滴滴面试题：MySQL主从部署，如何减小数据不一致的概率?

程序员飞鱼
104 阅读4分钟

文章内容收录到个人网站，方便阅读：hardyfish.top/

资料分享

MySQ技术内幕第5版：

深入浅出MySQL：

高性能MySQL第三版：

MySQL 主从部署及减少数据不一致的策略

在 MySQL 主从架构中，通过一主多从的方式可以有效地缓解主数据库的读取压力，同时也为高可用性提供了保障。

当主服务器挂掉后，可以通过配置从库或者使用第三方工具（如 MHA）选举出最新的从库作为新的主库。

为了确保从库能够承载主库的负载，建议从数据库的硬件配置至少与主数据库相当。

以下是详细的步骤和策略：

1. 一主多从架构

在一主多从架构中，主库负责写操作，从库负责读操作。

这样可以分散读负载，提高系统的整体性能。

优点：

  • 缓解主数据库的读取压力。
  • 提供数据冗余和高可用性。

2. 数据不一致的原因及解决方案

在主从架构中，数据不一致的原因主要有以下几种：

  • 网络延迟：主库的数据变更通过 binlog 传递到从库时，可能会有一定的网络延迟。
  • 复制延迟：从库应用 binlog 需要时间，可能会导致从库的数据稍微滞后于主库。
  • 故障恢复：主库故障恢复后，从库的数据可能与主库不一致。

减少数据不一致的策略：

  1. 异步复制调整：默认情况下，MySQL 使用异步复制，可以调整为半同步复制。

    • 异步复制：主库不等待从库确认，直接返回给客户端，存在较大延迟。
    • 半同步复制：主库在写操作完成后，等待至少一个从库确认接收到 binlog 后才返回给客户端，减少延迟。
    -- 在主库上启用半同步复制
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
​
-- 在从库上启用半同步复制
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

  2. 监控复制延迟：使用 SHOW SLAVE STATUS 命令监控复制延迟，如果发现延迟过大，可以调整网络配置或增加从库的硬件资源。

    SHOW SLAVE STATUS\G;

    关键字段包括：

    • Seconds_Behind_Master：显示从库落后主库的时间，单位为秒。
    • Relay_Log_Pos 和 Read_Master_Log_Pos：显示从库读取和执行 binlog 的位置。

  3. 优化从库性能：确保从库硬件配置至少与主库相当，并优化从库性能，包括：

    • 使用 SSD 以提高 I/O 性能。
    • 调整 InnoDB 缓存配置，增加 innodb_buffer_pool_size。
    • 调整从库的复制线程数，提高并发复制能力。

  4. 读写分离：使用中间件（如 MyCat、Atlas、ProxySQL）实现读写分离，将读请求分配到从库，写请求仍然发送到主库。

高可用性和故障切换

为了保证系统的高可用性，当主库发生故障时，需要迅速将一个从库提升为主库。常用的高可用性解决方案包括：

  1. MHA（Master High Availability） ：MHA 是一种用于 MySQL 高可用性和故障切换的工具。它可以自动监控 MySQL 主库的状态，并在主库发生故障时自动将最新的从库提升为新的主库。

    • 配置 MHA 管理节点和 MHA 工作节点。
    • 通过配置 MHA 自动检测和切换主库。

  2. 手动切换：在主库发生故障时，可以手动将一个从库提升为新的主库，更新应用程序的数据库连接配置。

  3. 自动化脚本：编写自动化脚本，监控主库状态并在发生故障时自动执行主从切换操作。

从库配置

确保从库的硬件配置至少与主库相当，以承载主库的负载。

主要包括：

  • CPU、内存和存储配置。
  • 网络带宽和延迟。

结论

通过以上措施，可以有效减少 MySQL 主从架构中的数据不一致性，并提高系统的高可用性。

包括调整复制方式、监控复制延迟、优化从库性能、使用读写分离和高可用性工具（如 MHA）等，这些措施都可以帮助我们在实际应用中实现稳定高效的数据库集群。

avatar
文章
阅读
粉丝