MGR中某个事务就悄无声息的漏掉了，数据丢了，跌入”深坑“都毫无察觉等着被”宰杀“，怕不？惊不？这个细节所有准备使用MGR的朋友都需要知道。
如ppt,某个事务就悄无声息的漏掉了，数据丢了，你还不知道。这是一个带dba进入”跑路“的坑。
其实，这个问题很简单，但是不了解mgr的人基本都会忽略，作者在初学mgr的时候，同样忽略了这个问题，因为没有人或者文档，资料告诉我需要谨慎对待这个group_replication_boostrap_group 参数，所以，亲自踩了这个坑。踩了之后还不知道自己掉坑里了，等着被宰杀，这个是最恐怖的。
具体的过程是这样的。作者在初始化启动MGR集群的第一个节点时，将
group_replication_boostrap_group 参数设置为on ,之后就没有管了。后来，这个节点从集群上剥离了，需要重新启动group replication。 当重新启动group replication之后，发现这个节点并没有跟其他节点进行数据同步。 经检查，是因为参数group_replication_boostrap_group设置为on的原因，该节点作为一个独立的集群启动了，所以它没有跟其他节点同步数据。
发现这个问题之后，所以重新设置group_replication_boostrap_group为off, 然后再通过start group_replication启动gr服务，然后发现“妥了“，数据开始同步了。但是，巨大的隐患就在此产生了，已经踩入了深坑，该节点已经丢失了一个事务，不再在是一个完整的数据副本。 数据一致性已破坏，而且当时还毫不知觉。
原因：当节点以独立的集群角色启动的时候，会产生一个view change的事件，也会产生一个事务，也会使gtid_executed增加一个事务。当将该节点再次跟GR集群同步时，会从下一个事务开始进行同步，真正的业务产生的这个事务号的事务就会漏掉。
group replication为更强地保护跟解决数据一致性而生，但这个细节，如果被忽略，将把使用者带入深渊。 当作者发现这个细节时，当时”一身汗“。
为了不踩坑，请注意下面三点：
1。永远不要将group_replication_boostrap_group在参数文件中设置为on .不然节点重启时，可能带你入坑。
2。在初始启动GR集群中的第一个节点时，启动完毕之后，立即将该group_replication_boostrap_group参数设置为off, 以免之后忘记设置。
3。养成好的习惯，执行start group_replication命令之前，先检查一下参数group_replication_boostrap_group是否设置正确，以免因为其他人对该参数的改动而带你入坑。