Recommended
More Related Content
Viewers also liked
Viewers also liked (14)
Similar to Everything i know about galera cluster
Similar to Everything i know about galera cluster (20)
Everything i know about galera cluster
- 1. 关于Galera Cluster Everything I know
- 2. 主要内容 • 传统数据库复制技术及其缺陷 • Galera Cluster及其机理 • Galera Cluster的优势 • 新节点加⼊入流程 • SST与IST • 节点状态变化流程 • 脑裂处理及权重设定 • 使⽤用Galera Cluster的⼀一些建议 • Galera Cluster的⼀一些限制 • 在Galera Cluster上更新表结构遇到的问题 • Galera Cluster的性能、监控及其他
- 3. 传统复制结构及其缺陷
- 4. 传统复制结构及其缺陷 • 异步复制，存在复制延迟 • 单进程复制，性能较差 • 宕机可能导致数据丢失 • 新节点需⼿手⼯工同步数据 • 伪双主，难以同时写⼊入 • 故障转移时存在停机时间
- 6. 同步复制机理
- 8. Galera Cluster 优势 • 真正的多主架构，任何节点都可以读写 • 同步复制，⽆无延迟，宕机数据不会丢失 • 所有节点数据⼀一致 • 多进程复制，提供更好性能 • 热备，⽆无需故障转移，因此⽆无停机时间 • ⾃自动成员控制，故障节点⾃自动移除；⾃自动 节点加⼊入 • ⽆无需进⾏行读写分离 • 对应⽤用透明，⽆无需或者只需进⾏行很⼩小修改
- 11. 新 节 点 加 ⼊入 Node1 Node2 Node3 rsync receive SST Request wsrep_cluster_address=Node2 Joiner
- 12. 新 节 点 加 ⼊入 Node1 Node2 Node3 rsync receiversync send Node2 enter ‘donor mode’ write operations blocked Joiner
- 14. SST的三种⽅方式 SST 类型 速度 服务 权限 读锁 依赖 mysqldump 逻辑复制 很慢 服务先运⾏行 都需要 是 ⽆无 rsync 物理复制 最快 服务后启动 都不需要 是 数据库版 本及配置 xtrabackup 物理复制 很快 服务后启动 Donor需要 基本⽆无 数据库版 本及配置
- 15. SST与IST
- 16. SST与IST • SST相当于全量 • IST相当于增量 • 节点根据情况⾃自动选 择合适的⽅方式 • 增⼤大gcache.size以增 ⼤大IST窗⼜⼝口 • 可以根据binlog或 write_replicated_bytes估 算write-sets增长速度
- 17. 节点状态变化
- 20. 脑裂（⽹网络分区）处理 当前分区权重之和 > (前主分区权重值和-安全下线节点权重之和)/2 • 满⾜足上述选举公式的分区为主分区。 • 只有主分区能够继续修改数据，⾮非主分区将⼀一直尝试连接主分区 • 集群最⼩小节点数是3个，最好使⽤用奇数个节点。 • 跨交换机集群最少分布在三台交换机，跨⽹网络集群最少分布在三 组⽹网络，跨机房集群最好分布在三个机房 • 通过设定节点权重，可以配置在应对⽹网络分区时类似主从、⼀一主 多从的集群。 • 所有节点都正常的集群可以看做⼀一个特殊的主分区。
- 21. ⼀一些建议 • 定期分析冲突⽐比例，寻找冲突热点并修改对应业务逻辑。 • 为了降低冲突可能性，考虑在⼀一台或少量节点进⾏行写⼊入，其他节 点⽤用于读取。 • 专门划分⼀一个节点⽤用做Donor，避免SST对在线业务有任何影响 ；由于此节点不参与业务连接，在集群性故障时其数据完整性较 ⾼高。 • 新节点加⼊入集群时，最好指定Donor。 • 增⼤大Gcache，增⼤大IST时间窗⼜⼝口。 • 设置⾃自动重试提交，降低冲突时事务回滚的可能。 • 备份的三种⽅方法：断开⼀一个节点⽤用于备份、通过SST命令接⼜⼝口和 使⽤用Xtrabackup。 • 集群通过公⽹网同步时，通过VPN或配置SSL加密数据。 • 通过防⽕火墙阻⽌止⾮非授权节点通过SST偷取数据。
- 22. 使⽤用限制 • 只⽀支持innodb，任何写⼊入其他引擎的表，包括mysql.*表将不会复制。 DDL/DCL语句会被复制的，因此创建⽤用户将会被复制，但是insert into mysql.user......并不会被复制。 • ⾃自增键增长间隔不确定，⼤大体按照取模进⾏行间隔，并⾏行在两个节点插 ⼊入数据时，⾃自增键相互交叉。 • 在多主环境下对LOCK/UNLOCK TABLES，以及锁函数 GET_LOCK(), RELEASE_LOCK()不⽀支持，不过设计合理的事务⼀一般 也不需要这些锁。 • DELETE操作不⽀支持没有主键的表，没有主键的表在不同的节点顺序 将不同(DELETE … LIMIT … 在不同节点上执⾏行同样语句得到的结果 不同)。 • 查询⽇日志不能保存在表中。如果开启查询⽇日志，只能保存到⽂文件中。
- 23. • 事务⼤大⼩小有限制，默认为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(更新表结构)语句可能破坏集群。 使⽤用限制
- 24. 更新表结构问题
- 25. 更新表结构问题 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…
- 26. 更新表结构问题 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语句 • ⽆无法回滚 • 执⾏行前需加锁
- 27. 更新表结构问题 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的基于事务的复制。 • 对于其他语句，直接跳过或者执⾏行前加锁。
- 28. 向后兼容性
- 29. 向后兼容性 新旧应⽤用都能够使⽤用新旧表结 构： — 新应⽤用能够检测表结构版本并具有兼容 性 — 如果旧应⽤用不能使⽤用新的表结构，那么 旧应⽤用只能连接⼀一个节点，该节点最后升 级表结构 删除表或者列的问题： — 需要延后操作，等待应⽤用完成升级后 再统⼀一删除 应⽤用兼容性
- 30. 向后兼容性 新旧应⽤用都能够使⽤用新旧表结 构： — 新应⽤用能够检测表结构版本并具有兼容 性 — 如果旧应⽤用不能使⽤用新的表结构，那么 旧应⽤用只能连接⼀一个节点，该节点最后升 级表结构 删除表或者列的问题： — 需要延后操作，等待应⽤用完成升级后 再统⼀一删除 应⽤用兼容性 ⾏行复制兼容性 MySQL的⾏行复制有⼀一些限制： — 旧表到新表可以有不同数量的列 — 但是这些列的顺序必须⼀一致 — 新的列放在最后，⽽而且必须有默认值 — 允许⼀一定的数据类型转换 — 这些限制将可能会继续放宽
- 31. 向后兼容性 新旧应⽤用都能够使⽤用新旧表结 构： — 新应⽤用能够检测表结构版本并具有兼容 性 — 如果旧应⽤用不能使⽤用新的表结构，那么 旧应⽤用只能连接⼀一个节点，该节点最后升 级表结构 删除表或者列的问题： — 需要延后操作，等待应⽤用完成升级后 再统⼀一删除 应⽤用兼容性 ⾏行复制兼容性 MySQL的⾏行复制有⼀一些限制： — 旧表到新表可以有不同数量的列 — 但是这些列的顺序必须⼀一致 — 新的列放在最后，⽽而且必须有默认值 — 允许⼀一定的数据类型转换 — 这些限制将可能会继续放宽 基于语句复制就不会存在上述两 个兼容性需求，但是Galera不会 ⽀支持基于语句的复制： — ⼀一致性存在风险 — ⽆无法并⾏行复制 — 已经过时了
- 33. Total Order Isolation 优点： — 严格⼀一致性，所有节点同时更新 — 不需要担⼼心向后兼容性 缺点： — 严格的提交顺序限制 将阻塞所有事务操作 适⽤用场景： — DDL语句执⾏行很快 — 表结构更新⽆无法满⾜足向后兼容性 — 存在维护时间窗⼜⼝口
- 35. Rolling Schema Upgrade 优点： — DDL不会阻塞集群 — DDL完成后⾃自动同步 缺点： — 节点所有链接将被断开 — 必须向后兼容 — ⼀一次只能执⾏行⼀一个RSU操作 — ⼿手⼯工完成所有节点RSU 适⽤用场景： — DDL需要很长时间 — 不存在维护时间窗⼜⼝口 — 能够考虑向后兼容性
- 47. 性能
- 48. 性能
- 49. 性能
- 50. 性能
- 51. 性能
- 52. 监控 • Galera Cluster在节点关系 发⽣生变更时可以执⾏行⽤用户⾃自 定义脚本 • 常规的端⼜⼝口/进程监控 • 使⽤用Ganglia采集集群运⾏行 数据并进⾏行阈值告警 • 使⽤用server_audit插件进⾏行 操作审计
- 53. 可⽤用性/可靠性(补充) • 使⽤用Keepalived解决MaxScale的单点问题(服务器级别) • 使⽤用MaxScale进⾏行负载均衡和后端节点故障转移 • 单独搭建⼀一台数据库作为集群的从库，进⾏行数据备份
- 54. Q&A