MySQL 复制概述和规则 - 性能和可扩展性的基石

1。复制概述

MySQL内置的复制功能是基于MySQL构建大规模、高质量应用程序的基础。复制解决的主要问题是允许一台服务器的数据与其他服务器存储。接下来，我们将从复制概述和原理、复制配置、常见问题及解决方案来学习MySQL的复制功能。

1.1 通过复制解决的问题

以下是复制的常见用途：

• 数据共享。 Mysql复制一般不会对带宽造成太大压力，但是5.1版本中引入的基于行的复制会比基于语句的复制方式造成更大的压力。您可以随意停止和启动复制，并跨地理位置（例如不同的数据中心）分发备份。此外，即使在不稳定的网络环境中，远程复制也能正常工作。但如果你想在未来节省低延迟，最好有一个长而低的连接。
• 负载平衡。通过Mysql复制，可以将读操作分布到多台服务器上，提高读性能，而且实现起来很容易。通过简单的代码更改即可完成基本的负载平衡。对于小型应用程序，您可以简单地使用 DNS 轮询（将主机名引用到多个 IP 地址）。
• 备份。负载是备份中另一项重要的技术。
• 可用和无效高度。负载可以帮助应用程序避免 MySQL 中的单点故障，而设计良好的使用复制的系统可以显着减少停机时间。
• MySQL升级测试。这是一种常见的做法。在升级Mysql版本之前，首先将升级后的版本作为备份文件，以确保升级后的版本不会对系统造成影响。

1.2 复制是如何工作的？

在详细介绍如何设置复制之前，我们先来看看Mysql实际上是如何复制数据的。

一般情况下，恢复分为三个步骤：

1. 将数据更改写入主数据库中的二进制日志（Binary Log）（这些记录称为二进制日志事件）。
2. 备库将主库中的日志复制到自己的中继日志（Relay Log）中。
3. 备库读取传输日志中的事件，并将其更改与备库同步。

上面是复制的简单概述，下图描述了复制的细节：

一般复制流程：

1. 在主库中记录 。在准备事务时，每次更新完成之前，主数据库都会在二进制日志中记录数据更新活动。Mysql 按事务顺序而不是按单个语句顺序记录二进制日志。记录二进制日志后，主库会告诉存储引擎事务是可能的。
2. 备库将主数据日志复制到本地传输日志。 首先，备库会启动一个工作线程，称为I/O线程。 I/O线程与主数据库建立到客户端的正常连接，然后在主数据库上启动一个特殊的二进制线程（binlog转储），这个转储线程-binary这将读取主库二进制日志。 。时间不受监控。如果线程正在向主库“申请”，那么它将进入睡眠状态，直到主库发送信号量通知它有新活动时才会更新。备用库I/O线程会将接收到的事件记录在传输日志中。
3. 备库启动SQL线程，执行最后一步。该线程从传输日志中读取事件并在备用数据库上执行它们以更新数据库。当SQL线程到达I/O线程时，中继日志通常已经在系统缓存中，因此中继日志的开销非常低。 SQL 线程执行的操作也可以使用配置功能写入二进制日志，这对于备用数据库的标准配置非常有用。

该复制架构实现了get 事件的发布和replay 事件，允许两个进程异步进行。这意味着I/O线程可以独立于SQL线程工作。然而，该系统限制了复制过程。最重要的一点是，在主库上运行的查询只能在备库上执行，因为只有一个 SQL 线程来检索中继日志。行动。

但好消息是5.7版本现在支持库的并行复制。基于二进制日志的并行复制会在日志内容中添加last_commissed和sequence_number，分别代表事务提交时间和最后一次事务提交计数。如果事务具有相同的时间，则意味着这些事务在一个组中并且可以并行重复。

2。复制原理

现在我们已经了解了复制的基本思想。接下来，我们需要更深入地了解复制，看看复制是如何工作的以及它的优点和缺点。

2.1 语句式复制

