标签：主库 主从复制 slave -- MySQL mysql 从库 data
目录
主从复制基础
主从复制简介
MySQL数据库的主从复制方案，与使用scp/rsync等命令进行的文件级别复制类似，都是数据的远程传输，只不过MySQL的主从复制是自带的功能。MySQL的主从复制并不是数据库磁盘上的文件直接拷贝，而是将二进制日志binlog复制到要同步的服务器本地，然后由本地的线程读取日志里面的SQL语句，重新应用到MySQL数据库中。
- 基于二进制日志binlog进行复制
- 主库的修改操作会记录到二进制日志文件中
- 从库会请求新的二进制日志并回放，最终达到主从数据同步
- 主从复制核心功能：辅助备份，处理数据库物理损坏
什么是逻辑损坏？drop、delete truncate等在数据库内部的误操作
什么是物理损坏？操作系统层次的损坏（数据库外部的损坏）
问：主从复制可以替代数据库的备份？
答：主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）；对逻辑损坏还是需要通过备份进行恢复。
主从复制前提
- 两台以上mysql实例 ：server_id、server_uuid不同
- 主库开启二进制日志
- 主库需建立专用的复制用户（replication slave）
- 建立主库全备（适用于主库运行很久后需要建立从库的情况），保证主从开启之前的某个时间点,从库数据和主库一致
- change master to：告知从库主库的IP、Port、user、passwd以及复制的起点（file，position）
- start slave：开启专用的复制线程（主库：binlog_dump_T 、从库：thread IO thread 、SQL thread）
主从复制搭建
主库配置（3307实例）
- 创建数据目录并赋予权限进行初始化
[root@localhost data]# mkdir /data/3307/data -p [root@localhost data]# chown -R mysql.mysql /data/3307 [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3307/data - 编辑配置文件，开启二进制日志功能
[root@localhost data]# vim /data/3307/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3307/data socket=/data/3307/mysql.sock log_error=/data/3307/mysql.log port=3307 server_id=7 log_bin=/data/3307/mysql-bin - 启动主库数据库实例3307
[root@localhost data]# systemctl start mysqld3307 [root@localhost data]# mysql -uroot -S /data/3307/mysql.sock - 检查是否开启二进制日志文件
[root@localhost ~]# ll /data/3307/mysql-bin* -rw-r-----. 1 mysql mysql 154 Oct 3 12:23 /data/3307/mysql-bin.000001 -rw-r-----. 1 mysql mysql 28 Oct 3 12:23 /data/3307/mysql-bin.index - 创建专用复制用户
[root@localhost ~]# mysql -uroot -S /data/3307/mysql.sock mysql [(none)]>grant replication slave on *.* to slave@'192.168.1.%' identified by '123456'; - 建立主库全备（若主库都是刚搭建可以省略该步骤）
[root@localhost ~]# [root@localhost ~]# mysqldump -uroot -S /data/3307/mysql.sock -A -R -E --triggers --master-data=2 --single-transaction > /data/3307/backup/full.sql 获取change master to 的信息 [root@localhost ~]# vim /data/3307/backup/full.sql -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=448; - 查看主库状态
mysql [(none)]>show master status ; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000001 | 448 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
从库配置（3308实例）
-
从库模拟恢复主库全备，保证主从开启之前的某个时间点，从库数据和主库一致
[root@localhost ~]# mysql -uroot -S /data/3308/mysql.sock mysql [mysql]>set sql_log_bin=0; mysql [mysql]>source /data/3307/backup/full.sql -
告知从库主库的IP、Port、专用复制用户的用户名和密码等信息（change master to）
查看change master to帮助信息 mysql [(none)]>help change master to CHANGE MASTER TO MASTER_HOST='master2.mycompany.com', --主库地址 MASTER_USER='replication', --用户名 MASTER_PASSWORD='bigs3cret', --密码 MASTER_PORT=3306, --端口 MASTER_LOG_FILE='master2-bin.001', --binlog MASTER_LOG_POS=4, --position MASTER_CONNECT_RETRY=10; --重复连接次数mysql [(none)]>CHANGE MASTER TO -> MASTER_HOST='192.168.1.5', -> MASTER_USER='slave', -> MASTER_PASSWORD='123456', -> MASTER_PORT=3307, -> MASTER_LOG_FILE='mysql-bin.000001', -> MASTER_LOG_POS=448, -> MASTER_CONNECT_RETRY=10; Query OK, 0 rows affected, 2 warnings (0.22 sec) -
开启主从专用线程
mysql [(none)]> start slave; -
检查复制状态
mysql [(none)]>show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.5 --主库相关信息监控 Master_User: slave Master_Port: 3307 Connect_Retry: 10 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 448 Relay_Log_File: localhost-relay-bin.000002 --从库中继日志的应用状态 Relay_Log_Pos: 320 Slave_IO_Running: Yes --从库复制线程有关状态 Slave_SQL_Running: Yes Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Do_DB: --过滤复制有关 Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Seconds_Behind_Master: 0 --主从延时相关状态（非人为） SQL_Delay: 0 --延时从库有关状态（人为） SQL_Remaining_Delay: NULL Retrieved_Gtid_Set: --GTID复制有关状态 Executed_Gtid_Set: Auto_Position: 0
主从复制原理
主从复制相关文件
- 主库：
mysql-bin.000001：二进制文件 - 从库：
localhost-relay-bin.000002：中继日志文件
master.info：主库信息
relay-log.info：中继日志信息
主从复制相关线程
- 主库：
Binlog_Dump_Thread：DT - 从库：
Slave_IO_Thread：IT
Slave_SQL_Thread：ST
主从复制图解原理
- change master to命令：主库的ip port user password binlog position写入到master.info进行记录；
- start slave 命令：从库会启动Slave_IO_Thread和Slave_SQL_Thread；
- Slave_IO_Thread读取master.info信息，获取主库信息并连接主库；
- 主库会生成一个Binlog_Dump_Thread来响应从库；
- Slave_IO_Thread根据master.info记录的binlog文件名和position号，请求主库Binlog_Dump_Thread最新日志；
- Binlog_Dump_Thread检查主库的binlog日志，如果有新日志生成，TP(传送)给从库的Slave_IO_Thread（主库一旦有新的日志生成，会发送信号给Binlog_Dump_Thread，IO线程再请求）；
- Slave_IO_Thread将收到的日志存储到了TCP/IP 缓存，并立即返回ACK给主库 ，主库工作完成；
- Slave_IO_Thread将缓存中的数据存储到relay-log中继日志文件，并更新master.info文件binlog 文件名和postion，Slave_IO_Thread工作完成；
- Slave_SQL_Thread读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log；
- Slave_SQL_Thread回放完成之后，会更新relay-log.info文件；
- relay-log有自动清理的功能。
主从故障监控/分析/处理
IO线程故障
连接主库出现问题
Slave_IO_Running：Connecting
Last_IO_Errno: 0
Last_IO_Error:
-
IP
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.55' (113) -
Port
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.5' (111) -
user，passwd
ERROR 1045 (28000): Access denied for user 'slave'@'192.168.1.5' (using password: YES) -
连接数量上限
ERROR 1040 (HY000)：Too many connections -
防火墙、网络不通
请求和接收二进制文件
故障：主库日志损坏或丢失
案例：执行reset master模拟主库日志丢失（会导致从库方面二进制日志位置点不对）
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000001' at 154, the last event read from '/data/3307/data/mysql-bin.000002' at 154, the last byte read from '/data/3307/data/mysql-bin.000002' at 154.'
注意：在主从复制环境中，严令禁止主库中reset master； 可以选择expire 进行定期清理主库二进制日志。
处理故障过程
重新搭建主从环境
- 从库停止slave服务
> stop slave; - 重置从库信息
> reset slave all; > show slave status \G - 重新搭建从库
> change master to > start slave;
SQL线程故障
SQL线程故障原因分析
- 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响；
- 要创建的数据库对象已经存在；
- 要删除或修改的对象不存在 ；
- DML语句不符合表定义及约束；
归根揭底都是由于从库发生了写入操作。
SQL县城故障模拟环境
-
从库建立一个数据库sql_error
mysql [(none)]>create database sql_error; Query OK, 1 row affected (0.03 sec) mysql [(none)]>show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sql_error | | sys | | test | +--------------------+ 6 rows in set (0.13 sec) -
主库再次建立一个sql_error数据库
mysql [(none)]>show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | | test | +--------------------+ 5 rows in set (0.29 sec) mysql [(none)]>create database sql_error; Query OK, 1 row affected (0.02 sec) -
查看从库状态，出现异常
Slave_SQL_Running: No Last_SQL_Error: Error 'Can't create database 'sql_error'; database exists' on query. Default database: 'sql_error'. Query: 'create database sql_error'
SQL线程故障处理方式
以从库为核心的处理方案
丑话说在前头：以从库为核心处理的方案是有风险的，最安全的做法就是重新构建主从。坚定把握一个原则：一切以主库为主。
- 方法一：sql_slave_skip_counter=1;(有风险)
mysql [(none)]>stop slave; Query OK, 0 rows affected (0.01 sec) mysql [(none)]>set global sql_slave_skip_counter=1; # 将同步指针移到下一个，如果多次不同步，可以重复操作 Query OK, 0 rows affected (0.00 sec) mysql [(none)]>start slave; Query OK, 0 rows affected (0.11 sec) - 方法二：编辑配置文件跳过指定错误（生产环境不允许）
vim my.cnf slave-skip-errors = 1032,1062,1007 常见错误代码: - 1007:对象已存在 - 1032:无法执行DML - 1062:主键冲突,或约束冲突
一劳永逸的方案
- 方法一：设置从库只读
mysql [(none)]>set global read_only=1; Query OK, 0 rows affected (0.00 sec) mysql [(none)]>show variables like '%read_only%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_read_only | OFF | | read_only | ON | | super_read_only | OFF | | transaction_read_only | OFF | | tx_read_only | OFF | +-----------------------+-------+ 5 rows in set (0.00 sec) - 方法二：加入中间件实现读写分离
主从延时分析
主库做了修改操作,从库比较长时间才能追上。
外在因素
- 网络
- 主从硬件差异大
- 版本差异
- 参数因素
主库因素
原因分析：
- 二进制日志写入不及时
mysql [(none)]>select @@sync_binlog; +---------------+ | @@sync_binlog | +---------------+ | 1 | +---------------+ 1 row in set (0.01 sec) - 传统模式的主从复制中，binlog_dump线程以事件为单元串行传送二进制日志(版本5.5 5.6)
a. 主库并发事务量大,主库可以并行,传送时是串行
b. 主库发生大事务,由于是串行传送,会阻塞后续的事务 - 一主多从情况下，主库有很多DUMP线程，传输压力大（架构层面）
解决方案:
- MySQL 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO
- MySQL 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,但建议还是开启GTID
- 大事务拆成多个小事务,可以有效的减少主从延时
从库因素
原因分析：
SQL线程导致的主从延时。在传统模式主从复制中，从库默认情况下只有一个SQL，只能串行回放事务SQL
- 主库如果并发事务量较大,从库只能串行回放
- 主库发生了大事务,会阻塞后续的所有的事务的运行
解决方案:
- MySQL 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放（同一个库内依然是串行回放，防止出现逻辑问题）
- MySQL 5.7 版本开启GTID之后,在SQL方面,提供了逻辑时钟(logical_clock),binlog加入了seq_no（sequence number，序列号）机制,
真正实现了基于事务级别的并发回放,这种技术称之为MTS(enhanced multi-threaded slave) - 大事务拆成多个小事务,可以有效的减少主从延时
主从复制进阶
延时从库
延时从库是一种特殊从库，通过人为配置从库和主库延时N小时。
延时从库原因
主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）。如果发生了逻辑损坏，就需要备份恢复，但如果恢复数量级很大的话，时间成本很高。
因此延时从库是为了更快的解决逻辑损坏问题的从库（备份恢复的替代方案）。
延时从库配置
SQL线程延时：数据已经写入relay-log中，但SQL线程慢点执行relay-log中的语句。
一般企业建议延时3-6小时，具体看公司运维人员对于故障的反应时间。
延时从库配置
-
停止slave服务
mysql [(none)]>stop slave; Query OK, 0 rows affected, 1 warning (0.05 sec) -
修改MASTER_DELAY参数
mysql [(none)]>CHANGE MASTER TO MASTER_DELAY=300; Query OK, 0 rows affected (0.32 sec) -
开启slave服务
mysql [(none)]>start slave; -
查看延时状态
mysql [(none)]>show slave status \G; SQL_Delay: 300 --延时时间 SQL_Remaining_Delay: 295 --延时倒计时 -
查看二进制日志是否一致
# 主库 mysql [test]>show master status ; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000001 | 943 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.34 sec) # 从库 mysql [(none)]>show slave status \G; Read_Master_Log_Pos: 943
延时从库应用
一主一从，从库延时5分钟，主库误删除1个库。
逻辑故障恢复思路：
- 5分钟之内及时侦测到误删除操作
- 立即停止延时从库SQL的线程
- 挂维护页
- 截取relay-log日志进行恢复
起点 ：停止SQL线程时的relay-log位置点
终点 ：误删除之前的position(GTID) - 截取的日志恢复到从库
- 从库身份解除,替代主库工作
故障模拟及恢复：
-
模拟主库数据操作
mysql [(none)]> create database relay charset utf8; mysql [(none)]> use relay mysql [relay]> create table t1 (id int); mysql [relay]> insert into t1 values(1); mysql [relay]> drop database relay; -
发现故障，停止从库的SQL线程
mysql [none]> stop slave sql_thread; -
找到relay-log的截取起点和终点
# 起点 mysql [(none)]>show slave status\G; Relay_Log_File: localhost-relay-bin.000002 Relay_Log_Pos: 482 --同步前的position Read_Master_Log_Pos: 1698 --主库传来的新position # 终点 mysql [(none)]>show relaylog events in 'localhost-relay-bin.000002' | localhost-relay-bin.000002 | 1046 | Xid | 7 | 1538 | COMMIT /* xid=74 */ | | localhost-relay-bin.000002 | 1077 | Anonymous_Gtid | 7 | 1603 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | localhost-relay-bin.000002 | 1142 | Query | 7 | 1698 | drop database relay | # 截取日志 [root@localhost ~]# mysqlbinlog --start-position=482 --stop-position=1077 /data/3308/data/localhost-relay-bin.000002>/tmp/relay.sql -
从库恢复relay-log
mysql [relay]>source /tmp/relay.sql -
从库身份解除，从库替代主库身份（数据量比较小的话可以考虑直接将数据导入主库）
mysql [relay]>stop slave; mysql [relay]>reset slave all;
半同步复制
半同步复制用来解决主从数据一致性问题。
- MySQL 5.5 版本出现
- MySQL 5.6 增强
- MySQL 5.7 完善，5.7.17后出现MGR复制
- 主库执行新的事务commit时，更新 show master status\G ，触发一个信号给Binlog_Dump_Thread；
- Binlog_Dump_Thread 接收到主库的 show master status\G 信息,通知从库日志更新；
- 从库Slave_IO_Thread 请求新的二进制日志事件;
- 主库会通过 Binlog_Dump_Thread 传送新的日志事件给从库Slave_IO_Thread；
- 从库Slave_IO_Thread接收到binlog日志，当日志写入到磁盘上的relaylog文件时，给主库ACK_receiver线程发送确认；
- ACK_receiver线程触发一个事件，告诉主库commit可以成功了；
- 如果ACK达到了预设值的超时时间，半同步复制会切换为原始的异步复制。
过滤复制
需求：master 有3个库A、B、C ，现在需要将其中2个库B，C单独拆分出来，单独一个实例。
常见的做法为：单独搭建一个只有B、C库的实例，且它们只复制master的B、C库，过滤掉A库。此时就需要过滤复制。
mysql [(none)]>show slave status \G;
Replicate_Do_DB: --过滤复制相关参数
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
过滤复制配置
-
主库方面（不建议使用）
Binlog_Do_DB
Binlog_Ignore_DB -
从库方面
Replicate_Do_DB
Replicate_Ignore_DB配置3309数据库实例只对两个库进行同步操作
[root@db01 ~]# vim /data/3309/my.cnf replicate_do_db=people replicate_do_db=world [root@db01 ~]# systemctl restart mysqld3309
GTID复制
GTID简介
GTID(Global Transaction ID)是对一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。它的官方定义如下：
GTID = source_id ：transaction_id
什么是sever_uuid？和server-id 区别？
server_uuid是mysql的识别码，server_id是在集群里面的id号，防止server_id冲突。
-
核心特性
全局唯一，具备幂等性 -
核心参数
gtid-mode=on --启动GTID类型，否则就是普通的复制架构
enforce-gtid-consistency=true --强制GTID的一致性
log-slave-update=1 --设置为开启，则从库从主库复制数据时可以写入到binlog日志
GTID复制配置
需求：搭建一主两从的GTID环境
-
创建数据目录并授予权限
[root@localhost ~]# mkdir -p /data/330{7,8,9}/data [root@localhost ~]# chown -R mysql.mysql /data/330{7,8,9} -
准备各实例的配置文件
[root@localhost ~]# vim /data/3307/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3307/data socket=/data/3307/mysql.sock server_id=7 port=3307 secure-file-priv=/tmp autocommit=0 log_bin=/data/3307/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db01 [\\d]>[root@localhost ~]# vim /data/3308/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3308/data socket=/data/3308/mysql.sock server_id=8 port=3308 secure-file-priv=/tmp autocommit=0 log_bin=/data/3308/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db02 [\\d]>[root@localhost ~]# vim /data/3309/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3309/data socket=/data/3309/mysql.sock server_id=9 port=3309 secure-file-priv=/tmp autocommit=0 log_bin=/data/3309/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db03 [\\d]> -
初始化各实例数据目录
[root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3307/data [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3308/data [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3309/data -
启动各数据库实例
[root@localhost system]# systemctl start mysqld3307.service [root@localhost system]# systemctl start mysqld3308.service [root@localhost system]# systemctl start mysqld3309.service [root@localhost system]# ps -ef | grep mysqld mysql 10676 1 21 18:18 ? 00:00:06 /app/mysql/bin/mysqld --defaults-file=/data/3307/my.cnf mysql 10687 1 9 18:19 ? 00:00:02 /app/mysql/bin/mysqld --defaults-file=/data/3308/my.cnf mysql 10761 1 24 18:19 ? 00:00:03 /app/mysql/bin/mysqld --defaults-file=/data/3309/my.cnf root 10795 5857 16 18:19 pts/0 00:00:00 grep --color=auto mysqld -
构建主从
数据库实例3307mysql [(none)]>grant replication slave on *.* to repl@'192.168.1.%' identified by '123456'; Query OK, 0 rows affected, 1 warning (0.12 sec)数据库实例3308/数据库实例3309
mysql [(none)]>change master to -> master_host='192.168.1.5', -> master_user='repl', -> master_password='123456' , -> MASTER_AUTO_POSITION=1; Query OK, 0 rows affected, 2 warnings (0.13 sec) mysql [(none)]>start slave; Query OK, 0 rows affected (0.10 sec) -
GTID从库误写入操作处理
查看监控信息产生错误
Last_SQL_Error: Error 'Can't create database 'oldboy'; database exists' on query. Default database: 'oldboy'. Query: 'create database oldboy' Retrieved_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3 --从主库请求的 Executed_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-2, --实际运行的 7ca4a2b7-4aae-11e9-859d-000c298720f6:1由于71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3操作有问题，可以采取注入空事务的方法，跳过该错误（有风险）：
> stop slave; --停止slave服务 > set gtid_next='99279e1e-61b7-11e9-a9fc-000c2928f5dd:3'; --手工设置操作xxxxx:N 就是slave_sql_thread报错的GTID，或者是想要跳过的GTID > begin;commit; --注入空事物 > set gtid_next='AUTOMATIC'; --设置回自动操作注入空事务的方式有风险，最好的解决方案：重新构建主从环境。
GTID复制与普通复制的区别
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
0. 在主从复制环境中，主库发生过的事务，在全局都是由唯一GTID记录的，更方便Failover;
1. gtid-mode=on 、enforce-gtid-consistency=true 、log-slave-update=1;
2. change master to 的时候不再需要binlog 文件名和position号，直接auto即可，MASTER_AUTO_POSITION=1;
3. 在复制过程中，从库不再依赖master.info文件，而是直接读取最后一个relaylog的 GTID号，获取到上次复制的GTID号后从此号开始向后复制即可;
4. 在MHA高可用环境下，主库无法SSH时，从库进行数据恢复更加便捷;
5. mysqldump备份时，默认会将备份中包含的事务操作，以以下方式:
SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';
告诉从库，我的备份中已经有以上事务，你就不用运行了，直接从下一个GTID开始请求binlog就行。
企业高可用标准
-
全年无故障率（非计划内故障停机）
99.9% ----> 0.001*365*24*60=525.6 min 99.99% ----> 0.0001*365*24*60=52.56 min 99.999% ----> 0.0001*365*24*60=5.256 min -
高可用架构方案
负载均衡：有一定的高可用性（高可用最低的标准） LVS、Nginx 主备（单活架构）：有高可用性，但是需要切换（切换的过程无法提供服务） Keepalived、MHA 真正高可用（多活系统）：NDB Cluster、Oracle RAC、Sysbase Cluster、InnoDB Cluster（MGR）、Percona PXC、MGC
标签：主库,主从复制,slave,--,MySQL,mysql,从库,data 来源： https://blog.csdn.net/hawava/article/details/120586651
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。