1、异步复制：这是MySQL默认的复制模式。在这种模式下，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并处理。这种模式的优点是实现简单，但缺点是如果主库崩溃，已经提交的事务可能没有传到从库，导致数据不一致。

2、全同步复制：在这种模式下，主库执行完一个事务后，需要等待所有从库都执行了该事务才能返回给客户端。这种模式的优点是数据一致性高，但缺点是性能影响较大，因为需要等待所有从库的确认。

3、半同步复制：这种模式介于异步复制和全同步复制之间。主库在执行完客户端提交的事务后，会等待至少一个从库接收到并写入relay log中才返回给客户端。这种模式提高了数据的安全性，但会造成一定的延迟。

4、增强半同步复制：这种模式在半同步复制的基础上进一步增强了数据安全性。主库将每个事务写入binlog后，等待从库刷新到磁盘才返回给客户端。这种模式的优点是进一步减少了数据丢失的风险，但缺点是可能会增加事务的延迟。

5、组复制：这种模式是一种高级的复制技术，支持多主多从架构，适用于读写参半的场景。它通过组内节点间的相互通信和投票机制来保证数据的一致性和高可用性。

本次就用两台机器node1和node2两台机器，用node1做主库，用node2做从库 。

1、获取myql镜像

# 在node1和node2上分别拉取mysql镜像，该镜像mysql版本是8.4.3，
docker pull mysql:8

2、获取默认配置文件

​ 启动容器，把配置文件copy到本地,（node1和node2同步操作） 。

# 在/opt/下创建一个mysql目录
# 临时启动一下mysql
docker run -d \
	--name mysql-master \
	-p 3306:3306 \
	-e MYSQL_ROOT_PASSWORD=123456 \
	mysql:8
	
# 把数据和配置目录copy到本地
node1上执行
docker cp mysql-master:/etc/my.cnf /opt/mysql/my.cnf
node2上执行
docker cp mysql-master:/etc/my.cnf /opt/mysql/my.cnf

3、配置启动主库

1、在node1修改主库配置文件

在node1上执行vim my.cnf ，编辑以下配置 。

[mysqld]
#mysql 服务ID，保证整个集群环境中唯一，取值范围：1 – 2的32次方-1，默认为1
server-id=1
#是否只读,1 代表当前服务器只读(不能做增删改操作), 0代表读写
read-only=0
# 设置日志格式，默认值ROW。row（记录行数据）  statement（记录sql）  mixed（混合模式）
binlog_format=STATEMENT
# 二进制日志名，默认binlog
log-bin=master_binlog
# 设置需要复制的数据库，默认复制全部数据库
#binlog-do-db=test
# 设置不需要复制的数据库
# binlog-ignore-db=test

2、在node1上启动主库

docker run -d \
	--name mysql-master \
	-p 3306:3306 \
	-e MYSQL_ROOT_PASSWORD=123456 \
	-v /opt/mysql/mysql_data:/var/lib/mysql \
	-v /opt/mysql/my.cnf:/etc/my.cnf \
	--restart=always \
	--privileged=true \
	mysql:8

3、创建主备账号：

# 创建专门用于复制的账户
CREATE USER 'backups'@'%' IDENTIFIED BY 'backups';
# 授予此帐户复制所需的权限
GRANT REPLICATION SLAVE ON *.* TO 'backups'@'%';

获取复制源二进制日志坐标 。

要配置副本在正确的点开始复制过程，您需要在二进制日志中记下源的当前坐标。要获取源二进制日志坐标，通过使用命令行客户端连接到源来启动源上的会话，并通过执行以下语句刷新所有表并阻止写入语句 。

# 刷新所有表并阻止写入语句
mysql> FLUSH TABLES WITH READ LOCK;
# 确定当前二进制日志文件的名称和位置
mysql> SHOW BINARY LOG STATUS\G

记录一下File和Position，在从库配置同步源的时候需要用到 。

3、配置启动从库

1、配置从库并启动

在node2上执行vim my.cnf ，编辑以下配置 。

[mysqld]
# 服务器唯一id，每台服务器的id必须不同，如果配置其他从机，注意修改id
server-id=2
# 中继日志名，默认xxxxxxxxxxxx-relay-bin
#relay-log=relay-bin
#是否只读,1 代表只读, 0 代表读写。对于从库来说，我们只需要从从库中进行查询即可，不需要从从库中进行写入操所>以直接把read-only设置为1就行了。
read-only=1
#二进制文件的名称
#log-bin=binlog
# 设置日志格式，默认值ROW。row（记录行数据）  statement（记录sql）  mixed（混合模式）
binlog_format=STATEMENT