Mysql 5.0及之前版本支持语句式复制（也称为逻辑复制）。基于语句的恢复方式，主数据库会记录导致数据变化的SQL语句。当备库读取并重复这些操作时，它只是执行主库再次执行的 SQL。这种方法有优点也有缺点。

优点是：

1. 易于应用。理论上，只需登录并执行SQL语句，就可以保持主备服务器同步。
2. 二进制日志对带宽没有显着影响。二进制日志中的事件更准确并且占用的带宽更少。

但实际上，基于语句的方法可能并不像看起来那么好。它的缺点是：

1. 除了正在执行的语句之外，主库中的数据可能还取决于其他因素。当在主库中使用基于语句的迭代方法以及使用 CURRENT_USER() 函数的声明、存储过程和触发器时，可能会出现此问题。

2.2 基于行的复制

MySQL 5.1 开始支持基于行的复制。该方法将在二进制日志中记录正确的数据。同样，它也有其优点和缺点。

的优点是可以更准确地解释数据，但缺点是会造成较大的开销。比如工资表中有10000个用户，每个用户的工资加1000。那么基于行的复制会复制10000行的内容，会造成比较大的开销，但是基于语句的复制只需要一条语句。

因为没有一种方法是适合所有情况的，Mysql允许Mysql动态改变。默认启用语句复制，但如果发现语句无法正确复制，请进入复制模式。如果需要控制二进制日志格式，您还可以设置会话级 binlog_format 变量。

2.3 复制复制的文件

复制过程中会用到一些文件。我已经上传了二进制日志文件和中继日志文件。此外，还有其他文件可以使用。

1. mysql-bin.index：当二进制日志发送到服务器时，会有一个与二进制日志同名但扩展名为.index的文件。该文件用于将二进制文件写入磁盘。 。这里的索引不是表的索引，而是这个文件的每一行都包含了二进制文件的名称。 Mysql依靠这个文件来识别二进制日志文件。
2. mysql-relay-bin-index：中继日志索引文件，与mysql-bin.index功能相同。
3. master.info：存放角库与主库通信所需的信息文件。格式为纯文本（每行一个值），根据Mysql版本不同，包含的信息可能有所不同。该文件不能删除，否则初始化备库后将无法连接主库。该文件包含文本格式的复制用户密码，因此请务必检查该文件的权限。 Relay-log.info

使用这些文件来记录 Mysql 备份和日志位置是非常糟糕的做法。最可悲的是他们没有一起写作。如果服务器断电，数据没有刷新到磁盘，服务器重启后文件中存储的数据可能不正确。幸运的是，这些问题在5.5版本中得到了改善。

2.4 向另一台从服务器发送复制操作

log_slave_update 选项允许从数据库更新另一台服务器上的主数据库。设置此选项后，Mysql 将在自己的二进制日志中记录其已完成的操作。这样他就可以从日记中检索并执行事件。下图展示了这个过程：

在这种情况下，主数据库将数据更新活动记录在二进制日志中，并且主数据库接收并执行该操作。至此，一个Activity的生命周期就应该结束了。但由于设置了log_slave_updates，备用数据库会将这个事件写入自己的二进制日志中。这样，第二看门狗数据库可以在其传输日志中从第一看门狗数据库获取事件并执行它。

这意味着主数据库作为源服务器可以将其数据更改传达给未直接连接到它的常规数据库。默认情况下，此选项处于启用状态，因此连接到备用数据库时无需重新启动服务器。

当第一个看门狗数据记录独立数据在另一个二进制日志中的事件时，保证与主数据的二进制日志中的位置不同的是该事件在另一个二进制日志中的位置观看数据。也许在不同的日志文件或文件中的不同位置。这意味着您不能假设具有相同逻辑复制点的所有服务器都具有相同的日志坐标。

总结

1. 复制功能是MySQL高扩展性的基础。标准读写分区使用复制。
2. 审核使用三个线程。 master的日志线程将事件写入binlog，slave的IO线程接收binlog并写入relaylog，SQL线程返回relaylog。
3. 复制包括基于语句的复制和基于行的复制。？如需商业印刷，请联系作者以获得许可。非商业转载请注明来源。