从MySQL复制迁移到MySQL Galera Cluster 4.0的技巧

导语：
如何成功的将数据库从MySQL复制迁移到MySQL Galera Cluster一直是很多人关心的问题，今天我们将分享一些从MySQL复制设置迁移到MySQL Galera Cluster 4.0的技巧。

MySQL复制和Galera群集之间的区别

如果您还不熟悉Galera，建议您阅读Galera Cluster for MySQL Tutorial。与使用异步复制的MySQL复制相比，Galera Cluster使用基于同步复制的完全不同级别的复制（但也可以将其配置为实现半同步复制）。

加莱拉集群还支持多主复制。它能够不受约束平行施加（即，“并行复制”），组播复制，和自动节点供应的。

Galera Cluster的主要重点是数据一致性，而使用MySQL复制时，它容易出现数据不一致（可以通过最佳实践和适当的配置来避免，例如在从属服务器上强制执行只读操作，以避免在从属服务器中进行不必要的写入）。

尽管Galera接收到的事务要么应用于每个节点，要么根本不应用于所有节点，但是这些节点中的每个节点都证明申请人队列中的复制写集（事务提交），其中还包括有关数据库在执行期间持有的所有锁的信息。交易。一旦没有确定冲突的锁，就会应用这些写集。到目前为止，事务被视为已提交，并继续将其应用于表空间。与异步复制不同，此方法也称为虚拟同步复制，因为写入和提交是在逻辑同步模式下进行的，但是对表空间的实际写入和提交是独立发生的，并且在每个节点上都是异步的。

与MySQL复制不同，Galera集群是真正的多主机，多线程从属服务器，是纯热备份，无需进行主服务器故障转移或读写拆分。但是，迁移到Galera Cluster并不意味着可以自动解决您的问题。Galera Cluster仅支持InnoDB，因此如果您使用MyISAM或内存存储引擎，则可以进行设计修改。

将非InnoDB表转换为InnoDB
Galera Cluster确实允许您使用MyISAM，但这不是Galera Cluster设计的目的。Galera Cluster旨在严格实现集群内所有节点内的数据一致性，这需要强大的ACID兼容数据库引擎。InnoDB是在这一领域具有强大功能的引擎，建议您使用InnoDB。特别是在处理交易时。

如果您使用的是ClusterControl，则可以轻松地为Performance Advisors提供的任何MyISAM表确定数据库实例。您可以在Performance→Advisors选项卡下找到它。例如，

如果您需要MyISAM和MEMORY表，您仍然可以使用它，但是请确保不需要复制您的数据。您可以将存储的数据用作只读数据，并在适当的地方使用“ START TRANSACTION READONLY”。

向您的InnoDB表添加主键
由于Galera Cluster仅支持InnoDB，因此所有表必须具有聚集索引（也称为主键或唯一键）非常重要。为了从查询，插入和其他数据库操作中获得最佳性能，非常重要的一点是必须使用唯一键定义每个表，因为InnoDB使用聚簇索引为每个表优化最常见的查找和DML操作。这有助于避免集群中长时间运行的查询，并且可能减慢集群中的写/读操作。

在ClusterControl中，有一些顾问可以通知您。例如，在您的MySQL Replication主/从群集中，您将从顾问列表中的或视图中发出警报。下面的示例屏幕快照显示，您没有没有主键的表：

识别主节点（或活动作者）
Galera Cluster纯粹是真正的多主复制。但是，这并不意味着您可以随意编写要定位的任何节点。要确定的一件事是，当在不同的节点上进行写入并且将检测到冲突的事务时，您将陷入如下所示的死锁问题：

1个 2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
2 
3 TRANSACTION 728431, ACTIVE 0 sec starting index read
4
5 mysql tables in use 1, locked 1
6
7 MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
8 
9 2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
10
11 TRANSACTION 728426, ACTIVE 3 sec updating or deleting
12
13mysql tables in use 1, locked 1
14
15, undo log entries 11409
16
17 MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
18岁
19 update sbtest1_success set k=k+1 where id > 1000 and id < 100000
20
21 2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
22
23 RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
24
25 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
26
270: len 8; hex 73757072656d756d; asc supremum;;

多个节点写入而未标识当前活动写入器节点的问题，您将遇到这些问题，这是我在同时写入多个节点时使用Galera Cluster时遇到的非常普遍的问题。为了避免这种情况，您可以使用单主机设置方法：

从文档中，

要放松流量控制，您可以使用以下设置：

1个 wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

由于fc_master_slave不是动态的，因此上述操作要求服务器重新启动。

