Mysql集群方案：Mysql主从复制

一、MySQL常用集群方案

1、了解 MySQL 集群之前，先看看单节点数据库的弊病：

大型互联网程序用户群体庞大，所以架构需要特殊设计。
单节点数据库无法满足大并发时性能上的要求。
单节点的数据库没有冗余设计，无法满足高可用。
单节点 MySQL无法承载巨大的业务量，数据库负载巨大。

2、最常见的MySQL 集群方案

Repliaction 集群方案
PXC 集群方案（ Percona XtraDB Cluster ）

两种集群方案特性如下图：

3、PXC方案和 Replication方案对比
（1）先看看 PXC方案

很明显 PXC方案在任何一个节点写入的数据都会同步到其他节点，数据双向同步的（在任何节点上都可以同时读写）。

（2）Replication 集群方案

Replication方案只能在Master数据库进行写操作，在Slave数据库进行读操作。如果在Slave数据库中写入数据，Master数据库是不能知道的（单向同步的）。

3. PXC 数据的强一致性

PXC 采用同步复制，事务在所有集群节点要么同时提交，要么不提交。
Replication 采用异步复制，无法保证数据的一致性。

下面看看 PXC写入操作：

当一个写入请求到达PXC集群中的一个 mysql（node1数据库）数据库时，node1数据库会将该写入请求同步给集群中的其他所有数据库，等待所有数据库都成功提交事务后，node1节点才会将写入成功的结果告诉给 node1的客户端。

PXC 的强一致性对保存高价值数据时特别重要。

在看Replication集群写入操作：

当一个写入请求到达 Master数据库时，Master数据库执行写入操作，然后 Master 向客户端返回写入成功，同时异步的复制写入操作给 Slave数据库，如果异步复制时出现问题，从数据库将无法执行写入操作，而客户端得到的是写入成功。这也是弱一致性的体现。

二、MySQL Replication简介

主从复制（也称 AB 复制）允许将来自一个MySQL数据库服务器（主服务器）的数据复制到一个或多个MySQL数据库服务器（从服务器）。

复制是异步的，从站不需要永久连接以接收来自主站的更新。

根据配置，您可以复制数据库中的所有数据库，所选数据库甚至选定的表。

MySQL中复制的优点包括：

横向扩展解决方案 - 在多个从站之间分配负载以提高性能。在此环境中，所有写入和更新都必须在主服务器上进行。但是，读取可以在一个或多个从设备上进行。该模型可以提高写入性能（因为主设备专用于更新），同时显着提高了越来越多的从设备的读取速度。
数据安全性 - 因为数据被复制到从站，并且从站可以暂停复制过程，所以可以在从站上运行备份服务而不会破坏相应的主数据。
分析 - 可以在主服务器上创建实时数据，而信息分析可以在从服务器上进行，而不会影响主服务器的性能。
远程数据分发 - 您可以使用复制为远程站点创建数据的本地副本，而无需永久访问主服务器。

Replication 的原理

前提是作为主服务器角色的数据库服务器必须开启二进制日志

主服务器上面的任何修改都会通过自己的 I/O tread(I/O 线程)保存在二进制日志 Binary log 里面。
从服务器上面也启动一个 I/O thread，通过配置好的用户名和密码, 连接到主服务器上面请求读取二进制日志，然后把读取到的二进制日志写到本地的一个Realy log（中继日志）里面。
从服务器上面同时开启一个 SQL thread 定时检查 Realy log(这个文件也是二进制的)，如果发现有更新立即把更新的内容在本机的数据库上面执行一遍。

每个从服务器都会收到主服务器二进制日志的全部内容的副本。

从服务器设备负责决定应该执行二进制日志中的哪些语句。

除非另行指定，否则主从二进制日志中的所有事件都在从站上执行。

如果需要，您可以将从服务器配置为仅处理一些特定数据库或表的事件。

重要: 您无法将主服务器配置为仅记录特定事件。

