从另一服务器启动MySQL复制的实践

准备工作

确认服务器环境

在开始从另一服务器启动 MySQL 复制之前，需要确保两台服务器（主服务器和从服务器）的 MySQL 版本兼容，且网络能够正常通信。一般来说，尽量使用相同版本的 MySQL 以避免潜在的兼容性问题。例如，两台服务器都运行 MySQL 8.0 版本。同时，要检查服务器之间的防火墙设置，确保 MySQL 服务所使用的端口（默认为 3306）能够在两台服务器之间畅通无阻。可以通过以下命令检查端口是否开放（假设使用的是 Linux 系统）：

telnet <主服务器IP> 3306

如果连接成功，说明端口是开放的；如果连接失败，则需要调整防火墙规则开放该端口。

主服务器配置

修改主服务器配置文件：打开主服务器上的 MySQL 配置文件（通常为 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），添加或修改以下配置参数：

[mysqld]
log-bin=mysql-bin # 开启二进制日志，这是主从复制的关键，用于记录数据库的更改操作
server-id=1 # 主服务器的唯一标识，每个参与复制的服务器都必须有唯一的 server-id，这里设为 1

保存并关闭配置文件后，重启 MySQL 服务使配置生效：

sudo systemctl restart mysql

创建用于复制的用户：登录到主服务器的 MySQL 数据库，创建一个专门用于从服务器连接并进行复制的用户。例如：

CREATE USER 'repl_user'@'<从服务器IP>' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'<从服务器IP>';
FLUSH PRIVILEGES;

这里 repl_user 是创建的用户名，password 是用户密码，<从服务器IP> 要替换为实际从服务器的 IP 地址。授予 REPLICATION SLAVE 权限，允许该用户执行复制相关操作。

获取主服务器状态：在主服务器上执行以下命令获取主服务器的二进制日志文件名和位置，这两个值在从服务器配置时会用到：

SHOW MASTER STATUS;

执行结果类似如下：

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql - bin.000003 | 154 | | | |
+------------------+----------+--------------+------------------+-------------------+

记录下 File 和 Position 的值，例如 mysql - bin.000003 和 154。

从服务器配置

修改从服务器配置文件：与主服务器类似，打开从服务器的 MySQL 配置文件，添加或修改以下配置参数：

[mysqld]
server-id=2 # 从服务器的唯一标识，不能与主服务器相同，这里设为 2

保存并关闭配置文件后，重启 MySQL 服务：

sudo systemctl restart mysql

配置从服务器连接主服务器：登录到从服务器的 MySQL 数据库，执行以下命令配置从服务器连接主服务器：

CHANGE MASTER TO
    MASTER_HOST='<主服务器IP>',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql - bin.000003',
    MASTER_LOG_POS=154;

这里 <主服务器IP> 替换为主服务器的实际 IP 地址，repl_user 和 password 是在主服务器上创建的用于复制的用户名和密码，MASTER_LOG_FILE 和 MASTER_LOG_POS 分别是在主服务器上通过 SHOW MASTER STATUS 命令获取的二进制日志文件名和位置。

启动从服务器复制：配置完成后，在从服务器上执行以下命令启动复制：

START SLAVE;

检查从服务器复制状态：执行以下命令检查从服务器的复制状态：

SHOW SLAVE STATUS \G;

重点关注以下两个参数：

Slave_IO_Running：如果为 Yes，表示从服务器的 I/O 线程正在运行，负责从主服务器读取二进制日志。
Slave_SQL_Running：如果为 Yes，表示从服务器的 SQL 线程正在运行，负责将读取到的二进制日志应用到从服务器的数据库中。同时，还需要确保 Seconds_Behind_Master 的值为 0 或接近 0，这表示从服务器与主服务器的数据同步延迟较小。如果 Slave_IO_Running 或 Slave_SQL_Running 为 No，则需要根据错误信息排查问题。常见问题及解决方法如下：

常见问题及解决方法

网络连接问题：如果 Slave_IO_Running 为 No，且错误信息提示网络连接失败，首先检查主从服务器之间的网络是否正常，如前面提到的通过 telnet 命令检查端口是否开放。还可能是因为 DNS 解析问题，如果使用主机名连接主服务器，确保从服务器能够正确解析主服务器的主机名。可以尝试在从服务器上通过 ping <主服务器主机名> 或 ping <主服务器IP> 来确认。
权限问题：若提示权限不足，确保在主服务器上为从服务器创建的用户具有正确的权限，并且用户名、密码和 IP 地址配置正确。可以重新在主服务器上创建用户并授予权限，然后在从服务器上重新执行 CHANGE MASTER TO 命令。
二进制日志位置错误：如果 Slave_SQL_Running 为 No，且错误信息与二进制日志位置相关，可能是在配置 CHANGE MASTER TO 命令时，MASTER_LOG_FILE 或 MASTER_LOG_POS 的值填写错误。重新在主服务器上执行 SHOW MASTER STATUS 命令获取正确的值，并在从服务器上重新配置 CHANGE MASTER TO 命令。

