【译】MySQL复制入门：探索不同类型的MySQL复制解决方案

原文地址：An Introduction to MySQL Replication: Exploring Different Types of MySQL Replication Solutions

在这篇博文中，我将深入介绍 MySQL 复制，回答它是什么、如何工作、它的优势和挑战，并回顾作为 MySQL 环境（特别是 Percona Server for MySQL）一部分的一些 MySQL 复制概念。最后，我还将澄清人们对复制的一些常见误解，以及 Percona 可以提供哪些帮助。

什么是 MySQL 复制？

MySQL 复制是将主 MySQL 数据库中的数据复制并发送到一个或多个辅助数据库（称为副本）的过程。
复制确保信息被复制并有目的地填充到另一个环境中，而不是只存储在一个位置（基于源环境的事务）。
这样做的目的是将基础架构上的辅助服务器用于读取或其他管理解决方案。下图显示了一个 MySQL 复制环境示例。
在这里插入图片描述

MySQL 复制安装要求

在本节中，我们将介绍实施 MySQL 复制的基本要素：

前提条件和要求：

Primary-Replica 配置：确保有一个主 MySQL 数据库和一个或多个副本 MySQL 数据库。
网络连接：在主服务器和副本服务器之间建立可靠的网络连接。
MySQL 版本：确保主服务器和副本服务器上的 MySQL 版本与复制兼容。

安装 MySQL 复制 - 具体步骤：

备份数据：在开始之前，创建主数据库备份，以防止在设置过程中丢失数据。
配置主服务器：
- 编辑主服务器上的 MySQL 配置文件（my.cnf 或 my.ini），启用二进制日志记录。
- 重新启动 MySQL 服务。
创建复制用户：
- 登录主服务器上的 MySQL，创建具有必要权限的专用复制用户。
记录二进制日志坐标：
- 记下当前二进制日志文件和主服务器上的位置。
配置复制服务器：
- 在每个副本服务器上，编辑 MySQL 配置文件，将其配置为副本。
- 将 server-id 设置为唯一值。
- 指定主服务器的主机名或 IP 地址。
- 在每个副本上重新启动 MySQL 服务。
初始化复制：
- 在其中一个副本服务器上运行 CHANGE MASTER TO 命令，指定主服务器的二进制日志文件和位置。
- 启动副本服务器的复制进程。
验证复制：
- 使用 SHOW SLAVE STATUS 检查复制的状态。确保 "Slave_IO_Running "和 "Slave_SQL_Running "都显示 “Yes”。
添加更多副本（可选）：
- 如果需要，在其他副本服务器上重复配置步骤。
监控和维护：
- 定期监控复制状态和日志。
- 执行日常维护和备份，确保数据完整性。
扩展和负载平衡（可选）：
- 如果有多个副本，请实施负载平衡和故障切换机制。

MySQL 复制有哪些潜在优缺点？

MySQL复制可提供高可用性、负载平衡和数据冗余，从而提高系统可靠性。它还能实现地理分布式数据库的灾难恢复。不过，考虑潜在的缺点也很重要，包括管理副本的复杂性增加、复制滞后的可能性以及需要监控和维护以确保各副本的一致性和可靠性。

优点

MySQL 复制有很多优点，但其中几个重点包括：通过将读取密集型工作负载分布到多个副本、降低主数据库服务器负载和提高整体性能来增强可扩展性。复制还能在主服务器不可用时切换到副本服务器，从而提高数据库可用性。
最后，在发生灾难的情况下，数据和数据库可以快速恢复，因为复制提供了地理上分散的数据副本。

缺点

尽管有这么多好处，MySQL 复制也会面临一些潜在的缺点。一个非常常见的问题是数据一致性，尤其是在写入活动较多的设置中。副本可能会落后于主服务器，从而影响任何依赖实时数据的应用程序。
另一个问题是单点故障风险。如果主服务器出现故障，整个复制过程就会中断。实施前面讨论的故障转移机制可以降低这种风险。
在安全性方面，如果没有正确配置加密和访问控制，主服务器和副本服务器之间传输的数据可能会受到攻击。

MySQL 复制有哪些不同类型？

您实际上有几种不同的选择：

标准异步复制（Standard asynchronous replication）

异步复制意味着事务完全在本地环境中完成，不受复制本身的影响。

在完成更改后，主线程会将数据修改或实际语句填充到二进制日志中（基于行的复制和基于语句的复制之间的区别–稍后详述）。转储线程读取二进制日志，并将其发送给副本 IO 线程。副本使用其 IO 线程将其放入自己的预处理队列（称为中继日志）。

