6种MySQL高可用方案对比分析

大家好，我是 V 哥，关于 MySQL 高可用方案，在面试中频频出现，有同学在字节面试就遇到过，主要考察你在高可用项目中是如何应用的，V 哥整理了6种方案，供你参考。
V 哥推荐：2024 最适合入门的 JAVA 课程
MySQL的高可用方案有多种，常见的包括以下几种：

1. 主从复制（Master-Slave Replication）

• 原理：主库进行写操作，数据通过异步或半同步复制到从库。可以通过从库进行读操作，实现读写分离。
• 优点：实现简单，适用于读多写少的场景。
• 缺点：主库故障时，手动提升从库为主库，切换较慢。可以借助管理工具，如MHA（Master High Availability）来自动切换主从。

**主从复制（Master-Slave Replication）**是一种常见的MySQL高可用方案，主要用于数据读写分离、备份、故障恢复等场景。以下是适合的业务场景和实现步骤的详细介绍。

一、主从复制适合的业务场景

1. 读多写少的业务

   • 在一些业务场景中，数据库的读操作远多于写操作。通过将读操作分发到从库，减轻主库的压力。
   • 例如：电商平台中的商品展示页面，读操作远多于写操作。

2. 数据备份

   • 主从复制可以为数据提供实时备份，从库上的数据几乎实时同步主库。即便主库故障或出现问题，也可以通过提升从库为主库来确保业务的持续运行。

3. 故障恢复

   • 主库故障时，可以快速切换到从库，提供一定程度上的高可用性。

4. 数据分析

   • 数据分析或报表生成往往对实时性要求不高，可以从从库中读取数据进行分析，避免影响主库的性能。

二、主从复制的实现步骤

1. 准备工作

• 环境要求：假设有两台服务器，分别作为主库（Master）和从库（Slave）。IP地址假设为：
  • 主库IP：192.168.1.100
  • 从库IP：192.168.1.101
• 安装MySQL：确保主库和从库都已经安装了MySQL，并进行基础配置。

2. 主库（Master）配置

1. 修改主库的MySQL配置文件

   • 编辑主库的MySQL配置文件my.cnf或my.ini（路径根据系统不同有所差异，一般在/etc/my.cnf或/etc/mysql/my.cnf）。

     [mysqld]

     开启二进制日志 (Master必须开启)

     log-bin=mysql-bin

     设置server-id，确保在集群中唯一

     server-id=1

     设置binlog格式，推荐ROW

     binlog_format=ROW

     可选：限制binlog大小

     max_binlog_size=100M

     可选：保留二进制日志的天数

     expire_logs_days=7

2. 重启MySQL服务

   在修改配置文件后，需要重启MySQL服务以使配置生效：

   sudo systemctl restart mysqld

3. 创建用于复制的用户

   在主库上为从库创建一个专门用于复制的用户，并授予复制权限：

   CREATE USER ‘replica’@‘192.168.1.101’ IDENTIFIED BY ‘replica_password’;
   GRANT REPLICATION SLAVE ON . TO ‘replica’@‘192.168.1.101’;
   FLUSH PRIVILEGES;

4. 锁定数据库并获取二进制日志文件和位置

   由于复制需要基于二进制日志来同步数据，所以需要锁定表来确保数据的一致性：

   FLUSH TABLES WITH READ LOCK;
   SHOW MASTER STATUS;

运行SHOW MASTER STATUS;命令后，MySQL会返回类似如下信息：

   +------------------+----------+--------------+------------------+
   | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
   +------------------+----------+--------------+------------------+
   | mysql-bin.000001 |      120 |              |                  |
   +------------------+----------+--------------+------------------+

记录下File和Position的值，例如：mysql-bin.000001 和 120。它们将在配置从库时使用。

5. 备份主库数据

   使用mysqldump进行全量备份，将数据导出并导入从库：

   mysqldump -u root -p --all-databases --master-data > master_backup.sql

6. 解锁表

   完成备份后，解除数据库锁定：

   UNLOCK TABLES;

3. 从库（Slave）配置

1. 修改从库的MySQL配置文件

   • 编辑从库的MySQL配置文件my.cnf或my.ini。

     [mysqld]

     设置server-id，确保在集群中唯一

     server-id=2

     从库不需要开启二进制日志，除非需要级联复制

     log-bin=mysql-slave-bin

     其他可选配置

     relay-log=relay-bin

2. 重启从库MySQL服务

   使配置生效：

   sudo systemctl restart mysqld

