一、复制概述

二、二进制日志格式

三、复制的配置

3.1 配置主库

3.2 配置从库

3.3 创建复制专用用户

3.4 同步数据

3.5 将从库指向主库并启动复制：

一、复制概述

MySQL的复制就是将来自一个MySQL数据库服务器（主库）的数据复制到一个或多个MySQL数据库服务器（从库）。其工作原理是通过binlog（二进制日志）记录事务变更然后传送到从库并重放事务，保持数据一致。

复制的主要步骤如下：

主库事务提交，MySQL将事务变更记录到binlog。
主库上日志转储线程（binlog dump）将日志传递给从库I/O线程。
从库I/O线程将日志中的事件记录到本地的中继日志中（relay log）。
从库SQL线程从中继日志中读取事务，应用变更，保持数据和主库一致。

示意图：

如果binlog dump线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被唤醒，备库I/O线程会将接收到的事件记录到中继日志中。

使用复制可以带来如下好处：

复制可以将读操作分布到多个服务器上，对读密集型业务有更好的承载能力。
由于读的压力分离至从库，主库可以分配更多的资源来响应写请求。
提高安全，可以利用延迟复制等特性，快速恢复主库上的误操作。
高可用，复制+故障切换系统，可以让系统宕机时快速恢复，响应请求。

二、二进制日志格式

二进制日志在记录事务变更时有statement、row、mixed三种格式，通过binlog_format系统变量来设置：

statement

基于SQL语句的复制（Statement-Based Replication，SBR），将修改数据的SQL语句都会被记录到binlog中，优点是不需要记录每行的数据变化，这样二进制日志会比较少。缺点是在某些情况下不能很好工作，例如last_insert_id()、now()等非确定性函数，以及用户自定义函数（User-Defined Function，UDF）、存储过程、触发器时也易出问题。

row（推荐，也是MySQL8默认的日志格式）

基于行的复制（Row-Based Replication，RBR）。该格式不记录SQL语句，仅记录哪条数据被修改了，修改成了什么样子，能清楚地记录每一行数据的修改前后细节。优点是不会出现某些特定情况下的存储过程、函数或触发器的调用和触发无法被正确复制的问题。缺点是通常会产生大量的日志。

mixed

混合复制（Mixed-Based Replication，MBR）。它是STATEMENT和ROW这两种格式的混合体，默认使用STATEMENT格式保存二进制日志，对于STATEMENT格式无法正确复制的操作，会自动切换到基于ROW格式的复制操作，MySQL会根据执行的SQL语句选择日志保存方式。

二进制日志除了复制还会在数据库故障崩溃时进行恢复使用，因此建议将二进制日志和数据文件保存在不同的磁盘，减少I/O争用。三种日志格式中，理论上基于行的复制（row）更优，因为几乎没有基于行的复制模式无法处理的场景。对于所有的SQL构造、触发器、存储过程等都能正确执行，这也是MySQL8默认的日志格式。

三、复制的配置

MySQL最基本的复制是单路、异步、基于日志位置的复制。其架构是1台主库，1台或多台从库通过指定日志文件及位置连接到主库。

现有2台数据库环境如下，示例基本异步复制的配置步骤：

192.168.3.71（主库主机名master）
192.168.3.72（从库主机名slave01）

3.1 配置主库

为主库配置唯一的server_id并打开二进制日志，配置数据库配置文件（Redhat/CentOS默认是/etc/my.cnf）在[mysqld]选项下加入下列参数：

[mysqld]
server_id=71
log_bin = bin-log
sync_binlog = 1
innodb_flush_log_at_trx_commit =1

其中server_id和log_bin参数是必选，其他参数是可选项，根据自身需要选择：

server_id需要在整个复制拓扑中保持唯一，一种通用的建议是采用IP地址的后8位，只要遵循某种规则保持唯一即可。
log_bin用于打开二进制日志并明确指定日志名称，默认日志采用主机名命名，建议明确指定日志名，否则后期主机更名容易带来问题。
sync_binlog（强烈推荐）保证每次提交事务会将binlog同步到磁盘，保证服务器崩溃时不丢失事务，还可以防止主从不一致。
innodb_flush_log_at_trx_commit 保证每次提交事务Innodb将日志写入redo log，只针对innodb表。

3.2 配置从库

修改从库的配置参数，必要时重启服务器。在[mysqld]选项下加入下列参数：

server_id = 72
relay_log = relay-bin
log_bin = bin-log
log_slave_updates = 1
read_only = 1
skip_slave_start = 1

上面的配置只有server_id=72是必须的，其他都是可选项，自己可以根据需要选择：

relay_log用于指定中继日志名称以避免主机更名带来的问题。
log_bin和log_slave_update用来控制slave在复制时同时也将事件写入自己的二进制日志（级联复制使用）。
read_only=1备库建议开启，用来防止普通用户修改数据，但具有super权限的用户依然是可以修改的。
skip_slave_start阻止备库启动时自动开启复制，如果备库在崩溃后处于不一致的状态下自动启动复制，可能会导致更多的损坏。

3.3 创建复制专用用户

在主库上创建用户并赋予replication slave权限：

create user 'repuser'@'192.168.3.%' identified  by 'repP@ssword';
grant replication slave on *.* to 'repuser'@'192.168.3.%';

3.4 同步数据

