mysql主从复制停电后先启动

第一种：在master上删除一条记录，而slave上找不到。

Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1

Can't find record in 't1',

Error_code: 1032handler error HA_ERR_KEY_NOT_FOUND

the event's master log mysql-bin.000006, end_log_pos 254

第二种：主键重复。在slave已经有该记录，又在master上插入了同一条记录。

Last_SQL_Error: Could not execute Write_rows event on table hcy.t1

Duplicate entry '2' for key 'PRIMARY',

Error_code: 1062

handler error HA_ERR_FOUND_DUPP_KEYthe event's master log mysql-bin.000006, end_log_pos 924

第三种：在master上更新一条记录，而slave上找不到，丢失了数据。

Last_SQL_Error: Could not execute Update_rows event on table hcy.t1

Can't find record in 't1',

Error_code: 1032

handler error HA_ERR_KEY_NOT_FOUNDthe event's master log mysql-bin.000010, end_log_pos 263

异步半同步区别

MySQL 4.1/5.0/5.1/5.5/5.6各版本的主要区别

1、4.1 增加了子查询的支持，字符集增加UTF-8，GROUP BY语句增加了ROLLUP，mysql.user表采用了更好的加密算法。

2、5.0 增加了Stored procedures、Views、Cursors、Triggers、XA transactions的支持，增加了INFORATION_SCHEMA系统数据库。

3、5.1 增加了Event scheduler，Partitioning，Pluggable storage engine API ，Row-based replication、Global级别动态修改general query log和slow query log的支持。

4、5.5的新特征

1)默认存储引擎更改为InnoDB

2)提高性能和可扩展性

a. 提高了默认线程并发数(innodb_thread_concurrency)

b. 后台输入/输出线程控制（innodb_read_io_threads、innodb_write_io_threads）

c. 主线程输入/输出速率控制（innodb_io_capacity）

d. *** 作系统内存分配程序使用控制(innodb_use_sys_malloc)

e. 适应性散列索引(Hash Index)控制，用户可以关闭适应性散列功能。

f. 插入缓冲（Insert Buffering）控制，用户可以关闭innodb的插入缓冲功能。

g. 通过快速加锁算法提高可扩展性，innodb不在使用代理(posix)线程,而是使用原生的独立 *** 作来完成互斥和读写锁定。

h. 恢复组提交（Restored Group Commit）

i. 提高恢复性能

j. 多缓冲池实例

k. 多个回滚段（Multiple Rollback Segments）,之前的innodb版本最大能处理1023个并发处理 *** 作，现在mysql5.5可以处理高达128K的并发事物，

l. Linux系统固有的异步输入/输出，mysql5.5数据库系统也提高了linux系统的输入输出请求的并发数。

m. 扩展变化缓冲：添加了删除缓冲和清除缓冲

n. 改善了日志系统互斥和单独刷新（Flush）列表互斥

o. 改善清除程序进度，在mysql5.5中清楚 *** 作线程是独立的线程，并支持并发，可以使用innodb_purge_treads配置。

p. 改善事务处理中的元数据锁定。例如，事物中一个语句需要锁一个表，会在事物结束时释放这个表，而不是像以前在语句结束时释放表。

3)提高实用性

a. 半同步复制（Semi-synchronous Replication）

b. 复制Heartbeat

c. 中继日志自动恢复（Automatic Relay Log Recovery）

d. 根据服务器过滤项复制（Replication Per Server Filtering）

e. 从服务器复制支持的数据类型转换（Replication Slave Side Data Type Conversions）

4)提高易管理性和效率

a. 建立快速索引（Faster Index Creation）

b. 高效的数据压缩（Efficient Data Compression）

c. 为大物件和可变长度列提供高效存储

d. 增加了INFORMATION_SCHEMA表，新的表提供了与InnoDB压缩和事务处理锁定有关的具体信息。

5)提高可用性

a. 针对SIGNAL/RESIGNAL的新SQL语法

b. 新的表/索引分区选项。MySQL5.5将表和索引RANG和LIST分区范围扩展到了非整数列和日期，并增加了在多个列上分区的能力。

6)改善检测和诊断

Mysql5.5引入了一种新的性能架构(performancn_shema,P_S),用于监控mysql监控服务器运行时的性能。

5、5.6的新特征 1)InnoDB现在可以限制大量表打开的时候内存占用过多的问题（比如这里提到的）(第三方已有补丁)

2)InnoDB性能加强。如分拆kernel mutexflush *** 作从主线程分离多个perge线程大内存优化等

