社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  DATABASE

阿里二面:聊聊 MySQL 主从同步方案的优缺点

脚本之家 • 1 周前 • 27 次点击  
脚本之家 设为“星标
第一时间收到文章更新
图片
来源 | 君哥聊技术(ID:gh_1f109b82d301)

大家好,我是君哥。今天来聊一聊 MySQL 主从架构。

MySQL Replication 是 MySQL 官方提供的主从同步方案,用于将 MySQL 主库的数据同步到从库中,从库可以供应用程序读取数据。

1 简介

Replication 是目前 MySQL 使用最多的灾备方案,主要有 3 个作用:

  1. 读写分离,写主库读从库。这样大大降低主库的负载,即使主库出现类似锁表之类的情况,也不影响应用读取数据。
  2. 实现灾备,当主库发生故障时,可以方便地把从库切换成主库,实现高可用(HA)。
  3. 水平扩展,当应用访问量导致数据库 I/O 高时,可以通过水平扩展的方式将降低单机负载,降低磁盘 I/O。

下面是一个 MySQL Replication 的案例。

在上面的例子中,有一个主库,三个从库,通过 Replication,主库生成 events 的 binlog 发给 slave,Slave 将收到的 binlog 拷贝到 relaylog,然后解析 relaylog 中的命令进行执行,实现主从数据同步。

2 同步原理

MySQL 通过 binlog 实现同步过程中,会用到 3 个线程:

  • IO thread: 从库执行 START SLAVE 语句时,会创建一个 IO thread,负责连接主节点,请求更新的 binlog,接收到 binlog 后写入 relaylog;
  • dump thread:主库接收到从库的 binlog 请求后,创建一个 dump thread,把 binlog 同步给从库;
  • sql thread:读取 relaylog,解析 relaylog 的命令并执行,将数据落库。

整个同步流程如下:

  1. 在从库上执行 change master 命令,设置要连接主库的用户名、密码、ip、端口以及请求同步的 binlog 中的位置,这个位置包含文件名和binlog offset;
  2. 从库执行 start slave 命令,这时会启动上面的 IO thread 和 sql thread,其中 IO thread 负责跟主库建立连接;
  3. 主库收到从库的连接请求后,校验用户名密码;
  4. 主库校验通过后创建 dump thread,按照从库请求 binlog 的 offset 将 binlog 发给从库;
  5. 从库收到主库发送的 binlog 后,将日志写入 relaylog;
  6. sql thread 读取 relaylog,解析出命令后执行。

3 优缺点

前面讲到,主从同步有读写分离、实现灾备、水平扩展等优点。那主从同步有哪些缺点呢?最大的缺点就是主从延迟

导致主从延迟的主要原因如下:

  1. 从库所在机器性能差,命令执行慢;
  2. 从库查询压力大,消耗了大量 CPU 资源,影响了 sql thread 执行;
  3. 主库有大事务(比如大表DDL),这个事务里面执行的 sql 比较多,一方面主库需要等待事务执行完成才能写入 binlog,另一方面同步到从库和在从库执行都需要花费很多时间,导致主从延迟;
  4. 数据库版本低,在 MySQL 5.6 之前,只支持单线程复制,效率比较低;
  5. 表上无主键,主库利用索引更改数据,从库只能用全表扫描。

要解决主备延迟的问题,可以考虑下面方法:

  1. 优化业务逻辑,避免使用大事务,或者大事务场景尽量放在业务低峰期执行;
  2. 提高从库所在机器的性能;
  3. 保障网络性能,避免网络延迟;
  4. 引入 semi-sync 半同步复制,配合异步复制。

主从同步的第二个缺点就是数据丢失

MySQL 有 3 种主从复制方式:

  1. 异步复制:主库执行完客户端提交的事务后立即将结果返回给客户端,不关心从库是否同步完成。这种方式很容易发生数据丢失,比如主库的日志还未同步给从库就宕机了,这时需要在从库中选择一个作为新主库,之前未同步完成的数据就丢失了;
  2. 全同步复制:主库执行完客户端提交的事务并且等待从库也执行完成数据同步后再把结果返回给客户端。这种方式能够保证不丢失数据,但是数据库的性能会受到影响;
  3. 半同步复制:是介于全同步和异步复制的一种方式,主库至少等待一个从库接收 binlog 并成功写入到 relaylog 后给客户端返回结果。主库不需要等待所有从库返回 ACK。

MySQL 中默认采用异步复制,这样很容易导致数据丢失。一个好的方式就是采用 semi-sync 半同步复制插件。不过 semi-sync 存在一个问题,主库写数据到 binlog 后执行 commit,才会给从库同步数据。如果从库还没有返回 ACK,主库发生了宕机,从库还没有写完 relaylog 就被选择为主库,也会发生数据丢失。

为了解决这个问题,MySQL 5.7 引入了增强版半同步复制。主库写入数据到 binlog 后,就给从库进行同步,直到至少一个从库返回给主库 ACK,主库才会进行 commit 操作。

4 总结

本文介绍了 MySQL 主从同步方案的优缺点,希望能对你使用和理解 MySQL 有所帮助。

图片
  推荐阅读:
  1. DML 误操作?MySQL 闪回工具大盘点
  2. MySQL用得好好的,为啥非要转ES?
  3. MySQL 主从复制 1594 报错分析
  4. 悟了:MySQL原来是这样执行SQL的!

  5. 如何准确获取 MySQL 主从延迟时间?

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/181850
 
27 次点击