大部分情况下主库都是都不是空的，这就需要在开启复制前获取主库的快照并还原到从库，保证复制开始时数据一致。主要方法有3种：

直接复制数据文件（需要关闭主库暂停业务）
使用mysqldump工具转储（便捷、但数据量大时速度较慢）
使用xtrabackup等第三方工具转储（便捷、速度较快）

第一种方法由于需要关库，意味着业务要生产业务要暂停，通常不会采用。第二种采用mysqldump转储，适合数据量中等的情况。如果不能关库，采用mysqldump转储又太慢，可以试着采用第三方工具xtrabackup，由于是采用物理层面的数据文件备份，所以速度比mysqldump快很多。

下面示例采用mysqldump转储的方式，在主库开启一个会话执行下面语句：

flush tables with read lock;
show master status;

第一句会阻止所有的数据库变更，第二句显示当前的日志名称和位置，记录下来，这个就是复制的起点。

此时，另开一个会话获取数据快照，注意备份时第一个执行flush table with read lock的会话不能退出，否则可能会发生数据变更。

mysqldump --all-databases --master-data > dbdump.sql

导出之后第一个会话就可以退出了，或者执行unlock tables，让主库继续执行业务。

将上述转储文件传输到备库并导入：

scp dbdump.sql root@'192.168.3.72':/root

登录到备库上还原数据，此时主备库的数据已经相同，可以启动复制了：

mysql < dbdump.sql

3.5 将从库指向主库并启动复制：

在从库上执行change master to（8.0.23版本以上使用change replication source to），指定主库位置及我们在第三步建立的复制用户：

change master to
master_host = '192.168.3.71',
master_user='repuser',
master_password='repP@ssword',
master_log_file='mysql-bin.000009',
master_log_pos=1174;

最后两句master_log_file,master_log_pos就是上一步主库show master status显示的日志名和偏移量，由于我们在转储时加了--master-data选项，所以备份文件中自动会带上这个坐标，不加也可以。

启动复制：

start slave;
show slave status \G;

start slave 语句会启动从库上的I/O线程和SQL线程，并且连接到主库（主库上启动binlog dump线程）。

show slave status，我们可以看到备库的I/O和SQL线程都已经起来了，Slave_IO_State显示正在等待主库发送更多的事件。MySQL的基础异步复制就完成了。

MySQL复制（一）：异步复制（Asynchronous replication）相关推荐

MySQL性能半同步复制VS异步复制
性能测试报告 •从当前性能测试来看其实半同步复制与异步复制差距并不大,只是略微有点差距 •都说半同步复制比异步复制性能慢了好多,为什么当前测试却差距这么小呢? 原因一:半同步复制时只有一个slave库 ...
MySQL 8.0 异步复制的三种方式
本实验中分别针对空库.脱机.联机三种方式,配置一主两从的mysql标准异步复制.只做整服务器级别的复制,不考虑对个别库表或使用过滤复制的情况. 实验环境 [root@slave2 ~]# cat /e ...
mysql同步和异步区别是什么_mysql同步复制和异步复制的区别是什么？
区别:1.异步复制是Master将事件写入binlog,自身并不知道slave是否接收是否处理,不能保证所有事务都被所有slave接收:2.同步复制是Master提交事务,直到事务在所有slave都已 ...
rocketmq 同步刷盘和异步刷盘以及主从复制之同步复制和异步复制你理解了吗
同步刷盘.异步刷盘 RocketMQ的消息是存储到磁盘上的,这样既能保证断电后恢复,又可以让存储的消息量超出内存的限制. RocketMQ为了提高性能,会尽可能地保证磁盘的顺序写.消息在通过Produ ...
RocketMQ高可用机制----同步刷盘、异步刷盘和同步复制、异步复制
RocketMQ高可用机制----同步刷盘.异步刷盘和同步复制.异步复制同步刷盘.异步刷盘 RocketMQ的消息是存储到磁盘上的,这样既能保证断电后恢复,又可以让存储的消息量超出内存的限制. Ro ...
Mysql进阶(1)——异步复制(主从复制、Gtid复制)、半同步复制
前言原理总结异步复制:在主节点写入日志即返回成功,默认情况下MySQL5.5/5.6/5.7和mariaDB10.0/10.1的复制功能是异步的.异步复制可以实现最佳的性能,主库把binlog日志 ...
mysql：安装 / 主从复制简介 / 异步复制
######1.安装mysql###### ###1.获得安装包,解压### ###2.安装### ###3.查看数据库初始密码,安全初始化### grep password /var/log/m ...
mysql主从中异步和半同步的区别
MySQL主从复制,默认是异步复制.异步复制,即master执行完事物并提交后,二进制日志记录完这些更新操作后,就又开始下一批事物.并不关心这些更新是否被复制到从上. 而半同步复制则相反,它需要等待至 ...
mysql异步复制参数_MySQL Replication(异步复制)基本原理
1.复制进程 Mysql的复制(replication)是一个异步的复制,从一个Mysql instace(称之为Master)复制到另一个Mysql instance(称之Slave).实现整个复制 ...

MySQL复制（一）：异步复制（Asynchronous replication）

一、复制概述

二、二进制日志格式

三、复制的配置

3.1 配置主库

3.2 配置从库

3.3 创建复制专用用户

3.4 同步数据

3.5 将从库指向主库并启动复制：

MySQL复制（一）：异步复制（Asynchronous replication）相关推荐

最新文章

热门文章