高级配置与优化

半同步复制

原理：传统的异步复制存在数据丢失的风险，因为主服务器在执行完事务并将二进制日志写入本地后，就会向客户端返回成功，而不等待从服务器接收并应用这些日志。半同步复制则介于异步复制和同步复制之间，主服务器在执行完事务并将二进制日志写入本地后，会等待至少一个从服务器接收并保存这些日志，然后才向客户端返回成功。这样可以在一定程度上保证数据的安全性，减少数据丢失的可能性。
配置步骤：
- 主服务器配置：在主服务器的 MySQL 配置文件中添加以下配置参数：

[mysqld]
rpl_semi_sync_master_enabled=1 # 开启主服务器的半同步复制
rpl_semi_sync_master_timeout=10000 # 设置主服务器等待从服务器确认的超时时间，单位为毫秒

重启 MySQL 服务后，登录到主服务器的 MySQL 数据库，加载半同步复制插件：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

- **从服务器配置**：在从服务器的 MySQL 配置文件中添加以下配置参数：

[mysqld]
rpl_semi_sync_slave_enabled=1 # 开启从服务器的半同步复制

重启 MySQL 服务后，登录到从服务器的 MySQL 数据库，加载半同步复制插件：

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

然后在从服务器上启动半同步复制：

START SLAVE;

验证半同步复制：在主服务器上执行以下命令查看半同步复制状态：

SHOW STATUS LIKE 'Rpl_semi_sync_master_status';

如果 Value 为 ON，表示半同步复制已启用。在从服务器上执行以下命令查看半同步复制状态：

SHOW STATUS LIKE 'Rpl_semi_sync_slave_status';

如果 Value 为 ON，表示从服务器已成功启用半同步复制。

多线程复制

原理：在传统的主从复制中，从服务器只有一个 SQL 线程来应用主服务器的二进制日志，这在高并发写入的情况下可能会成为性能瓶颈。多线程复制则允许从服务器使用多个线程来并行应用二进制日志，从而提高复制的性能。MySQL 从 5.6 版本开始支持基于库的多线程复制（slave_parallel_type=DATABASE），从 5.7 版本开始支持基于逻辑时钟的多线程复制（slave_parallel_type=LOGICAL_CLOCK）。
配置步骤：
- 从服务器配置：在从服务器的 MySQL 配置文件中添加或修改以下配置参数：

[mysqld]
slave_parallel_workers=4 # 设置从服务器用于并行复制的线程数，可根据服务器性能调整
slave_parallel_type=LOGICAL_CLOCK # 设置并行复制类型，这里使用基于逻辑时钟的方式

重启 MySQL 服务后，登录到从服务器的 MySQL 数据库，执行以下命令重新启动复制：

STOP SLAVE;
START SLAVE;

性能调优：多线程复制的性能调优需要根据实际的业务场景和服务器硬件资源进行。一般来说，增加并行复制的线程数可以提高复制性能，但过多的线程可能会导致资源竞争加剧，反而降低性能。可以通过监控从服务器的 CPU、内存和磁盘 I/O 等指标，逐步调整 slave_parallel_workers 的值，找到最优的配置。

GTID 复制

原理：GTID（Global Transaction Identifier）即全局事务标识符，是 MySQL 5.6 版本引入的一项新特性。在传统的主从复制中，从服务器通过记录主服务器的二进制日志文件名和位置来进行复制，这种方式在主服务器发生故障切换或二进制日志轮换时，配置和维护相对复杂。而 GTID 复制则为每个事务分配一个全局唯一的标识符，从服务器通过 GTID 来识别和应用事务，大大简化了主从复制的配置和管理，并且在故障恢复时能够更准确地定位和应用未复制的事务。
配置步骤：
- 主服务器配置：在主服务器的 MySQL 配置文件中添加或修改以下配置参数：

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON
log - bin=mysql - bin
server - id=1

重启 MySQL 服务后，登录到主服务器的 MySQL 数据库，创建用于复制的用户并授予权限：

CREATE USER 'repl_user'@'<从服务器IP>' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'<从服务器IP>';
FLUSH PRIVILEGES;

- **从服务器配置**：在从服务器的 MySQL 配置文件中添加或修改以下配置参数：

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON
server - id=2

重启 MySQL 服务后，登录到从服务器的 MySQL 数据库，执行以下命令配置从服务器连接主服务器：

CHANGE MASTER TO
    MASTER_HOST='<主服务器IP>',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_AUTO_POSITION=1;

然后启动从服务器复制：

START SLAVE;

验证 GTID 复制：在主服务器上执行以下命令查看 GTID 状态：

SHOW GLOBAL VARIABLES LIKE 'gtid_executed';

在从服务器上执行以下命令查看 GTID 状态：

SHOW GLOBAL VARIABLES LIKE 'gtid_executed';

确保从服务器的 gtid_executed 包含主服务器上已执行的 GTID，且 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，表示 GTID 复制配置成功。

