---

MySQL主从复制

主从复制与读写分离的意义

企业中的业务通常数据量都比较大，而单台数据库在数据存储、安全性和高并发方面都无法满足实际的需求，所以需要配置多台主从数据服务器，以实现主从复制，增加数据可靠性，读写分离，也减少数据库压力和存储引擎带来的表锁定和行锁定问题。

主从数据库实现同步（主从复制）

什么是主从复制？简单来说就是在主服务器上执行的语句，从服务器执行同样的语句，在主服务器上的操作在从服务器产生了同样的结果。

主从复制的基本过程如下:

• Master（主数据库）将用户对数据库更新的操作以二进制格式保存到BinaryLog日志文件中。

• Slave（从数据库）上面的IO进程连接上Master， 并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容。

• Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。

• Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master “我需要从某个bin- log的哪个位置开始往后的日志内容，请发给我”。

• Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay- log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

三台mysql服务器搭建主从复制，要求不可以用root帐号同步，要求第三台服务器在测试过1、2的主从复制之后进行主从复制配置

# 0.架构规划
192.168.99.116 master 主节点
192.168.99.117 slave1 从节点
192.168.99.118 slave2 从节点
# 1.修改mysql的配置文件
 vim /etc/my.cnf
# 2.分别在配置文件中加入如下配置
mysql(master):
server-id=1
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

mysql(slave1):
server-id=2
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

mysql(slave2):
server-id=3
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

# 3.重启mysql服务
systemctl restart mysqld
# 4.登录mysql执行如下命令检测配置是否生效
SHOW VARIABLES like 'server_id';

# 5.登录master节点执行如下命令
show master status;
create user 'namida' @'localhost' identified by 'Namida@123';

主数据库授权

 grant all privileges on *.* to 'namida'@'%' identified by 'Namida@123' with grant option;

# 6.登录从节点执行如下命令:
change master to
master_host='192.168.99.116',
master_user='namida',
master_password='Namida@123',
master_log_file='mysql-bin.000006',
master_log_pos=454;

# 7.开启从节点
start slave;
#关闭 stop slave;

# 8.查看从节点状态
show slave status\G;

slave1：

slave2

# 9.通过客户端工具进行测试

在master上新建数据库和表

slave同步数据

注意:如果出现Slave I/O: Fatal error: The slave I/O thread stops because master and slave have
equal MySQL server UUIDs; these UUIDs must be different for replication to work.
Error_code: 1593错误,请执行如下命令,rm -rf /var/lib/mysql/auto.cnf删除这个文件,之所以会出现这样的问题，是因为我的从库主机是克隆的主库所在的主机，所以auto.cnf文件中保存的UUID会出现重复.

四台mysql服务器(m1,s1,m2,s2)的主从复制，两主两从，s1是m1的从，m2是s1从，s2是m2的从

# 0.架构规划
192.168.99.116 master1 主节点1
192.168.99.117 slave1 从节点1
192.168.99.118 master1 主节点1
192.168.99.119 slave2 从节点
# 1.修改mysql的配置文件
 vim /etc/my.cnf
# 2.分别在配置文件中加入如下配置
mysql(master1):
server-id=1
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

mysql(slave1):
server-id=2
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

mysql(master2):
server-id=3
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

mysql(slave2):
server-id=4
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=all

# 3.重启mysql服务
systemctl restart mysqld
# 4.登录mysql执行如下命令检测配置是否生效
SHOW VARIABLES like 'server_id';

# 5.登录master1、slave1、master2节点执行如下命令
show master status;
create user 'namida' @'localhost' identified by 'Namida@123';

# 6.登录主节点1、从节点1、2执行如下命令:
change master to
master_host='192.168.99.116',
master_user='namida',
master_password='Namida@123',
master_log_file='mysql-bin.000006',
master_log_pos=454;

change master to
master_host='192.168.99.117',
master_user='namida',
master_password='Namida@123',
master_log_file='mysql-bin.000001',
master_log_pos=1217;

change master to
master_host='192.168.99.118',
master_user='namida',
master_password='Namida@123',
master_log_file='mysql-bin.000001',
master_log_pos=1772;

# 7.开启从节点
start slave;

测试：
master1

slave1

master2

slave2

部署一个由四台MySQL服务器构成的双主双从复制架构（m1, s1, m2, s2），其中m1和m2为两个主服务器，s1和s2分别为它们的从服务器，这样的设置有其特定的优势与劣势：

优势

1. 高可用性：此配置提高了系统的整体可用性。如果其中一个主服务器（比如m1）发生故障，s1作为其从服务器可以迅速提升为主服务器，同时m2仍然在服务，保证了数据的连续访问。同理，m2故障时，m1和s1组合也能保持服务。

2. 负载均衡：通过在两个主服务器上分担读写操作，可以有效减轻单个服务器的压力，实现负载均衡，提高处理能力。

3. 数据冗余：每个主服务器的数据都会被至少一个从服务器复制，提供了数据冗余，增强了数据安全性。即使某个服务器硬件故障导致数据丢失，也能从其他服务器恢复。

4. 可扩展性和灵活性：这种结构易于扩展，可以根据需要添加更多的从服务器来处理读取密集型操作，或调整复制链路以适应不同的流量模式。

劣势

1. 复杂性增加：相比于单一主从结构，双主双从结构的管理和维护更加复杂。需要监控多个服务器间的复制状态，解决可能出现的冲突，以及确保数据一致性。

2. 数据不一致风险：在双主模式下，如果不恰当管理，可能会出现数据冲突或不一致的问题。尤其是在双向复制（即m1和m2互相复制）未正确配置时，容易引发循环复制问题。

3. 资源消耗：多服务器架构会增加网络带宽、存储空间和计算资源的需求，尤其是在数据同步过程中，可能会对系统性能产生影响。

4. 故障恢复复杂：当主服务器发生故障时，需要手动干预来提升从服务器的角色，并重新配置复制关系，这相比单一主从结构更复杂且容易出错。

5. 延迟问题：数据在多个节点间复制可能会引入延迟，对于实时性要求较高的应用可能会影响用户体验。

总之，双主双从的MySQL复制架构提供了更高的可用性和扩展性，但同时也带来了复杂度、数据一致性维护和资源消耗等挑战。在实际部署时，应根据业务需求、资源条件和技术能力综合考虑。