mysql 主从复制详细部署

1、异步复制：这是MySQL默认的复制模式。在这种模式下，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并处理。这种模式的优点是实现简单，但缺点是如果主库崩溃，已经提交的事务可能没有传到从库，导致数据不一致。
2、全同步复制：在这种模式下，主库执行完一个事务后，需要等待所有从库都执行了该事务才能返回给客户端。这种模式的优点是数据一致性高，但缺点是性能影响较大，因为需要等待所有从库的确认。
3、半同步复制：这种模式介于异步复制和全同步复制之间。主库在执行完客户端提交的事务后，会等待至少一个从库接收到并写入relay log中才返回给客户端。这种模式提高了数据的安全性，但会造成一定的延迟。
4、增强半同步复制：这种模式在半同步复制的基础上进一步增强了数据安全性。主库将每个事务写入binlog后，等待从库刷新到磁盘才返回给客户端。这种模式的优点是进一步减少了数据丢失的风险，但缺点是可能会增加事务的延迟。
5、组复制：这种模式是一种高级的复制技术，支持多主多从架构，适用于读写参半的场景。它通过组内节点间的相互通信和投票机制来保证数据的一致性和高可用性。

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

# 在/opt/下创建一个mysql目录# 临时启动一下mysqldocker 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.cnfnode2上执行docker cp mysql-master:/etc/my.cnf /opt/mysql/my.cnf

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

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

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

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

[mysqld]# 服务器唯一id，每台服务器的id必须不同，如果配置其他从机，注意修改idserver-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

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

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

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 和相对较大的值之间反复来回变化。

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

# 创建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);