故障处理与恢复

主服务器故障

切换从服务器为主服务器：当主服务器发生故障且无法快速恢复时，需要将其中一个从服务器提升为主服务器，以保证业务的连续性。首先，在要提升的从服务器上执行以下命令停止复制：

STOP SLAVE;

然后重置复制设置，清除之前作为从服务器的配置：

RESET SLAVE ALL;

接着修改从服务器的配置文件，将 server - id 设为一个新的唯一值（例如，如果原来为 2，可设为 101），并开启二进制日志（如果之前未开启）：

[mysqld]
server - id=101
log - bin=mysql - bin

保存并关闭配置文件后，重启 MySQL 服务。此时，该从服务器已成为新的主服务器。 2. 重新配置其他从服务器：其他从服务器需要重新配置连接到新的主服务器。首先在这些从服务器上停止复制：

STOP SLAVE;

然后根据新主服务器的信息重新执行 CHANGE MASTER TO 命令，例如：

CHANGE MASTER TO
    MASTER_HOST='<新主服务器IP>',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql - bin.000001',
    MASTER_LOG_POS=154;

这里 MASTER_LOG_FILE 和 MASTER_LOG_POS 需要根据新主服务器执行 SHOW MASTER STATUS 命令获取的结果进行填写。配置完成后，启动从服务器复制：

START SLAVE;

从服务器故障

数据恢复：如果从服务器的数据损坏或丢失，可以通过备份和主服务器的二进制日志进行恢复。首先，在主服务器上执行以下命令记录当前的二进制日志位置：

SHOW MASTER STATUS;

记录下 File 和 Position 的值。然后在从服务器上使用备份文件恢复数据（假设使用 mysqldump 进行备份）：

mysql - u root - p < backup.sql

恢复完成后，登录到从服务器的 MySQL 数据库，根据主服务器记录的二进制日志位置配置从服务器：

CHANGE MASTER TO
    MASTER_HOST='<主服务器IP>',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql - bin.000001',
    MASTER_LOG_POS=154;

启动从服务器复制：

START SLAVE;

同步延迟处理：如果从服务器出现同步延迟，可以通过以下方法进行处理。首先，检查从服务器的系统资源使用情况，如 CPU、内存和磁盘 I/O 等。如果资源不足，需要进行相应的调整，例如增加内存或优化磁盘 I/O。另外，可以调整多线程复制的参数，增加并行复制的线程数（slave_parallel_workers）来提高复制性能。还可以通过 SHOW PROCESSLIST 命令查看从服务器上复制线程的执行情况，分析是否存在锁等待或其他性能瓶颈。

监控与维护

监控复制状态

使用 SHOW SLAVE STATUS 命令：如前面提到的，通过 SHOW SLAVE STATUS \G 命令可以获取从服务器的详细复制状态信息。除了关注 Slave_IO_Running、Slave_SQL_Running 和 Seconds_Behind_Master 等关键参数外，还可以查看 Last_IO_Error 和 Last_SQL_Error 等字段，以了解复制过程中是否出现错误。如果出现错误，根据错误信息进行排查和解决。
使用性能监控工具：可以使用 pt - slave - lag 等工具来实时监控从服务器的延迟情况。pt - slave - lag 是 Percona Toolkit 中的一个工具，它可以快速获取从服务器与主服务器之间的延迟时间，并支持设置阈值进行报警。例如，安装 Percona Toolkit 后，可以通过以下命令查看从服务器延迟：

pt - slave - lag --daemonize --pid /var/run/pt - slave - lag.pid --interval 1 --master_host=<主服务器IP> --master_user=root --master_password=password

这里 --interval 参数表示检查延迟的时间间隔，单位为秒。

定期维护

清理二进制日志：主服务器上的二进制日志会不断增长，占用大量磁盘空间。因此，需要定期清理不需要的二进制日志。可以通过 PURGE BINARY LOGS 命令来清理二进制日志。例如，清理所有早于指定日志文件的二进制日志：

PURGE BINARY LOGS TO 'mysql - bin.000005';

还可以设置自动清理二进制日志的策略，在主服务器的 MySQL 配置文件中添加以下参数：

[mysqld]
expire_logs_days=7 # 设置二进制日志的保留天数，这里设为 7 天

重启 MySQL 服务后，MySQL 会自动清理超过保留天数的二进制日志。 2. 优化数据库性能：定期对主从服务器的数据库进行性能优化，例如执行 OPTIMIZE TABLE 命令优化表结构，ANALYZE TABLE 命令更新表的统计信息等。这些操作可以提高数据库的查询性能，减少复制延迟的可能性。同时，定期检查服务器的硬件资源使用情况，确保服务器有足够的资源来支持数据库的运行和复制。

通过以上详细的步骤、高级配置、故障处理以及监控维护方法，能够有效地从另一服务器启动 MySQL 复制，并保证其稳定、高效地运行。在实际应用中，需要根据具体的业务需求和服务器环境进行灵活调整和优化。