3)InnoDB死锁信息可以记录到 error 日志，方便分析

4)MySQL5.6支持延时复制，可以让slave跟master之间控制一个时间间隔，方便特殊情况下的数据恢复。

5)表分区功能增强

6)MySQL行级复制功能加强，可以降低磁盘、内存、网络等资源开销（只记录能确定行记录的字段即可）

7)Binlog实现 crash-safe

8)复制事件采用crc32校验，增强master/slave 复制数据一致性

9)新增 log_bin_basename （以前variables里面没有binlog位置信息，对数据库的监管很不方便）

MGR是MySQL Group Replication的缩写，即MySQL组复制。

在以往，我们一般是利用MySQL的主从复制或半同步复制来提供高可用解决方案，但这存在以下几个比较严重的问题：

因为上述几个明显的缺点，因此MySQL推出了全新的高可用解决方案 -- 组复制，这是本系列文章要着重介绍的新特性。

MGR是MySQL 5.7.17开始引入的，但随着5.7版本逐渐退出历史舞台（MySQL 5.7已于2020年10月起不再做大的功能更新，只有修修补补以及针对安全更新），更多MGR相关特性都只在MySQL 8.0上才有。

因此，如果线上还有基于MySQL 5.7版本的MGR环境的话，建议尽快升级、迁移到MySQL 8.0版本。进一步提醒，推荐MySQL 8.0.22及之后的版本，整体会更稳定可靠，也有些很不错的新功能（不只是MGR方面的）。

MGR具备以下几个特点：

MGR可以选择单主（Single-Primary）模式

如上图所示，一开始S1节点是Primary角色，提供读写服务。当它发生故障时，剩下的S2-S5节点会再投票选举出S2作为新的Primary角色提供读写服务，而S1节点再达到一定超时阈值后，就会被踢出。

亦可选择多主（Multi-Primary）模式（再次 强烈建议选用单主模式 ）

如上图所示，一开始S1-S5所有节点都是Primary角色，都可以提供读写服务，任何一个节点发生故障时，只需要把指向这个节点的流量切换下就行。

上述两种架构模式下，应用端通过MySQL Router连接后端在MGR服务，当后端节点发生切换时，Router会自动感知，对应用端来说几乎是透明的，影响很小，架构上也更灵活。

首先来个MGR的技术架构图：

MGR是以Plugin方式嵌入MySQL，部署更灵活方便。

事务从Server层通过钩子（hook）进入MGR API接口层，再分发到各组件层，在组件层完成事务Capture/Apply/Recover，通过复制协议层（Replication Protocol Logics）传输事务，最后经由GCS协调事务在各节点的最终一致性。

MGR节点间由组通信系统（GCS）提供支持，它提供了故障检测机制、组成员角色管理，以及安全且有序的消息传递，这些机制可确保在各节点间一致地复制数据。这项技术的核心是Paxos算法的实现，在MySQL里称之为XCom，由它充当MGR的通信引擎。

对于要提交的事务，组中的多数派节点必须就全局事务序列中给定的事务顺序达成一致。各节点做出决定提交或中止事务的选择，但所有节点都要做出相同的决定。如果发生网络分区，导致节点间无法达成一致决定，则在网络恢复前，MGR无法工作。

MGR支持单主和多主两种模式，在单主模式下，各节点会自动选定主节点，只有该主节点能同时读写，而其他（从）节点只能只读。在多主模式下，所有节点都可以进行读写。

相对于MariaDB Galera Cluster（以及基于此技术的Percona XtraDB Cluster，下面为了书写方便，都统称为PXC），个人认为MGR具备以下几个优势：

相对于传统主从复制（Replication），我认为MGR的优势有以下几点：

以上是我根据MySQL、MariaDB、Percona的资料整理得到的观点，不一定准确和全面，有不完善的地方还请留言指正。

本节主要介绍了什么是MGR，MGR的技术架构概要，以及MGR相对PXC的几个技术优势。

MGR是MySQL四部战略走的关键一环，依靠MGR和MySQL Shell、MySQL Router已实现了读节点扩展，以及写节点扩展（MGR多主模式），下一步预计实现sharding，让我们拭目以待。

相信MGR也是MySQL未来几年的重头戏，建议跟紧方向，不要错过这班列车。

因个人水平有限，专栏中难免存在错漏之处，请勿直接复制文档中的命令、方法直接应用于线上生产环境。请读者们务必先充分理解并在测试环境验证通过后方可正式实施，避免造成生产环境的破坏或损害。

Enjoy GreatSQL :)

---