这是学习笔记的第 1870篇文章
MGR这个方案之前写了一些文章来讨论,其实要在你的业务中落地,需要考虑的细节就很多了。
如果把如下的步骤当做线上环境的正式部署,
那就很有问题了。
首先第一个就是MGR是否在技术上可控,第二个是考虑如何尽可能平滑的切换过来。
技术可控方面,我也做了大量的部署测试,也总结了一些初步的实践总结。
首先原本的MGR部署我们在测试中是一种迭代的部署方式,需要安装插件了安装,安装后在线修改参数,这些变更都是内存级别生效,但是如果这个实例重启了,还能不能启动起来,原先的配置是不是还能够生效,从实际的使用情况来说,不规范的操作,MGR是肯定起不来的。
所以部署的过程需要循序渐进的配置
1)安装数据库
2)配置插件
3)配置新增参数
另外就是一个比较明显的问题,原本的文件管理是一种混乱的状态,所有的文件都在一个目录下面,尤其是MGR里面新增了额外的日志,这些日志和binlog都放在一起,会感觉目录非常混乱。从正式使用来说,我们需要对MySQL的目录做一个整体的规划和设计。
比如innodblog里面放redo,binlog和applylog,log目录里面放慢日志,错误日志,tmp目录放socket文件等。
此外你需要考虑在线上环境如何部署。 换句话来说,如果线上已经存在一套环境,我们怎么能够适配新的MGR架构。
如果平滑从业务过度到该架构,有一些前置的配置需要考虑。
1)主库需要是GTID模式,这里的差别就是GTID会对应一些更加标准规范的使用习惯,如果已有的业务中使用了GTID,那么切换到MGR的犯错成本就会小一些。 比如create table xxxx as select *from xxxx;这种语法在GTID模式下是不可行的。
2)表需要主键,这一点是硬性规定,也是作为MySQL方向集群的潜规则。MGR在这方面的提示有些太委婉了,建表无主键可以成功,但是无法写入数据,其实可以更加直接。
3)对于已有的业务,自增列的使用是否有连续性的要求,在MGR里面,自增列的部分是一个中和的设计。
在单机版本中,自增列的参数如下:
>>show variables like '%increment%';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| auto_increment_increment | 1
| auto_increment_offset | 1
| div_precision_increment | 4
| innodb_autoextend_increment | 64
在MGR环境中的自增列情况如下:
>show variables like '%increment%';
+--------------------------------------------+-------+
| Variable_name |Value |
+--------------------------------------------+-------+
| auto_increment_increment | 7
| auto_increment_offset | 7239
| div_precision_increment | 4
| group_replication_auto_increment_increment | 7
| innodb_autoextend_increment | 64
如果对于自增列的连续性有强业务依赖,那么MGR方案的实现会有一些出入,也就是你原本的自增列值为1,结果下一次就可能是8了。我们可以设置的小一些,因为MGR最多支持9个节点,而绝大多数的环境中节点7个就是很多了,在设计的时候也是做了这样的一个中和,我们可以把这个参数设置的小一些。
通过环境的配置发现MGR节点的server-id相同的情况下依然可以搭建成功,需要设置server-id为不同的值,避免后续环境对接中出现问题。
此外MGR的方案你是打算怎么用或者有一个长远的规划,
比如集群的架构设计,是否考虑了跨机房?
是否考虑双写模式?
在网络存在较大延迟的情况下,如何对MGR的数据一致性做充分的测试。
MGR方案也可以是一个比较轻量的方案,不一定非要3台以上,2台就可以搭建一套简单的集群环境,如何平滑的实现switchover等操作?