19.1 主从复制介绍
19.1.1 主从存在的意义
数据备份:为了避免单点故障,增加一个从服务器,用来复制主服务器上的数据。
分担负载:将写操作在主上做,查询操作在从上做。
19.1.2 主从复制原理
① 主上将所有变更事件记录到binlog里
② 从发起请求连接主
③ 主的binlog备份线程将binlog传给从
④ 从的I/O线程将binlog解析成自己的relay log
⑤ 从的SQL线程根据relay log来执行具体的SQL语句
MySQL主从复制是一个异步的复制过程,主库发送更新事件到从库,从库读取更新记录,并执行更新记录,使得从库的内容与主库保持一致。
binlog:binary log,主库中保存所有更新事件日志的二进制文件。binlog是数据库服务启动的一刻起,保存数据库所有变更记录(数据库结构和内容)的文件。在主库中,只要有更新事件出现,就会被依次地写入到binlog中,之后会推送到从库中作为从库进行复制的数据源。
binlog dump线程:每当有从库连接到主库的时候,主库都会创建一个线程然后发送binlog内容到从库。对于每一个即将发送给从库的sql事件,binlog dump线程会将其锁住。一旦该事件被线程读取完之后,该锁会被释放,即使在该事件完全发送到从库的时候,该锁也会被释放。
在从库中,当复制开始时,从库就会创建从库I/O线程和从库的SQL线程进行复制处理。
从库I/O线程:当START SLAVE语句在从库开始执行之后,从库创建一个I/O线程,该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件,其中包括relay log文件。
从库的SQL线程:从库创建一个SQL线程,这个线程读取从库I/O线程写到relay log的更新事件并执行。
19.2 搭建主从复制
19.2.1 基于二进制日志文件位置的复制
① 根据我们前面的文档,搭建两台MySQL服务,具体步骤略
192.168.222.128 主 192.168.222.132 从
② 检查并配置两台机器的server_id
vi my.cnf #搜索server_id ,如果没有则增加 主上设置为 server_id = 1 从上设置为 server_id = 2
③ 在主上创建用作主从复制的用户
create user 'rep'@'192.168.222.132' identified with 'mysql_native_password' by 'AmingLinux.Com'; grant REPLICATION SLAVE on *.* to 'rep'@'192.168.222.132'; flush privileges;
④ 在主上查询日志名字以及位置
show master status; ##记录下对应的日志命令以及位置 +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | aminglinux.000001 | 853| | | +------------------+----------+--------------+------------------+
⑤ 到从上执行
change master to master_host='192.168.222.128',master_user='rep',master_password='AmingLinux.Com',master_log_file='aminglinux.000001',master_log_pos=853; start slave; show slave statusG
19.2.2 基于GTID的主从复制
1. 什么是GTID
GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识,保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增。下面是一个GTID的具体形式:
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
2. GTID的作用
根据GTID可以知道事务最初是在哪个实例上提交的,GTID的存在方便了Replication的Failover(故障切换)
3. GTID比传统复制的优势
更简单的实现failover,不用以前那样在需要找log_file和log_Pos。更简单的搭建主从复制。比传统复制更加安全。GTID是连续没有空洞的,因此主从库出现数据冲突时,可以用添加空事物的方式进行跳过。
4. GTID的工作原理:
① master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。
② slave端的i/o线程将变更的binlog,写入到本地的relay log中。
③ sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。
④ 如果有记录,说明该GTID的事务已经执行,slave会忽略。
⑤ 如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog。
⑥ 在解析过程中会判断是否有主键,如果有就用二级索引,如果没有就用全部扫描。
4. GTID复制搭建
由于之前做过主从配置,可以先取消之前的主从。
slave上执行:
stop slave; reset slave all;
master上执行:
reset master;
① 主上修改配置文件,重启mysql服务
server_id = 1 gtid_mode = on enforce_gtid_consistency=on log_bin=mysql-bin binlog_format=row log-slave-updates=1 skip-slave-start=1
② 从上修改配置文件,重启mysql服务
server_id = 2 gtid_mode = on enforce_gtid_consistency=on log_bin=mysql-bin binlog_format=row log-slave-updates=1 skip-slave-start=1
③ 主上授权用户
create user 'rep'@'192.168.222.132' identified with 'mysql_native_password' by 'AmingLinux.Com'; grant REPLICATION SLAVE on *.* to 'rep'@'192.168.222.132'; flush privileges;
④ 从上配置主从
stop slave; CHANGE MASTER TO MASTER_HOST='192.168.222.128', MASTER_USER='rep',MASTER_PASSWORD='AmingLinux.Com',MASTER_AUTO_POSITION=1,MASTER_CONNECT_RETRY=10; start slave;
④ 查看主从状态
从上执行
show slave statusG
⑤ 测试主从
主上新建一个数据库
create database testd;
到从上查看是否有testd数据库
show databases;
全部0条评论
快来发表一下你的评论吧 !