关于mysql:MySQL优化复制

MySQL 内建的复制性能是构建基于 MySQL 的大规模、高性能利用的根底，这类利用应用所谓的“程度扩大”的架构。咱们能够通过为服务器配置一个或多个备库的形式来进行数据同步。复制性能不仅有利于构建高性能的利用，同时也是高可用性、可扩展性、劫难复原、备份以及数据仓库等工作的根底。

概述

复制解决的根本问题是让一台服务器的数据与其余服务器放弃同步。一台主库的数据能够同步到多台备库上，备库自身也能够被配置成另外一台服务器的主库。主库和备库之间能够有多种不同的组合形式。

实用场景

横向扩大

横向扩大是指在多个从库之间进行读负载平衡，以进步读性能。在此扩大计划中，所有数据变更在主库上执行，读负载能够摊派到一个或者多个从库上。

数据安全

数据安全性在很大水平上须要靠数据副原本保障。在这里，正本能够了解为咱们通常所说的备份。

数据分析

在主库上运行 OLTP（联机事务处理）利用，而 OLAP（联机剖析解决）利用能够在从库上运行，防止在主库上运行 OLAP 利用对主库性能造成影响。

近程数据散发

能够应用复制个性为近程站点创立数据的本地正本，那些对数据实时性没有要求的利用能够拜访本地正本，剩下的一小部分对实时性有要求的利用拜访主库。近程站点既能够作为灾备核心，也能够用于实现跨地区拜访以摊派负载，以及实现就近拜访，放慢访问速度。

滚动降级

应用一个更高版本的 MySQL 作为备库，保障在降级全副实例前，查问可能在备库依照预期执行。

高可用性和故障切换

复制可能帮忙应用程序防止 MySQL 单点失败，一个蕴含复制的设计良好的故障切换零碎可能显著地缩短宕机工夫。

复制形式

MySQL 反对以下两种数据同步办法：

• 传统复制 ：也能够称为基于二进制日志文件和地位的复制，在从库中配置复制时，要求指定从主库中获取的二进制日志文件（binlog file）和地位（binlog position），以便从库中的复制线程启动时，可能以指定的二进制日志文件和地位为终点，继续读取主库中的二进制日志，并在从库中利用，从而达到数据同步的目标。
• 基于 GTID 的复制 ：GTID（全局事务标识符）是新的事务性复制办法，利用 GTID 能够主动在主库中寻找须要复制的二进制日志记录，因而不须要关怀日志文件或地位，极大地简化了许多常见的复制工作。应用 GTID 复制可确保主库和从库之间的一致性。。

同步类型

MySQL 反对如下 4 种不同类型的数据同步：

• 异步复制 ：最早呈现的复制技术，MySQL 内置反对，不须要额定装置插件。其中，一个实例充当主库，一个或多个其余实例充当从库，与同步复制造成比照。
• 半同步复制 ：从 MySQL 5.5 开始反对半同步复制。应用半同步复制时，主库的会话在提交事务之前，会期待至多一个从库返回收到二进制日志的 ACK 音讯（确认接管，并将事务的事件记录到从库的中继日志中）。
• 提早复制 ：从 MySQL 5.6 开始反对，使得从库能够成心滞后于主库至多一段指定的工夫，以便在呈现误操作时，有工夫对误操作的数据进行补救。
• 同步复制 ：指的是须要保障写操作齐全同步到其余数据节点，而不仅仅是二进制日志被其余节点接管。对于须要同步复制的场景，能够应用 NDB Cluster，或者其余相似的开源解决方案（虚构同步，非齐全同步），例如 Percona XtraDB Cluster（PXC）、MariaDB GaleraCluster（MGC）、MySQL Group Replication（MGR）。

复制格局

MySQL 的复制格局（二进制日志格局）能够分为三种，由零碎变量 binlog_format 进行设置：

• 基于 statement 的复制 （Statement Based Replication，SBR）：SBR 复制的是整个 SQL 语句的原始文本，日志量较小，但容易呈现主从库数据不统一。对于 SBR，当执行的某个语句被断定为不平安时，是否容许其执行还取决于事务的隔离级别。
• 基于 row 的复制 （Row Based Replication，RBR）：RBR 复制的是产生更改的数据行的理论记录（原始语句会被转换为产生变更的行数据记录），日志量较大，但能够保障主从库数据的一致性。
• 混合复制 （Mixed Based Replication，MBR）：MBR 实际上是由 MySQL 自行判断的，即在不影响数据一致性的状况下，应用 SBR；如果可能影响数据一致性，则主动转换为 RBR。

复制的基本原理

复制是基于主库（master）二进制日志中写入的对于该数据库的所有更改（更新、删除等）的日志记录来实现的。从库（slave）利用这些二进制日志中的事件记录进行回放来同步数据。

对于复制线程在主从之间新建设连贯或从新建设连贯的状况，从库会被动向主库申请所需的二进制日志（从库向主库注册连贯时，携带了从库本身所需二进制日志的地位信息）。如果复制线程曾经在主从之间建设连贯，而且从库曾经齐全接管建设连贯时申请的二进制日志内容，后续的增量二进制日志是由主库被动推送给从库的。

MySQL 的复制性能用三个线程来实现：一个线程在主库上（Binlog Dump 线程），两个线程在从库上（I/ O 线程和 SQL 线程）。如图所示：

复制的大抵步骤如下：

1. 用户提交对数据的批改，而后主库把所有数据库变更写进二进制日志。
2. 从库会启动一个工作线程，称为 I / O 线程。而后在主库上启动一个非凡的 Binlog Dump 线程，这个线程会读取主库上二进制日志中的事件，它不会对事件进行轮询，如果该线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量告诉其有新的事件产生时才会被唤醒。 从库的 I / O 线程跟主库的 Binlog Dump 线程建设一个一般的客户端连贯，备库 I / O 线程将接管到的事件记录到中继日志中。
3. 从库 SQL 线程读取并解析中继日志中的内容，依照读取的程序进行回放。