3. 导入主库数据

   将在主库导出的备份文件导入到从库：

   mysql -u root -p < master_backup.sql

4. 配置复制

   使用主库的二进制日志文件名和位置，配置从库的复制：

   CHANGE MASTER TO
   MASTER_HOST=‘192.168.1.100’,
   MASTER_USER=‘replica’,
   MASTER_PASSWORD=‘replica_password’,
   MASTER_LOG_FILE=‘mysql-bin.000001’,
   MASTER_LOG_POS=120;

5. 启动复制

   配置完成后，启动从库的复制进程：

   START SLAVE;

6. 检查复制状态

   通过以下命令查看从库的复制状态：

   SHOW SLAVE STATUSG;

需要确认以下两个字段为Yes，表明复制正常运行：

   Slave_IO_Running: Yes
   Slave_SQL_Running: Yes

4. 读写分离配置（可选）

1. 应用层处理读写分离

   • 应用程序可以通过代码配置，将写操作定向到主库，将读操作定向到从库。
   • 例如：在Java Spring中，使用AbstractRoutingDataSource来根据操作类型选择不同的数据库连接。

2. 使用中间件（例如Mycat、ProxySQL）

   • 可以使用数据库中间件，将读写分离的逻辑下沉到中间件层，实现更灵活的负载均衡。

三、维护和监控

1. 监控主从同步延迟

   • 通过Seconds_Behind_Master字段监控从库的延迟，确保数据同步及时。

2. 定期备份从库

   • 虽然从库的数据是实时同步的，但仍需定期备份从库，防止意外数据丢失。

3. 故障切换

   • 当主库故障时，可以手动提升从库为主库：

     STOP SLAVE;
     RESET SLAVE ALL;

---

主从复制可以为读多写少的业务场景提供一个简单而有效的解决方案，既提升了读操作的性能，也增强了数据库的可靠性。

2. 半同步复制（Semi-Synchronous Replication）

• 原理：在主库提交事务之前，至少一个从库确认收到数据，才算提交成功。相比于异步复制，有一定的延迟但更安全。
• 优点：保证数据一致性较强，适用于对数据一致性要求高的业务。
• 缺点：相比异步复制延迟较大，尤其在网络状况不佳时。

**半同步复制（Semi-Synchronous Replication）**是介于异步复制和全同步复制之间的一种高可用方案。它在写操作时不仅要求主库将数据写入二进制日志文件，还要求至少一个从库确认收到数据后，主库才认为提交成功。相比异步复制，它提供了更好的数据一致性保障，但又不像全同步复制那样带来较大的性能开销。以下将详细介绍它的适用业务场景和具体实现步骤。

一、半同步复制适合的业务场景

1. 对数据一致性要求较高的业务

   • 半同步复制适用于那些对数据一致性要求较高的业务场景。例如，金融系统、银行交易系统或电子商务平台，这些业务对数据的一致性要求非常严格，需要确保主库上的数据已经被至少一个从库接收到。

2. 高并发写操作下保证数据的安全

   • 如果某个业务场景具有大量的写操作，同时不能容忍数据丢失，半同步复制可以确保主库在提交事务时至少有一个从库已经收到数据，从而保证在主库崩溃时，数据依然是安全的。

3. 低容忍度的故障恢复

   • 在需要快速故障恢复的场景下，半同步复制可以确保数据在主库发生故障时不会丢失，这样可以快速地将从库提升为主库，以确保业务的连续性。

4. 跨地域分布的数据库

   • 当主库和从库位于不同数据中心时，半同步复制可以确保至少一个从库位于不同地理位置，保证在单个数据中心故障时，数据仍然可用。

二、半同步复制的实现步骤

1. 准备工作

• 假设我们有两台服务器，一台作为主库（Master），另一台作为从库（Slave）。我们将配置半同步复制，确保在事务提交时，至少一个从库已经收到数据。
• 假设主库的IP为192.168.1.100，从库的IP为192.168.1.101。

2. 主库（Master）配置

1. 修改主库的MySQL配置文件

   • 编辑主库的MySQL配置文件my.cnf或my.ini。

     [mysqld]

     启用二进制日志（必须开启）

     log-bin=mysql-bin

     设置server-id，必须在主从库中唯一

     server-id=1

     设置binlog格式，推荐ROW格式

     binlog_format=ROW

     启用半同步复制的插件

     plugin-load=rpl_semi_sync_master=semisync_master