MySQL replication is called in the industry: mysql synchronization, ab replication, etc. The professional name is called: copy.
Replication is one-way, and can only be replicated from the master to the slave, and the delay is basically at the millisecond level.
There can be multiple slaves in a set of replication structures, and only one is recommended for the master in general scenarios.
The master user writes data, generates events and records them in the binary log. The slave receives the binlog uploaded by the master, and then applies them in sequence to reproduce the user operations on the master.
The smallest unit of record is an event, the first 4 bytes of the log are a magic number, and the next 19 bytes are recorded formatt desc event: FDE
MySQL 5.6 adds GTID replication
1. Classic master-slave configuration
core configuration
Add a new slave library and get a backup with binlog and pos offset on the master library
Execute after restoring from repository
Start the slave and check the status
If you encounter errors, you can skip:
2. Copy configuration
A transaction corresponds to a unique ID, and a GTID will only be executed once on a server. GTID is used to replace the previous classic replication method, supported by mysql 5.62, and improved after mysql 5.6.10
advantage:
Higher data security and easier failover than row replication
Configure GTIDs
There are two ways to add GTID from the library:
1. If all the binlogs of the master are still there, after installing the slave, directly change the master to the master. The principle is to directly obtain all the gtids of the master and execute them. The advantage is that it is simple. The disadvantage is that if there are too many binlogs, it takes a long time for the data to be fully synchronized, and the master needs to have GTID enabled at the beginning.
Summary: It is suitable for the case that the master is also newly built soon
2、通过 master 或者其它 slave 的备份搭建新的 slave，原理：获取 master 的数据和这些数据对应的 GTID 范围，然后通过在 slave 设置 @@GLOBAL.GTID_PURGED 从而跳过备份包含的 GTID，优点是可以避免第一种方法中的不足，缺点操作相对复杂。
总结：适用于拥有较大数据集的情况
GTID 添加从库：
1、用 mysqldump 工具，在备份的时候需要指定 --master-data
导出的语句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497'; 恢复时，需要先在 slave 上执行一个 reset master，再执行 change master to
2、用 percona xtrabackup 工具
xtrabackup_binlog_info 包含了 GTID 在信息
做从库恢复后，需要手工设置：
恢复后，执行
错误跳过
GTID 的限制：
1、不支持非事务引擎（从库报错，stopslave; start slave; 忽略）
2、不支持 create table … select 语句复制（主库直接报错）
3、不允许在一个 SQL 同时更新一个事务引擎和非事务引擎的表
4、在一个复制组中，必须要求统一开启 CTID 或是关闭 GTID
5、开启 DTID 需要重启（5.7 中可能不需要）
6、开启 DTID 后，就不在使用原来的传统的复制方式
7、对于 createtemporary table 和 drop temporary table 语句不支持
8、不支持 sql_slave_skip_counter
MySQL 复制默认是异步复制，Master 将事件写入 binlog，但并不知道 Slave 是否或何时已经接收且已处理。在异步复制的机制的情况下，如果 Master 宕机，事务在 Master 上已提交，但很可能这些事务没有传到任何的 Slave 上。假设有 Master->Salve 故障转移的机制，此时 Slave 也可能会丢失事务。
官方半同步复制的概念：
1. 当 Slave 主机连接到 Master 时，能够查看其是否处于半同步复制的机制。
2. 当 Master 上开启半同步复制的功能时，至少应该有一个 Slave 开启其功能。此时，一个线程在 Master 上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的 Slave 已收到此事务的所有事件，或等待超时。
3. 当一个事务的事件都已写入其 relay-log 中且已刷新到磁盘上，Slave 才会告知已收到。
4. 如果等待超时，也就是 Master 没被告知已收到，此时 Master 会自动转换为异步复制的机制。当至少一个半同步的 Slave 赶上了，Master 与其 Slave 自动转换为半同步复制的机制。
5. 半同步复制的功能要在 Master，Slave 都开启，半同步复制才会起作用；否则，只开启一边，它依然为异步复制。
同步（社区增强半同步），异步，半同步复制的比较：
同步复制：Master 提交事务，直到事务在所有的 Slave 都已提交，此时才会返回客户端，事务执行完毕。缺点：完成一个事务可能会有很大的延迟。
异步复制：当 Slave 准备好才会向 Master 请求 binlog。缺点：不能保证一些事件都能够被所有的 Slave 所接收。
半同步复制：半同步复制工作的机制处于同步和异步之间，Master 的事务提交阻塞，只要一个 Slave 已收到该事务的事件且已记录。它不会等待所有的 Slave 都告知已收到，且它只是接收，并不用等其完全执行且提交。
半同步，开启后严重影响性能
To solve the problem that the main library does not care whether the log is read from the library to the semi-synchronous configuration, it is configured on both the master and the slave:
Copy parameters