2、启动从库：

docker run -d \
        --name mysql-slave \
        -p 3306:3306 \
        -e MYSQL_ROOT_PASSWORD=123456 \
        -v /opt/mysql/mysql_data:/var/lib/mysql \
        -v /opt/mysql/my.cnf:/etc/my.cnf \
        --restart=always \
        --privileged=true \
        mysql:8

3、使用复制用户请求服务器公钥

这一步是为了避免ERROR：Authentication plugin ‘caching_sha2_password‘ reported error:Authentication错误的 。

mysql -u backups -pbackups -h 10.10.10.11 -P3306 --get-server-public-key

执行完之后需要退出当前mysql终端使用root账号进行下面设置 。

设置从库的同步源 。

mysql> CHANGE REPLICATION SOURCE TO
    ->     SOURCE_HOST='10.10.10.11',
    ->     SOURCE_USER='backups',
    ->     SOURCE_PASSWORD='backups',
    ->     SOURCE_LOG_FILE='master_binlog.000003',
    ->     SOURCE_LOG_POS=697;

管理从库的同步复制状态 。

# 暂停副本上的复制
mysql> STOP REPLICA;
# 开始副本上的复制
mysql> START REPLICA;
# 检查单个副本的状态
SHOW REPLICA STATUS\G


Replica_IO_State：副本的当前状态
Replica_IO_Running：读取源二进制日志的 I/O（接收器）线程是否正在运行。通常情况下为Yes，除非您尚未启动复制或已明确停止复制，否则您希望此线程处于运行状态STOP REPLICA。
Replica_SQL_Running：执行中继日志中事件的SQL线程是否正在运行。与I/O线程一样，这通常应该是Yes。
Last_IO_Error, Last_SQL_Error：处理中继日志时I/O（接收方）和SQL（应用方）线程记录的最后错误。理想情况下，这些应该是空白的，表示没有错误。
Seconds_Behind_Source：复制SQL（应用程序）线程处理源二进制日志所落后的秒数。数字过大（或不断增加）可能表示副本无法及时处理来自源的事件。值为0，Seconds_Behind_Source通常可以解释为副本已赶上源；但在某些情况下这并不完全正确。例如，如果源和副本之间的网络连接中断，但复制 I/O（接收器）线程尚未注意到这一点，即设置的时间段 replica_net_timeout尚未过去，则可能会发生这种情况。Seconds_Behind_Source无法准确反映情况。当复制 SQL（应用程序）线程赶上 I/O 时， Seconds_Behind_Source显示 0；但当复制 I/O（接收器）线程仍在排队新事件时，Seconds_Behind_Source可能会显示较大的值，直到复制应用程序线程完成执行新事件。当事件具有旧时间戳时尤其可能出现这种情况；在这种情况下，如果您在相对较短的时间内执行SHOW REPLICA STATUS 多次，您可能会看到此值在 0 和相对较大的值之间反复来回变化。

详细执行流程看下图 。

在从库执行 SHOW REPLICA STATUS\G 之后看下面的Replica_IO_State状态显示：Waiting for source to send event， Replica_IO_Running: Yes，Replica_SQL_Running: Yes，说明复制状态正常 。

在主库执行 SHOW PROCESSLIST \G,

检查正在运行的进程列表来检查连接的副本的状态。副本连接包含Command字段为：Binlog Dump
SHOW PROCESSLIST \G;

主库看到这个进程，说明主库Binlog Dump进程启动 。

4、测试

1、连接主库和从库

2、在主库创建test库和user表，并插入三条数据

# 创建test库
create database test;
use test;
# 在test库中创建user表
create table user(
  id int(11) primary key not null auto_increment,
  name varchar(50) not null,
  sex varchar(1),
  age int(11)
)engine=innodb default charset=utf8mb4;
# 插入三条数据
insert into user(id,name,sex,age) values(null,'张三', '1',18),(null,'李四','0',19),(null,'王五','1',20);

3、查看node2上的从库是否同步

至此，主从同步已经完成，如果需要一主多从，只需要在多部署几个从库，按照上面从库的部署方式就可以了 。

如果感觉写的还能看，可以关注公众号，会将最新消息推送给你 。

最后此篇关于mysql主从复制详细部署的文章就讲到这里了,如果你想了解更多关于mysql主从复制详细部署的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。