尧图网站建设 
一、什么是复制ReplicationMySQL Replication 使来自一个 MySQL 数据库服务器称为源 Source的数据能够复制到一个或多个 MySQL 服务器称为副本 Replica。默认情况下复制是异步的副本不需要永久连接即可从源接收更新。根据配置可以复制所有数据库、指定数据库甚至某个数据库中的指定表。术语说明旧版本的 MySQL 复制将源Source称为主Master将副本Replica称为从Slave。二、复制的优势与缺点2.1 复制的优势高可用通过配置一定的复制机制MySQL 实现了跨主机的数据复制从而获得一定的高可用能力。如果需要获得更高的可用性只需配置多个副本或进行级联复制即可达到目的。性能扩展复制机制提供了多个数据备份可通过配置一个或多个副本将读请求分发至副本节点从而获得整体上读写性能的提升。异地灾备只需将副本节点部署到异地机房即可轻松获得一定的异地灾备能力。实际中需考虑网络延迟等可能影响整体表现的因素。交易分离通过配置复制机制将低频、大运算量的交易发送至副本节点执行可避免这些交易与高频交易竞争运算资源从而避免整体性能问题。2.2 复制的缺点没有故障自动转移容易造成单点故障。主库从库之间存在主从复制延迟问题容易造成最终数据的不一致。从库过多会对主库的负载以及网络带宽带来很大负担。三、复制的方式与数据同步类型3.1 复制的方式MySQL 8.0 支持多种复制方式基于 binlog 位点复制传统方法是基于从源的二进制日志binlog复制事件并要求日志文件及其中的位置在源和副本之间进行同步。源实例将更新和更改作为“事件”写入二进制日志副本配置为从源中读取二进制日志并在本地数据库上执行其中的事件。基于 GTID 复制基于全局事务标识符GTID的方式是完全基于事务的很容易确定源和副本是否一致只要在源上提交的所有事务也在副本上提交就可以保证两者之间的一致性。3.2 复制的数据同步类型异步复制默认方式。执行事务操作的线程不会等待复制 Binlog 的线程。主库收到客户端提交事务请求后先写入 Binlog再提交事务更新存储引擎数据然后给客户端返回成功响应。从库有专门的复制线程接收 Binlog 并写入中继日志另有回放线程读取中继日志更新数据。提交事务和复制流程在不同线程执行互不等待。劣势是可能存在主从延迟主节点宕机可能丢数据。半同步复制MySQL 5.7 开始支持。主节点收到客户端请求后必须在完成本节点日志写入的同时等待至少一个从节点完成数据同步的响应或超时后才会响应请求。从节点只有在写入 relay-log 并完成刷盘后才向主节点响应。当从节点响应超时时主节点将同步机制退化为异步复制从节点恢复并完成数据追赶后恢复为半同步复制。相比异步复制半同步复制提高了数据可用性但增加了网络交互和刷盘耗时整体响应性能有所降低。延迟复制使副本故意落后于源至少指定的时间。3.3 半同步复制的重要参数rpl_semi_sync_master_wait_slave_count8.0.26 之后改为 rpl_semi_sync_source_wait_for_replica_count至少等待数据复制到几个从节点再返回。数量配置越大丢数据风险越小但集群性能和可用性越差。rpl_semi_sync_master_wait_point8.0.26 之后改为 rpl_semi_sync_source_wait_point控制主库执行事务的线程是在提交事务之前AFTER_SYNC等待复制还是在提交事务之后AFTER_COMMIT等待复制。默认是 AFTER_SYNC即先等待复制再提交事务这样不会丢数据。四、设计理念复制状态机任何一个存储系统无论存储什么数据、用什么数据结构都可以抽象成一个状态机。存储系统中的数据称为状态状态的全量备份称为快照Snapshot按顺序记录更新存储系统的每条操作命令就是操作日志Commit Log即 MySQL 中的 Binlog。复制数据时只要基于一个快照按照顺序执行快照之后的所有操作日志就可以得到一个完全一样的状态。在从节点持续地从主节点上复制操作日志并执行就可以让从节点上的状态数据和主节点保持同步。要点这种基于“快照 操作日志”的方法并非 MySQL 特有。Redis Cluster 的全量备份称为 Snapshot操作日志叫 backlogElasticsearch 使用 translog备份和恢复数据的原理与实现方式完全一样。五、基于 binlog 位点同步的主从复制原理基于 binlog 位点同步的主从复制原理步骤如下主库会生成多个 binlog 日志文件。从库的 I/O 线程请求指定文件和指定位置的 binlog 日志文件位点。主库 dump 线程获取指定位点的 binlog 日志。主库按照从库发送来的位点信息读取 binlog然后推送 binlog 给从库。从库将得到的 binlog 写到本地的 relay log中继日志文件中。从库的 SQL 线程读取和解析 relay log 文件。从库的 SQL 线程重放 relay log 中的命令。六、基于 binlog 位点主从复制痛点分析基于 binlog 位点复制存在两大痛点痛点 1首次开启主从复制的步骤复杂。第一次开启主从同步时要求从库和主库一致需要找到主库的 binlog 位点、设置从库的 binlog 位点、开启从库的复制线程。痛点 2恢复主从复制的步骤复杂。需要找到从库复制线程停止时的位点、解决复制异常的事务。无法解决时需手动跳过指定类型的错误比如通过设置 slave_skip_errors1032,10621062 错误是插入数据时唯一键冲突1032 错误是删除数据时找不到行。关于搭建复制实战演示案例详情可参考链接有道云笔记 MySQL 主从复制
一、什么是复制ReplicationMySQL Replication 使来自一个 MySQL 数据库服务器称为源 Source的数据能够复制到一个或多个 MySQL 服务器称为副本 Replica。默认情况下复制是异步的副本不需要永久连接即可从源接收更新。根据配置可以复制所有数据库、指定数据库甚至某个数据库中的指定表。术语说明旧版本的 MySQL 复制将源Source称为主Master将副本Replica称为从Slave。二、复制的优势与缺点2.1 复制的优势高可用通过配置一定的复制机制MySQL 实现了跨主机的数据复制从而获得一定的高可用能力。如果需要获得更高的可用性只需配置多个副本或进行级联复制即可达到目的。性能扩展复制机制提供了多个数据备份可通过配置一个或多个副本将读请求分发至副本节点从而获得整体上读写性能的提升。异地灾备只需将副本节点部署到异地机房即可轻松获得一定的异地灾备能力。实际中需考虑网络延迟等可能影响整体表现的因素。交易分离通过配置复制机制将低频、大运算量的交易发送至副本节点执行可避免这些交易与高频交易竞争运算资源从而避免整体性能问题。2.2 复制的缺点没有故障自动转移容易造成单点故障。主库从库之间存在主从复制延迟问题容易造成最终数据的不一致。从库过多会对主库的负载以及网络带宽带来很大负担。三、复制的方式与数据同步类型3.1 复制的方式MySQL 8.0 支持多种复制方式基于 binlog 位点复制传统方法是基于从源的二进制日志binlog复制事件并要求日志文件及其中的位置在源和副本之间进行同步。源实例将更新和更改作为“事件”写入二进制日志副本配置为从源中读取二进制日志并在本地数据库上执行其中的事件。基于 GTID 复制基于全局事务标识符GTID的方式是完全基于事务的很容易确定源和副本是否一致只要在源上提交的所有事务也在副本上提交就可以保证两者之间的一致性。3.2 复制的数据同步类型异步复制默认方式。执行事务操作的线程不会等待复制 Binlog 的线程。主库收到客户端提交事务请求后先写入 Binlog再提交事务更新存储引擎数据然后给客户端返回成功响应。从库有专门的复制线程接收 Binlog 并写入中继日志另有回放线程读取中继日志更新数据。提交事务和复制流程在不同线程执行互不等待。劣势是可能存在主从延迟主节点宕机可能丢数据。半同步复制MySQL 5.7 开始支持。主节点收到客户端请求后必须在完成本节点日志写入的同时等待至少一个从节点完成数据同步的响应或超时后才会响应请求。从节点只有在写入 relay-log 并完成刷盘后才向主节点响应。当从节点响应超时时主节点将同步机制退化为异步复制从节点恢复并完成数据追赶后恢复为半同步复制。相比异步复制半同步复制提高了数据可用性但增加了网络交互和刷盘耗时整体响应性能有所降低。延迟复制使副本故意落后于源至少指定的时间。3.3 半同步复制的重要参数rpl_semi_sync_master_wait_slave_count8.0.26 之后改为 rpl_semi_sync_source_wait_for_replica_count至少等待数据复制到几个从节点再返回。数量配置越大丢数据风险越小但集群性能和可用性越差。rpl_semi_sync_master_wait_point8.0.26 之后改为 rpl_semi_sync_source_wait_point控制主库执行事务的线程是在提交事务之前AFTER_SYNC等待复制还是在提交事务之后AFTER_COMMIT等待复制。默认是 AFTER_SYNC即先等待复制再提交事务这样不会丢数据。四、设计理念复制状态机任何一个存储系统无论存储什么数据、用什么数据结构都可以抽象成一个状态机。存储系统中的数据称为状态状态的全量备份称为快照Snapshot按顺序记录更新存储系统的每条操作命令就是操作日志Commit Log即 MySQL 中的 Binlog。复制数据时只要基于一个快照按照顺序执行快照之后的所有操作日志就可以得到一个完全一样的状态。在从节点持续地从主节点上复制操作日志并执行就可以让从节点上的状态数据和主节点保持同步。要点这种基于“快照 操作日志”的方法并非 MySQL 特有。Redis Cluster 的全量备份称为 Snapshot操作日志叫 backlogElasticsearch 使用 translog备份和恢复数据的原理与实现方式完全一样。五、基于 binlog 位点同步的主从复制原理基于 binlog 位点同步的主从复制原理步骤如下主库会生成多个 binlog 日志文件。从库的 I/O 线程请求指定文件和指定位置的 binlog 日志文件位点。主库 dump 线程获取指定位点的 binlog 日志。主库按照从库发送来的位点信息读取 binlog然后推送 binlog 给从库。从库将得到的 binlog 写到本地的 relay log中继日志文件中。从库的 SQL 线程读取和解析 relay log 文件。从库的 SQL 线程重放 relay log 中的命令。六、基于 binlog 位点主从复制痛点分析基于 binlog 位点复制存在两大痛点痛点 1首次开启主从复制的步骤复杂。第一次开启主从同步时要求从库和主库一致需要找到主库的 binlog 位点、设置从库的 binlog 位点、开启从库的复制线程。痛点 2恢复主从复制的步骤复杂。需要找到从库复制线程停止时的位点、解决复制异常的事务。无法解决时需手动跳过指定类型的错误比如通过设置 slave_skip_errors1032,10621062 错误是插入数据时唯一键冲突1032 错误是删除数据时找不到行。关于搭建复制实战演示案例详情可参考链接有道云笔记