关于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