数据复制

配置与使用

创建账号

主库会通过创建账号的方式，赋予一些权限给复制线程，用以实现传输binlog文件。需要在主库上创建账号并赋予REPLICATION SLAVE权限。

从库通过该账户登录主库并获取binlog文件。

建议同时在从库上配置相同的账户，原因在于：

• 监控、管理功能依赖该权限
• 相同的配置，有利于方便的进行主从交换

配置

需要在主库中开启binlog，并指定serverID，my.cnf中配置如下：

从库中也需要对my.cnf文件进行配置

启动复制

在从库中执行，用于执行一些基本的准备工作： 此时复制还没有开始，同过show slave status可以看到状态。

使用start slave开始复制：

接入正在运行的数据库

推荐的配置

工作流程

1、主服务器MySQL服务将所有的写操作记录在 binlog 日志中，并生成 log dump 线程，将 binlog 日志传给从服务器MySQL服务的 I/O 线程。

2、从服务器MySQL服务生成两个线程，一个是 I/O 线程，另一个是 SQL 线程。

3、从库 I/O 线程去请求主库的 binlog 日志，并将 binlog 日志中的文件写入 relaylog（中继日志）中。

4、从库的 SQL 线程会读取 relaylog 中的内容，并解析成具体的操作，来实现主从的操作一致，达到最终两个数据库数据一致的目的。

拓扑结构

• 一主一从
• 主主复制
• 一主多从-- 扩展系统读取的性能，因为读是在从库读取的
• 多主一从
• 联级复制

复制模式

异步复制

一个主库，一个或多个从库，数据异步同步到从库。

异步复制

这种模式下，主节点不会主动推送数据到从节点，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理。

这样就会有一个问题，主节点如果崩溃掉了，此时主节点上已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整。

同步复制

在 MySQL cluster 中特有的复制方式。

当主库执行完一个事务，然后所有的从库都复制了该事务并成功执行完才返回成功信息给客户端。

因为需要等待所有从库执行完该事务才能返回成功信息，所以全同步复制的性能必然会收到严重的影响。

半同步复制

在异步复制的基础上，确保任何一个主库上的事物在提交之前至少有一个从库已经收到该事物并日志记录下来。

半同步复制

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到 relay log 中才返回成功信息给客户端(只能保证主库的 Binlog 至少传输到了一个从节点上)，否则需要等待直到超时时间然后切换成异步模式再提交。

相对于异步复制，半同步复制提高了数据的安全性，一定程度的保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。

半同步模式不是 MySQL 内置的，从 MySQL 5.5 开始集成，需要 master 和 slave 安装插件开启半同步模式。

延迟复制

在异步复制的基础上，人为设定主库和从库的数据同步延迟时间，即保证数据延迟至少是这个参数。

数据分区

数据分片 负载均衡

高可用

单点失效 故障转移 崩溃恢复