启用调试模式以记录冲突或死锁
Galera Cluster的调试或跟踪问题非常重要。与MySQL复制相比，Galera中的锁实现方式有所不同。在集群范围内处理事务时，它使用乐观锁定。与MySQL复制不同，它仅具有悲观锁定，它不知道在多主服务器上的联合主服务器中是否正在执行相同或冲突的事务。Galera仍然使用悲观锁定，但是在本地节点上，因为它由InnoDB（受支持的存储引擎）管理。Galera在转到其他节点时使用乐观锁定。这意味着在获得本地锁定（悲观锁定）时，不会对群集中的其他节点进行检查。Galera假定，一旦交易通过存储引擎中的提交阶段，并且其他节点得到通知，

实际上，最好启用wsrep_logs_conflicts。这将记录冲突的MDL以及群集中InnoDB锁的详细信息。启用此变量可以动态设置，但启用后请注意。它会冗长地填充您的错误日志文件，并且一旦您的错误日志文件太大就会填满磁盘。

小心您的DDL查询
与MySQL Replication 不同，运行ALTER语句只能影响需要访问或引用ALTER语句所针对的表的传入连接。如果表很大，它也会影响从属，并可能导致从属滞后。但是，只要您的查询与当前的ALTER不冲突，对主文件的写操作就不会被阻止。但是，在带有Galera Cluster的ALTER之类的DDL语句运行时，情况并非完全如此。ALTER语句可能会引起问题，例如由于群集范围内的锁定而导致Galera群集卡死，或者当某些节点从大写操作中恢复时，流控制开始放宽复制。

在某些情况下，如果该表太大并且对于您的应用程序来说是至关重要的主表，那么您可能最终会使其Galera Cluster停机。但是，无需停机即可实现。正如Rick James 在其博客中指出的那样，您可以遵循以下建议：

RSU vs TOI
滚动架构升级=一次手动执行一个节点（脱机）
总订单隔离= Galera进行同步，以便在所有节点上同时（按复制顺序）完成此操作。RSU和TOI
警告：由于无法将客户端与DDL同步，因此必须确保客户端对旧模式或新模式都满意。否则，您可能需要关闭整个群集，同时切换模式和客户端代码。

“快速” DDL也可以通过TOI完成。这是此类的暂定清单：

创建/删除/重命名数据库/表
更改默认值
更改以更改ENUM或SET的定义（请参见手册中的注意事项）
某些分区更改速度很快。
DROP INDEX（主键除外）
添加索引？
“小型”桌上的其他ALTER。
对于5.6（尤其是5.7）具有大量ALTER ALGORITHM = INPLACE情况的情况，请检查应采用哪种方式进行哪些ALTER。
否则，请使用RSU。对每个节点分别执行以下操作：

1个 SET GLOBAL wsrep_OSU_method='RSU';

这也将节点带出群集。

1个 ALTER TABLE
2 SET GLOBAL wsrep_OSU_method='TOI';

重新放回，导致重新同步（希望是快速的IST，而不是慢的SST）

保持群集的一致性
Galera Cluster不支持诸如 binlog_do_db或 binlog_ignore_db之类的复制过滤器，因为Galera不依赖二进制日志记录。它依赖于也称为GCache的环形缓冲区文件，该文件存储沿集群复制的写集。您不能应用此类数据库节点的任何不一致的行为或状态。

另一方面，Galera严格在群集内实现数据一致性。仍然可能存在无法找到行或记录的不一致之处。例如，为DDL ALTER语句将变量wsrep_OSU_method 设置为RSU或TOI可能会带来不一致的行为。查看Percona的这个外部博客，讨论与TOI vs RSU的Galera不一致。

设置wsrep_on = OFF并随后运行DML或DDL查询可能会对您的集群造成危险。如果结果不依赖于节点的状态或环境，则还必须查看存储过程，触发器，函数，事件或视图。当某个节点可能不一致时，可能会导致整个群集崩溃。一旦Galera检测到不一致的行为，Galera将尝试离开群集并终止该节点。因此，所有节点可能不一致，从而使您处于困境中。

如果Galera Cluster节点也发生崩溃，尤其是在高流量时段，最好不要立即启动该节点。取而代之的是，请执行完整的SST或尽快或在流量降低时引入一个新实例。节点可能带来不一致的行为，这可能已损坏了数据。

**隔离大事务并确定是否使用流复制 **
让我们直接看一看。流复制是最大的更改功能之一，尤其是在Galera Cluster 4.0上。过去的Galera Cluster 4.0版本限制了<2GiB的事务，该事务通常由变量wsrep_max_ws_rows和wsrep_max_ws_size控制。从Galera Cluster 4.0开始，您可以发送> 2GiB的事务，但是必须确定复制期间必须处理多大的碎片。它必须按会话进行设置，唯一需要注意的变量是wsrep_trx_fragment_unit和wsrep_trx_fragment_size。禁用流复制很简单，因为将wsrep_trx_fragment_size设置为0会做的。请注意，由于日志将被写入MySQL数据库中的wsrep_streaming_log表，因此复制大型事务在从属节点（针对当前活动写入器/主节点进行复制的节点）上也具有开销。