副本使用 SQL 线程执行副本数据库中的每次更改。
在这里插入图片描述

半同步复制（Semi-synchronous replication）

半同步复制是指副本和主服务器之间相互通信，以保证事务的正确传输。只有当其中一个副本确认事务已正确放入副本的一个中继日志时，主服务器才会填充 binlog 并继续其会话。

半同步复制能保证事务被正确复制，但不能保证在副本上的提交实际发生。
在这里插入图片描述
需要注意的是，半同步复制确保主服务器等待继续处理特定会话中的事务，直到至少有一个副本 ACK 了事务接收（或超时）。这与异步复制不同，半同步复制允许额外的数据完整性。

请记住，半同步复制会影响性能，因为它需要等待副本实际 ACK 的往返。

组复制（Group Replication）

这一新概念在 MySQL 社区版 5.7 中引入，并在 MySQL 5.7.17 中得到认可。它是一个用于虚拟同步复制的全新插件。
每当在一个节点上执行事务时，插件都会尝试与其他节点达成共识，然后再将完成的事务返回给客户端。虽然该解决方案与标准的 MySQL 复制概念完全不同，但它基于使用 binlog 生成和处理日志事件。

以下是组复制的架构示例。
在这里插入图片描述

Percona XtraDB Cluster / Galera Cluster

另一种可将信息复制到其他节点的解决方案是 Percona XtraDB Cluster。该解决方案专注于提供一致性，还使用认证流程来保证事务避免冲突并正确执行。

在这种情况下，我们谈论的是集群解决方案。每个环境都使用相同的数据，节点之间通过通信来保证一致性。

Percona XtraDB Cluster 有多个组件：

用于 MySQL 的 Percona 服务器
Percona XtraBackup，用于执行运行集群的快照（如果要恢复或添加节点）。
wsrep 修补程序/Galera 库

该解决方案实际上是同步的，可与组复制（Group Replication）相媲美。不过，它还具有使用多主复制的功能。Percona XtraDB Cluster 等解决方案是提高数据库基础架构可用性的组成部分。
在这里插入图片描述
通过我们的电子书了解如何优化数据库安装配置以实现高可用性，Percona Distribution for PostgreSQL: High Availability With Streaming Replication

基于行的复制与基于语句的复制（Row-Based Replication Vs. Statement-Based Replication）

基于语句的复制

在基于语句的复制中，SQL 查询本身被写入二进制日志。例如，副本会执行完全相同的 INSERT/UPDATE/DELETE 语句。

这种系统有很多优缺点：

由于实际语句记录在二进制日志中，因此审计数据库更加容易
通过线路传输的数据更少
非确定性查询（即那些其结果可能因多种因素而变化的查询）可在副本环境中造成实际破坏
使用基于语句的复制（基于 SELECT 的 INSERT）进行某些查询时，可能会出现性能劣势
由于 SQL 的优化和执行，基于语句的复制速度较慢

基于行的复制

基于行的复制是从 MySQL 5.7.7 开始的默认选择，它有很多优点。行更改会记录在二进制日志中，而且不需要上下文信息。这消除了非确定性查询的影响。

其他一些优势包括

包含少量行更改的高并发查询的性能提升
显著提高数据一致性

当然，也有一些缺点：

如果有修改大量行的查询，网络流量会大大增加
更难审核数据库中的更改
在某些情况下，基于行的复制可能比基于语句的复制更慢

处理故障和确保高可用性

确保 MySQL 复制的高可用性对于不间断的数据库访问非常重要，有几种策略可用于实现这一目标。其中一种方法是实施故障转移（failover）机制。故障切换可确保在主 MySQL 服务器因硬件故障或其他问题而不可用时，系统无缝切换到备用副本。设置故障转移机制可以使用负载平衡器或代理服务器来完成，它们会持续监控主服务器的健康状况。一旦发现问题，这些工具就会自动将流量重定向到备用副本。

半同步复制是另一种在高可用性 MySQL 设置中确保数据一致性的重要技术。这种方法要求在主服务器上提交事务之前，至少要有一个副本确认，从而确保数据更改在主服务器上确认之前，安全地复制到至少一个副本。这就降低了主服务器发生故障时数据丢失的风险。通过优先考虑数据一致性而不是原始性能，半同步复制为防止数据差异提供了一个额外的保护层，使其成为对保持数据完整性至关重要的高可用性配置中的一项重要功能。