本文详细介绍了MySQL主从复制的工作原理，包括优点、配置步骤、GTID模式的应用以及注意事项，如UUID一致性对复制的影响。
目录
主从复制（gtid方式）-------实验环境要求： 5.7.6 以上版本
概述：
主从复制（也称 AB 复制）允许将来自一个MySQL数据库服务器（主服务器）的数据复制到一个或多个MySQL数据库服务器（从服务器，是将主数据库中的DML和DDL操作通过二进制日志传到从服务器中，然后在从库上对这些日志重新执行（也叫重做），从而使得从数据库和主数据库保持同步。根据配置，您可以复制数据库中的所有数据库，所选数据库甚至选定的表。
主从复制优点：
MySQL主从复制的优点包括：
-
横向扩展解决方案 - 在多个从站之间分配负载以提高性能。在此环境中，所有写入和更新都必须在主服务器上进行。但是，读取可以在一个或多个从设备上进行。该模型可以提高写入性能（因为主设备专用于更新），同时显着提高了越来越多的从设备的读取速度。
-
数据安全性 - 因为数据被复制到从站，并且从站可以暂停复制过程，所以可以在从站上运行备份服务而不会破坏相应的主数据。
-
分析 - 可以在主服务器上创建实时数据，而信息分析可以在从服务器上进行，而不会影响主服务器的性能。
-
备份 - 可以使用从服务器数据进行备份，减轻主服务器的压力。
-
1.主库出现问题时，可以快速切换到从库提供服务。
2.实现读写分离，降低之库的访问压力。
3.可以在从库中执行备份，以避免备份期间影响主库。
原理
原理: 主服务器上面的任何修改都会保存在二进制日志（ Bin-log日志） 里面。 从服务器上面启动一个I/O线程， 连接到主服务器上面请求读取二进制（Bin-log）日志，然后把读取到的二进制日志写到本地的Realy-log（中继日志）里面。 从服务器上面同时开启一个SQL线程，读取Realy-log（中继日志），如果发现有更新立即把更新的内容在本机的数据库上面执行一遍。
搭建主从复制
一.准备工作
准备两台服务器并且关闭防火墙和selinux。
[root@master ~]# systemctl stop firewalld
[root@master ~]# systemctl disable firewalld
[root@master ~]# setenforce 0
setenforce: SELinux is disabledmaster：192.168.134.148
slave：192.168.134.149
yum安装数据库参考MySQL介绍与安装部署_鲨鱼卖辣椒--的博客-CSDN博客
两台安装好数据库初始化并且修改密码
#初始化数据库
[root@slave ~]# systemctl start mysqld
# 修改初始密码
[root@slave ~]# mysqladmin -p"`awk '/temporary password/{p=$NF}END{print p}' /var/log/mysqld.log`" password '001122'注：awk '/temporary password/{p=$NF}END{print p}' /var/log/mysqld.log #取出初始化的临时密码。
二.主库配置
- 修改配置文件在[mysqld]下面添加server-id和log-bin二进制文件路径。
# 配置mysql配置文件
[root@master ~]# vim /etc/my.cnf
[mysqld]
server-id=148
log-bin=/var/log/mysql/mysql-bin ###mysql-bin为二进制日志的前缀
- 创建binlog日志存放路径并且授权
[root@master ~]# mkdir /var/log/mysql
[root@master ~]# chown -R mysql.mysql /var/log/mysql- 重启mysql
[root@master ~]# systemctl restart mysqld
- 查看master的状态，file和position信息之后需要在从库中配置。
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000004
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)
- 创建一个主从复制的授权账号
mysql> grant replication slave on *.* to 'aren'@'192.168.134.%' identified by "001122";
mysql> flush privileges;三.从库配置
- 修改从库的mysql配置文件在[mysqld]下面添加server-id，配置完成后重启数据库。
[root@slave ~]# vim /etc/my.cnf
[mysqld]
server-id=149
[root@slave ~]# systemctl restart mysqld
- 在从服务器配置连接到主服务器的相关信息
# 配置从库
mysql> change master to
-> master_host='192.168.134.148', #主库IP，也可以是域名解析
-> master_port=3306, #端口
-> master_user='aren',
-> master_password='001122',
-> master_log_file='mysql-bin.000001',
-> master_log_pos=145;- 启动slave
mysql> start slave;- 查看slave状态
mysql> show slave status\G
如果想在从库中修改链接信息应当先停止从库slave，在执行reset slave；之后在修改链接信息。
mysql>stop slave;
mysql>reset slave;
mysql>mysql> change master to
-> master_host='192.168.134.148', #主库IP，也可以是域名解析
-> master_port=3306, #端口
-> master_user='aren',
-> master_password='001122',
-> master_log_file='mysql-bin.000001',
-> master_log_pos=145;
mysql>start slave;
主从复制有数据写入时
！！！！注意：当主从复制时数据仍然在写入应当先锁表备份然后查看master的状态记录file和position的信息，完成主从复制后再将表解锁。
锁表：
mysql> flush tables with read lock;解表：
mysql> unlocak tables;主从复制（gtid方式）-------实验环境要求： 5.7.6 以上版本
基于事务的Replication，就是利用GTID来实现的复制
GTID（全局事务标示符）最初由google实现，在MySQL 5.6中引入.GTID在事务提交时生成，由UUID和事务ID组成.uuid会在第一次启动MySQL时生成，保存在数据目录下的auto .cnf文件里，事务ID则从1开始自增使用GTID的好处主要有两点：
-
不再需要指定传统复制中的master_log_files和master_log_pos，使主从复制更简单可靠
-
可以实现基于库的多线程复制，减小主从复制的延迟
主库配置
- 配置mysql配置文件
[root@master ~]# vim /etc/my.cnf
[mysqld]
server-id=148
#打开gtid模式
log-bin=/var/log/mysql/mysql-bin
gtid_mode=ON
enforce_gtid_consistency=1
##重启mysql
[root@master ~]# systemctl restart mysqld
- 创建专属用户并授权
mysql> GRANT REPLICATION SLAVE ON *.* TO 'aren'@'192.168.134.%' identified by '001122';从库配置
- 测试用户链接
[root@slave ~]# mysql -uaren -p001122 -h192.168.134.148
连接成功，退出
- 在从库的mysql配置文件中打开gtid模式
[root@slave ~]# vim /etc/my.cnf
[mysqld]
server-id=149
gtid_mode=ON
enforce_gtid_consistency=1
#重启mysql
[root@slave ~]# systemctl restart mysqld
- Mysql 从服务器终端执行连接信息
mysql>CHANGE MASTER TO
MASTER_HOST='192.168.134.148',
MASTER_USER='aren',
MASTER_PASSWORD='001122',
MASTER_AUTO_POSITION=1;
#启动slave
> start slave;- 查看是否同步成功。
mysql> show slave status\G
可以看到Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 表示同步成功。
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.134.148
Master_User: aren
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 154
Relay_Log_File: slave-relay-bin.000002
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
注意：
开启 GTID 后的导出导入数据的注意点：
当执行 [root@master ~]# mysqldump -uroot -p224216 -A > /opt/all.sql 时会报错。
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.意思是： 当前数据库实例中开启了 GTID 功能, 在开启有 GTID 功能的数据库实例中, 导出其中任何一个库, 如果没有显示地指定--set-gtid-purged参数, 都会提示这一行信息. 意思是默认情况下, 导出的库中含有 GTID 信息, 如果不想导出包含有 GTID 信息的数据库, 需要显示地添加--set-gtid-purged=OFF参数.
[root@master ~]# mysqldump -uroot -p224216 --set-gtid-purged=OFF -A > /opt/all.sql
添加--set-gtid-purged=OFF参数后可以正常导入导出了。
UUID一致，导致主从复制I/O线程不是yes
致命错误：由于master和slave具有相同的mysql服务器uuid，导致I/O线程不进行；这些uuid必须不同才能使复制工作。
当我们检查过主库和从库server-id 不一样，还有aster_Log_File 和 Read_Master_Log_Pos 都与主库一致时；最后检查发现他们的auto.cnf中的server-uuid是一样的。只需要修改从库的uuid并重启服务。
#生成新的uuid并修改从库的uuid
[root@slave ~]# uuidgen
7f0296a5-41c9-4523-b544-a29c0b6cc34e
[root@slave ~]# vim /var/lib/mysql/auto.cnf
[auto]
server-uuid=7f0296a5-41c9-4523-b544-a29c0b6cc34e
扫一扫
1341
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