要补充的另一件事是，由于您要处理大型事务，因此事务可能需要一些时间才能完成，因此必须将变量innodb_lock_wait_timeout 设置为高，这是很可观的。通过会话设置此时间，具体取决于您估计的时间，但大于估计的完成时间，否则会导致超时。

我们建议您阅读此以前的博客，其中介绍了实际的流复制。

复制GRANTs语句
如果您使用的是GRANT，则相关操作将对数据库mysql中的MyISAM / Aria表进行操作。将复制GRANT语句，但不会复制基础表。因此，这意味着将不会复制INSERT INTO mysql.user …，因为该表是MyISAM。

但是，由于Percona XtraDB Cluster（PXC）8.0（当前处于实验状态），上述内容可能不再适用，因为mysql模式表已转换为InnoDB，而在MariaDB 10.4中，某些表仍为Aria格式，而另一些为CSV或InnoDB。您应该确定拥有的Galera版本和提供程序，但最好避免使用引用 mysql模式的DML语句。否则，除非您确定这是PXC 8.0，否则可能会得到意想不到的结果。

不支持XA事务，锁定/解锁表，GET_LOCK / RELEASE_LOCK

Galera Cluster不支持XA事务，因为XA事务处理回滚和提交的方式不同。LOCK / UNLOCK或GET_LOCK / RELEASE_LOCK语句在Galera上应用或使用很危险。您可能会遇到无法杀死的死锁或锁，并保持锁定状态。例如，

1个 ---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
2
3 mysql tables in use 2, locked 2
4
5 3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
6
7 MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
8
9 insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

此交易已被解锁，甚至被杀死，但无济于事。我们建议您在迁移到Galera Cluster时必须重新设计应用程序客户端，并摆脱这些功能。

网络稳定是必须的！！！

Galera Cluster甚至可以使用WAN间拓扑或地理间拓扑，而不会出现任何问题（请查看此博客，了解如何使用Galera实现地理间拓扑）。但是，如果每个节点之间的网络连接不稳定或在意外时间内间歇性地断开，则对于群集可能会出现问题。最好让您的群集在专用和本地网络中运行，并在其中连接这些节点中的每个节点。将节点设计为灾难恢复时，如果这些节点位于不同的区域或地理位置，则应计划创建一个群集。您可能会开始阅读我们以前的博客，“ 使用MySQL Galera群集复制创建地理分布式群集：第一部分”，因为这可以帮助您最好地确定Galera群集拓扑。

关于投资网络硬件要增加的另一件事是，如果您的网络传输速率在IST期间重建实例期间为您提供较低的速度，或者在SST中提供的速度较慢，尤其是在您的数据量庞大的情况下，那将是一个问题。这可能需要很长时间的网络传输，并且可能会影响群集的稳定性，特别是如果您有一个3节点群集，而2个节点不可用（其中2个是捐助者和连接者）则不然。请注意，在SST阶段，直到DONOR / JOINER节点最终能够与主群集同步之前，它才能被使用。

在Galera的先前版本中，当涉及到施主节点选择时，会随机选择“状态快照传输（SST）”施主。在Glera 4中，它有了更大的改进，并能够在集群中选择合适的供体，因为它将偏爱可以提供增量状态转移（IST）的供体，或在同一段中选择一个供体。另外，您可以将wsrep_sst_donor变量设置为您希望始终选择的正确的捐助者。

在迁移期间和生产之前备份数据并进行严格测试
当您适应并决定尝试将数据迁移到Galera Cluster 4.0时，请确保始终准备好备份。如果您尝试了ClusterControl，则进行备份应更容易。

确保您正在迁移到正确的InnoDB版本，并且不要忘记在进行测试之前始终应用并运行mysql_upgrade。确保所有测试都通过了MySQL复制可以为您提供的期望结果。很可能，在MySQL复制集群中使用的InnoDB存储引擎与MySQL Galera集群没有什么区别，只要事先已应用和准备了建议和技巧即可。

结论
迁移到Galera Cluster 4.0可能不是您想要的数据库技术解决方案。但是，只要可以准备，设置和提供其特定要求，就可以使用Galera Cluster 4.0。Galera Cluster 4.0现在已成为非常强大的可行选择，尤其是在高度可用的平台和解决方案上。