关于Galera Cluster Everying I know
关于Galera ClusterEverything I know
主要内容
•传统数据库复制技术及其缺陷 • Galera Cluster及其机理 • Galera Cluster的优势 •新节点加⼊入流程 • SST与IST •节点状态变化流程 •脑裂处理及权重设定 •使⽤用Galera Cluster的⼀一些建议 • Galera Cluster的⼀一些限制 •在Galera Cluster上更新表结构遇到的问题 • Galera Cluster的性能、监控及其他
传统复制结构及其缺陷
传统复制结构及其缺陷
•异步复制,存在复制延迟
•单进程复制,性能较差
•宕机可能导致数据丢失
•新节点需⼿手⼯工同步数据
•伪双主,难以同时写⼊入
•故障转移时存在停机时间
Galera Cluster
同步复制机理
Galera Cluster 优势
Galera Cluster 优势
•真正的多主架构,任何节点都可以读写•同步复制,⽆无延迟,宕机数据不会丢失•所有节点数据⼀一致•多进程复制,提供更好性能•热备,⽆无需故障转移,因此⽆无停机时间
•⾃自动成员控制,故障节点⾃自动移除;⾃自动节点加⼊入
•⽆无需进⾏行读写分离•对应⽤用透明,⽆无需或者只需进⾏行很⼩小修改
新节点加⼊入
Node1
Node2
新节点加⼊入
Node1
Node2 Node3
Joiner
新节点加⼊入
Node1
Node2 Node3rsync receive
SST Request
wsrep_cluster_address=Node2
Joiner
新节点加⼊入
Node1
Node2 Node3rsync receiversync send
Node2 enter ‘donor mode’ write operations blocked
Joiner
新节点加⼊入
Node1
Node2 Node3
Joiner
Catch up
SST的三种⽅方式
SST 类型 速度 服务 权限 读锁 依赖
mysqldump 逻辑复制 很慢 服务先运⾏行 都需要 是 ⽆无
rsync 物理复制 最快 服务后启动 都不需要 是 数据库版本及配置
xtrabackup 物理复制 很快 服务后启动 Donor需要 基本⽆无 数据库版本及配置
SST与IST
SST与IST
• SST相当于全量
• IST相当于增量
•节点根据情况⾃自动选择合适的⽅方式
•增⼤大gcache.size以增⼤大IST窗⼜⼝口
•可以根据binlog或write_replicated_bytes估算write-sets增长速度
节点状态变化
节点状态变化
1、节点启动并且连接到主分区。
2、成功发起SST请求,开始缓存write-sets
3、接收完SST数据,节点获得集群所有数据并开始消化write-sets
4、节点追上集群,复制队列为空并开启Flow Control保证其继续为空,节点能够开始处理事务
5、节点收到SST请求,Flow Control将其降级为Donor状态,缓存但并不消化write-sets
6、节点完成将SST数据传输到Joiner的任务
脑裂(⽹网络分区)处理
当前分区权重之和 > (前主分区权重值和-安全下线节点权重之和)/2
脑裂(⽹网络分区)处理
当前分区权重之和 > (前主分区权重值和-安全下线节点权重之和)/2
•满⾜足上述选举公式的分区为主分区。•只有主分区能够继续修改数据,⾮非主分区将⼀一直尝试连接主分区•集群最⼩小节点数是3个,最好使⽤用奇数个节点。
•跨交换机集群最少分布在三台交换机,跨⽹网络集群最少分布在三组⽹网络,跨机房集群最好分布在三个机房
•通过设定节点权重,可以配置在应对⽹网络分区时类似主从、⼀一主多从的集群。
•所有节点都正常的集群可以看做⼀一个特殊的主分区。
⼀一些建议
•定期分析冲突⽐比例,寻找冲突热点并修改对应业务逻辑。 •为了降低冲突可能性,考虑在⼀一台或少量节点进⾏行写⼊入,其他节点⽤用于读取。 •专门划分⼀一个节点⽤用做Donor,避免SST对在线业务有任何影响;由于此节点不参与业务连接,在集群性故障时其数据完整性较⾼高。 •新节点加⼊入集群时,最好指定Donor。 •增⼤大Gcache,增⼤大IST时间窗⼜⼝口。 •设置⾃自动重试提交,降低冲突时事务回滚的可能。 •备份的三种⽅方法:断开⼀一个节点⽤用于备份、通过SST命令接⼜⼝口和使⽤用Xtrabackup。 •集群通过公⽹网同步时,通过VPN或配置SSL加密数据。 •通过防⽕火墙阻⽌止⾮非授权节点通过SST偷取数据。
使⽤用限制
• 只⽀支持innodb,任何写⼊入其他引擎的表,包括mysql.*表将不会复制。DDL/DCL语句会被复制的,因此创建⽤用户将会被复制,但是insert into mysql.user......并不会被复制。
• ⾃自增键增长间隔不确定,⼤大体按照取模进⾏行间隔,并⾏行在两个节点插⼊入数据时,⾃自增键相互交叉。
• 在多主环境下对LOCK/UNLOCK TABLES,以及锁函数GET_LOCK(), RELEASE_LOCK()不⽀支持,不过设计合理的事务⼀一般也不需要这些锁。
• DELETE操作不⽀支持没有主键的表,没有主键的表在不同的节点顺序将不同(DELETE … LIMIT … 在不同节点上执⾏行同样语句得到的结果不同)。
• 查询⽇日志不能保存在表中。如果开启查询⽇日志,只能保存到⽂文件中。
• 事务⼤大⼩小有限制,默认为128k⾏行或1Gb⼤大⼩小,任何⼤大型操作(如LOAD DATA)将被拒绝。⽬目前默认⽀支持隐式提交,每10k⾏行⾃自动提交⼀一次。
• 由于在提交上可能回滚,不⽀支持XA事务。• 由于集群是乐观的并发控制,事务commit可能在该阶段中⽌止。如果有两个事务向在集群中不同的节点向同⼀一⾏行写⼊入并提交,失败的节点将中⽌止,需要应⽤用有对应的处理能⼒力。。
• 谨慎使⽤用binlog-do-db , binlog-ignore-db, replicate-wild-do-db, replicate-wild-ignore-db配置,可能出现数据不⼀一致。(replicate-do-db, replicate-ignore-db可⽤用)
• 集群性能由最差的节点决定,应该使⽤用相同配置节点。• 有问题的DDL(更新表结构)语句可能破坏集群。
使⽤用限制
更新表结构问题
更新表结构问题
SQL语句类型: • DML(Data Manipulation Language) — Select/Insert/Update… • DDL(Data Definition Language) — Create/Drop/Alter… • DCL(Data Control Language) — Grant/Revoke • TCL(Transaction Control Language) — Commit/Rollback…
更新表结构问题
SQL语句类型: • DML(Data Manipulation Language) — Select/Insert/Update… • DDL(Data Definition Language) — Create/Drop/Alter… • DCL(Data Control Language) — Grant/Revoke • TCL(Transaction Control Language) — Commit/Rollback…
事务型SQL: • Innodb上的所有DML语句 • 可以回滚
⾮非事务型SQL: • ⾮非事务型存储引擎的DDL、
DCL、DML语句 • ⽆无法回滚 • 执⾏行前需加锁
更新表结构问题
SQL语句类型: • DML(Data Manipulation Language) — Select/Insert/Update… • DDL(Data Definition Language) — Create/Drop/Alter… • DCL(Data Control Language) — Grant/Revoke • TCL(Transaction Control Language) — Commit/Rollback…
事务型SQL: • Innodb上的所有DML语句 • 可以回滚
⾮非事务型SQL: • ⾮非事务型存储引擎的DDL、
DCL、DML语句 • ⽆无法回滚 • 执⾏行前需加锁
• Galera使⽤用乐观的并发控制,其基础是冲突的事务可以回滚。 • 只有事务型语句才能通过Galera的基于事务的复制。 • 对于其他语句,直接跳过或者执⾏行前加锁。
向后兼容性
向后兼容性
新旧应⽤用都能够使⽤用新旧表结构: — 新应⽤用能够检测表结构版本并具有兼容性 — 如果旧应⽤用不能使⽤用新的表结构,那么旧应⽤用只能连接⼀一个节点,该节点最后升级表结构
删除表或者列的问题: — 需要延后操作,等待应⽤用完成升级后再统⼀一删除
应⽤用兼容性
向后兼容性
新旧应⽤用都能够使⽤用新旧表结构: — 新应⽤用能够检测表结构版本并具有兼容性 — 如果旧应⽤用不能使⽤用新的表结构,那么旧应⽤用只能连接⼀一个节点,该节点最后升级表结构
删除表或者列的问题: — 需要延后操作,等待应⽤用完成升级后再统⼀一删除
应⽤用兼容性 ⾏行复制兼容性
MySQL的⾏行复制有⼀一些限制: — 旧表到新表可以有不同数量的列 — 但是这些列的顺序必须⼀一致 — 新的列放在最后,⽽而且必须有默认值 — 允许⼀一定的数据类型转换 — 这些限制将可能会继续放宽
向后兼容性
新旧应⽤用都能够使⽤用新旧表结构: — 新应⽤用能够检测表结构版本并具有兼容性 — 如果旧应⽤用不能使⽤用新的表结构,那么旧应⽤用只能连接⼀一个节点,该节点最后升级表结构
删除表或者列的问题: — 需要延后操作,等待应⽤用完成升级后再统⼀一删除
应⽤用兼容性 ⾏行复制兼容性
MySQL的⾏行复制有⼀一些限制: — 旧表到新表可以有不同数量的列 — 但是这些列的顺序必须⼀一致 — 新的列放在最后,⽽而且必须有默认值 — 允许⼀一定的数据类型转换 — 这些限制将可能会继续放宽
基于语句复制就不会存在上述两个兼容性需求,但是Galera不会⽀支持基于语句的复制: — ⼀一致性存在风险 — ⽆无法并⾏行复制 — 已经过时了
Total Order Isolation
Total Order Isolation
优点: — 严格⼀一致性,所有节点同时更新 — 不需要担⼼心向后兼容性
缺点: — 严格的提交顺序限制将阻塞所有事务操作
适⽤用场景: — DDL语句执⾏行很快 — 表结构更新⽆无法满⾜足向后兼容性 — 存在维护时间窗⼜⼝口
Rolling Schema Upgrade
Rolling Schema Upgrade
优点: — DDL不会阻塞集群 — DDL完成后⾃自动同步
缺点: — 节点所有链接将被断开 — 必须向后兼容 — ⼀一次只能执⾏行⼀一个RSU操作 — ⼿手⼯工完成所有节点RSU
适⽤用场景: — DDL需要很长时间 — 不存在维护时间窗⼜⼝口 — 能够考虑向后兼容性
其他⽅方式及限制
wsrep_desync+wsrep_on
•本地更新表结构,不阻塞集群 •集群事务仍然同步到本地,如果发⽣生事务冲突,本地DDL语句将失败 •这种⽅方式只适合在确保⽆无冲突的时候适⽤用 •Galera可能会改进该⽅方式,使其只阻塞冲突的事务
TOI RSU
其他⽅方式及限制
隔离节点
•⼿手⼯工“RSU” •节点必须通过IST⽅方式加⼊入集群 •节点此时不能存在⽣生产环境的连接
TOI RSU wsrep_desync+wsrep_on
其他⽅方式及限制
隔离节点
•⼿手⼯工“RSU” •节点必须通过IST⽅方式加⼊入集群 •节点此时不能存在⽣生产环境的连接
TOI RSU wsrep_desync+wsrep_on
其他⽅方式及限制
隔离节点
•⼿手⼯工“RSU” •节点必须通过IST⽅方式加⼊入集群 •节点此时不能存在⽣生产环境的连接
TOI RSU wsrep_desync+wsrep_on
其他⽅方式及限制
隔离节点
•⼿手⼯工“RSU” •节点必须通过IST⽅方式加⼊入集群 •节点此时不能存在⽣生产环境的连接
TOI RSU wsrep_desync+wsrep_on
其他⽅方式及限制
pt-online-schema-change
•基于TOI •不⽀支持触发器,表中不能包含其他触发器 •每次只能升级⼀一个表 •处理外键约束的两种⽅方法都有额外影响 •存在风险,使⽤用前需测试
TOI RSU wsrep_desync+wsrep_on 隔离节点
其他⽅方式及限制
pt-online-schema-change
•基于TOI •不⽀支持触发器,表中不能包含其他触发器 •每次只能升级⼀一个表 •处理外键约束的两种⽅方法都有额外影响 •存在风险,使⽤用前需测试
TOI RSU wsrep_desync+wsrep_on 隔离节点
其他⽅方式及限制
pt-online-schema-change
•基于TOI •不⽀支持触发器,表中不能包含其他触发器 •每次只能升级⼀一个表 •处理外键约束的两种⽅方法都有额外影响 •存在风险,使⽤用前需测试
TOI RSU wsrep_desync+wsrep_on 隔离节点
其他⽅方式及限制
pt-online-schema-change
•基于TOI •不⽀支持触发器,表中不能包含其他触发器 •每次只能升级⼀一个表 •处理外键约束的两种⽅方法都有额外影响 •存在风险,使⽤用前需测试
TOI RSU wsrep_desync+wsrep_on 隔离节点
其他⽅方式及限制
pt-online-schema-change
•基于TOI •不⽀支持触发器,表中不能包含其他触发器 •每次只能升级⼀一个表 •处理外键约束的两种⽅方法都有额外影响 •存在风险,使⽤用前需测试
TOI RSU wsrep_desync+wsrep_on 隔离节点
简单判断流程
5s内执⾏行完毕
存在更⼤大时间窗⼜⼝口
是
否
否
TOI
是
表中存在触发器
RSU
PT-OSC
是
存在⼦子表且较⼤大
否是
rebuild_constraints
否
drop_old_table
性能
性能
性能
性能
性能
监控
• Galera Cluster在节点关系发⽣生变更时可以执⾏行⽤用户⾃自定义脚本
•常规的端⼜⼝口/进程监控
•使⽤用Ganglia采集集群运⾏行数据并进⾏行阈值告警
•使⽤用server_audit插件进⾏行操作审计
可⽤用性/可靠性(补充)
•使⽤用Keepalived解决MaxScale的单点问题(服务器级别)
•使⽤用MaxScale进⾏行负载均衡和后端节点故障转移
•单独搭建⼀一台数据库作为集群的从库,进⾏行数据备份
Q&A