每个从站(从服务器)都会记录二进制日志坐标：

文件名
文件中它已经从主站读取和处理的位置。

由于每个从服务器都分别记录了自己当前处理二进制日志中的位置，因此可以断开从服务器的连接，重新连接然后恢复继续处理。

一主多从

如果一主多从的话，这时主库既要负责写又要负责为几个从库提供二进制日志。此时可以稍做调整，将二进制日志只给某一从，这一从再开启二进制日志并将自己的二进制日志再发给其它从。或者是干脆这个从不记录只负责将二进制日志转发给其它从，这样架构起来性能可能要好得多，而且数据之间的延时应该也稍微要好一些。工作原理图如下：

关于二进制日志

mysqld将数字扩展名附加到二进制日志基本名称以生成二进制日志文件名。每次服务器创建新日志文件时，该数字都会增加，从而创建一系列有序的文件。每次启动或刷新日志时，服务器都会在系列中创建一个新文件。服务器还会在当前日志大小达到max_binlog_size参数设置的大小后自动创建新的二进制日志文件。二进制日志文件可能会比max_binlog_size使用大型事务时更大，因为事务是以一个部分写入文件，而不是在文件之间分割。

为了跟踪已使用的二进制日志文件， mysqld还创建了一个二进制日志索引文件，其中包含所有使用的二进制日志文件的名称。默认情况下，它具有与二进制日志文件相同的基本名称，并带有扩展名'.index'。在mysqld运行时，您不应手动编辑此文件。

术语二进制日志文件通常表示包含数据库事件的单个编号文件。

术语 二进制日志 表示含编号的二进制日志文件集加上索引文件。

SUPER 权限的用户可以使用SET sql_log_bin=0语句禁用其当前环境下自己的语句的二进制日志记录

三、MySQL Replication总结

1、什么是mysql主从同步？

当master(主)库的数据发生变化的时候，变化会实时的同步到slave(从)库。

2、主从同步有什么好处？

水平扩展数据库的负载能力。
容错，高可用。Failover(失败切换)/High Availability
数据备份。

3、主从同步的原理是什么？

首先我们来了解master-slave的体系结构。

如下图：

不管是delete、update、insert，还是创建函数、存储过程，所有的操作都在master上。当master有操作的时候,slave会快速的接收到这些操作，从而做同步。

但是，这个机制是怎么实现的呢？

在master机器上，主从同步事件会被写到特殊的log文件中(binary-log);在slave机器上，slave读取主从同步事件，并根据读取的事件变化，在slave库上做相应的更改。

如此，就实现了主从同步了！

下面我们来详细的了解。

3.1主从同步事件有哪些

上面说到：

在master机器上，主从同步事件会被写到特殊的log文件中(binary-log);

主从同步事件有3种形式:statement、row、mixed。

statement：会将对数据库操作的sql语句写入到binlog中。
row：会将每一条数据的变化写入到binlog中。
mixed：statement与row的混合。Mysql决定什么时候写statement格式的，什么时候写row格式的binlog。

3.2在master机器上的操作

当master上的数据发生改变的时候，该事件(insert、update、delete)变化会按照顺序写入到binlog中。

binlog dump线程

当slave连接到master的时候，master机器会为slave开启binlog dump线程。当master 的 binlog发生变化的时候，binlog dump线程会通知slave，并将相应的binlog内容发送给slave。

3.3在slave机器上的操作

当主从同步开启的时候，slave上会创建2个线程。

I/O线程。该线程连接到master机器，master机器上的binlog dump线程会将binlog的内容发送给该I/O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log。
SQL线程。该线程读取I/O线程写入的relay log。并且根据relay log的内容对slave数据库做相应的操作。

3.4如何在master、slave上查看上述的线程？

使用SHOW PROCESSLIST命令可以查看。

如图，在master机器上查看binlog dump线程。

如图，在slave机器上查看I/O、SQL线程。

参考链接：

MySQL常用集群方案

Mysql 主从复制