MySQL主从复制
- MySQL主从复制
- 主从复制与读写分离的意义
- 主从数据库实现同步(主从复制)
- 三台mysql服务器搭建主从复制,要求不可以用root帐号同步,要求第三台服务器在测试过1、2的主从复制之后进行主从复制配置
- 四台mysql服务器(m1,s1,m2,s2)的主从复制,两主两从,s1是m1的从,m2是s1从,s2是m2的从
- 优势
- 劣势
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=allmysql(slave1):
server-id=2
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=allmysql(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=allmysql(slave1):
server-id=2
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=allmysql(master2):
server-id=3
log-bin=mysql-bin
log-slave-updates
slave-skip-errors=allmysql(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分别为它们的从服务器,这样的设置有其特定的优势与劣势:
优势
-
高可用性:此配置提高了系统的整体可用性。如果其中一个主服务器(比如m1)发生故障,s1作为其从服务器可以迅速提升为主服务器,同时m2仍然在服务,保证了数据的连续访问。同理,m2故障时,m1和s1组合也能保持服务。
-
负载均衡:通过在两个主服务器上分担读写操作,可以有效减轻单个服务器的压力,实现负载均衡,提高处理能力。
-
数据冗余:每个主服务器的数据都会被至少一个从服务器复制,提供了数据冗余,增强了数据安全性。即使某个服务器硬件故障导致数据丢失,也能从其他服务器恢复。
-
可扩展性和灵活性:这种结构易于扩展,可以根据需要添加更多的从服务器来处理读取密集型操作,或调整复制链路以适应不同的流量模式。
劣势
-
复杂性增加:相比于单一主从结构,双主双从结构的管理和维护更加复杂。需要监控多个服务器间的复制状态,解决可能出现的冲突,以及确保数据一致性。
-
数据不一致风险:在双主模式下,如果不恰当管理,可能会出现数据冲突或不一致的问题。尤其是在双向复制(即m1和m2互相复制)未正确配置时,容易引发循环复制问题。
-
资源消耗:多服务器架构会增加网络带宽、存储空间和计算资源的需求,尤其是在数据同步过程中,可能会对系统性能产生影响。
-
故障恢复复杂:当主服务器发生故障时,需要手动干预来提升从服务器的角色,并重新配置复制关系,这相比单一主从结构更复杂且容易出错。
-
延迟问题:数据在多个节点间复制可能会引入延迟,对于实时性要求较高的应用可能会影响用户体验。
总之,双主双从的MySQL复制架构提供了更高的可用性和扩展性,但同时也带来了复杂度、数据一致性维护和资源消耗等挑战。在实际部署时,应根据业务需求、资源条件和技术能力综合考虑。