MGR环境构建中需要考虑的细节（一）
这是学习笔记的第 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等操作？