From 3fcf2cb8889a31cb10e907d6a6942203baa25ebc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=BD=97=E7=A5=A5?= <1366971433@qq.com>
Date: Mon, 19 Aug 2019 17:57:03 +0800
Subject: [PATCH] =?UTF-8?q?mysql=E5=A4=87=E4=BB=BD=E4=B8=8E=E5=A4=8D?=
 =?UTF-8?q?=E5=88=B6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 notes/MySQL_备份.md | 121 ++++++++++++++++++++++++++++++++++++++----
 notes/MySQL_复制.md |  95 ++++++++++++++++++++++-----------
 2 files changed, 177 insertions(+), 39 deletions(-)

diff --git a/notes/MySQL_备份.md b/notes/MySQL_备份.md
index 71151cb..ac1f9c7 100644
--- a/notes/MySQL_备份.md
+++ b/notes/MySQL_备份.md
@@ -1,10 +1,37 @@
 # 数据备份与恢复
 
-## 一、备份
+## 一、备份简介
+
+### 2.1 备份分类
+
+按照不同的思考维度，通常将数据库的备份分为以下几类：
+
+**物理备份 与 逻辑备份**
+
++ 物理备份：备份的是完整的数据库目录和数据文件。由于其基本都是 IO 复制，并不含任何逻辑转换，因此其备份和恢复速度通常都比较快。
++ 逻辑备份：通过数据库结构和内容信息来进行备份。因为要执行逻辑转换，因此其速度较慢，并且在以文本格式保存时，其输出文件的大小要远大于物理备份。逻辑备份和还原的粒度可以从服务器级别（所有数据库）精确到具体表，但备份不会包括日志文件、配置文件等与数据库无关的内容。
+
+**全量备份 与 增量备份**
+
++ 全量备份：备份服务器在给定时间点上的所有数据。
++ 增量备份：备份在给定时间跨度内（从一个时间点到另一个时间点）对数据所做的更改。
+
+**在线备份 与 离线备份**
+
++ 在线备份：在数据库服务运行状态下进行备份。此时其他客户端依旧可以连接到数据库，但为了保证数据的一致性，在备份期间必然会存在对数据加锁的操作，此时客户端的访问仍然可能受限。
++ 离线备份：在数据库服务停机状态下进行备份。此时备份过程更加简单，但会此时由于无法提供对外服务，通常会对业务造成比较大的影响。
+
+### 2.2 备份工具
+
+MySQL 支持的备份工具有很多种，这里列出常用的三种：
+
++ **mysqldump**：这是 MySQL 自带的备份工具，其采用的备份方式是逻辑备份，支持全库备份、单库备份、单表备份。由于其采用的是逻辑备份，所以生成的备份文件比物理备份的大，且所需恢复时间也比较长。
++ **mysqlpump**：这是 MySQL 5.7 之后新增的备份工具，在 mysqldump 的基础上进行了功能的扩展，支持多线程备份，支持对备份文件进行压缩，能够提高备份的速度和降低备份文件所需的储存空间。
++ **Xtrabackup**：这是 Percona 公司开发的实时热备工具，能够在不停机的情况下进行快速可靠的热备份，并且备份期间不会间断数据库事务的处理。它支持数据的全备和增备，并且由于其采用的是物理备份的方式，所以恢复速度比较快。
 
 ## 二、mysqldump
 
-### 2.1 基本语法
+### 2.1 常用参数
 
 mysqldump 的基本语法如下：
 
@@ -104,11 +131,61 @@ mysql> source /root/mysqldata/titles_bak.sql;
 
 ### 2.3 增量备份
 
+## 三、mysqlpump
 
+### 3.1 简介
 
-## 三、Xtrabackup
+mysqlpump 在 mysqldump 的基础上进行了扩展增强，其主要的优点如下：
 
-### 3.1 安装
+- 能够并行处理数据库及其中的对象，从而可以加快备份进程；
+
+- 能够更好地控制数据库及数据库对象（表，存储过程，用户帐户等）；
+
+- 能够直接对备份文件进行压缩；
+
+- 备份时能够显示进度指标（估计值）；
+- 备份用户时生成的是 CREATE USER 与 GRANT 语句，而不是像 mysqldump 一样直接备份成数据，可以方便用户按需恢复。
+
+### 3.2 常用参数
+
+mysqlpump 的使用和 mysqldump 基本一致，这里不再进行赘述。以下主要介绍部分新增的可选项，具体如下：
+
++ **--default-parallelism=N**
+
+  每个并行处理队列的默认线程数。默认值为 2。
+
++ **--parallel-schemas=[N:]db_list**
+
+  用于并行备份多个数据库：db_list 是一个或多个以逗号分隔的数据库名称列表；N 为使用的线程数，如果没有设置，则使用 --default-parallelism 参数的值。
+
++ **--users**
+
+  将用户信息备份为 CREATE USER 语句和 GRANT语句 。如果想要只备份用户信息，则可以使用下面的命令：
+
+  ```shell
+  mysqlpump --exclude-databases=% --users
+  ```
+
++ **--compress-output=algorithm**
+
+  默认情况下，mysqlpump 不对备份文件进行压缩。可以使用该选项指定压缩格式，当前支持 LZ4 和 ZLIB 两种格式。需要注意的是压缩后的文件可以占用更少的存储空间，但是却不能直接用于备份恢复，需要先进行解压，具体如下：
+
+  ```shell
+  # 采用lz4算法进行压缩
+  mysqlpump --compress-output=LZ4 > dump.lz4
+  # 恢复前需要先进行解压
+  lz4_decompress input_file output_file
+  
+  # 采用ZLIB算法进行压缩
+  mysqlpump --compress-output=ZLIB > dump.zlib
+  zlib_decompress input_file output_file
+  ```
+
+  MySQL 发行版自带了上面两个压缩工具，不需要进行额外安装。以上就是 mysqlpump 新增的部分常用参数，完整参数可以参考官方文档：[mysqlpump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html#option_mysqlpump_compress-output)
+
+## 四、Xtrabackup
+
+### 4.1 安装
 
 Xtrabackup 可以直接使用 yum 命令进行安装，这里我的 MySQL 为 8.0 ，对应安装的 Xtrabackup 也为 8.0，命令如下：
 
@@ -120,7 +197,7 @@ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
 yum install percona-xtrabackup-80
 ```
 
-### 3.2 全量备份
+### 4.2 全量备份
 
 #### 1. 创建备份
 
@@ -164,22 +241,26 @@ chown -R mysql:mysql /usr/app/mysql-8.0.17/data
 
 再次启动即可完成备份恢复。
 
-### 3.3 增量备份
+### 4.3 增量备份
+
+使用 Xtrabackup 进行增量备份时，每一次增量备份都需要以上一次的备份为基础，之后再将增量备份运用到第一次全备之上，从而完成备份。具体操作如下：
 
 #### 1. 创建备份
 
+这里首先创建一个全备作为基础：
+
 ```shell
 xtrabackup  --user=root --password --backup  --target-dir=/data/backups/base/
 ```
 
-
+之后修改库中任意数据，然后进行第一次增量备份，此时需要使用 incremental-basedir 指定基础目录为全备目录：
 
 ```shell
 xtrabackup  --user=root --password --backup  --target-dir=/data/backups/inc1 \
 --incremental-basedir=/data/backups/base
 ```
 
-
+再修改库中任意数据，然后进行第二次增量备份，此时需要使用 incremental-basedir 指定基础目录为上一次增备目录：
 
 ```shell
 xtrabackup  --user=root --password --backup  --target-dir=/data/backups/inc2 \
@@ -188,25 +269,47 @@ xtrabackup  --user=root --password --backup  --target-dir=/data/backups/inc2 \
 
 #### 2. 准备备份
 
+准备基础备份：
+
 ```shell
 xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base
 ```
 
+将第一次备份作用于全备数据：
+
 ```shell
 xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \
 --incremental-dir=/data/backups/inc1
 ```
 
+将第二次备份作用于全备数据：
+
 ```shell
 xtrabackup --prepare --target-dir=/data/backups/base \
 --incremental-dir=/data/backups/inc2
 ```
 
+在准备备份时候，除了最后一次增备外，其余的准备命令都需要加上 `--apply-log-only` 选项来阻止事务的回滚，因为备份时未提交的事务可能正在进行，并可能在下一次增量备份中提交。如全备中的某些事务可能在第一次备份中才会提交，如果不进行阻止，那么增量备份将没有任何意义。
+
 #### 3. 恢复备份
 
+恢复备份和全量备份时相同，只需要最终准备好的全备数据复制到 MySQL 的数据目录下即可：
+
 ```shell
 xtrabackup --copy-back --target-dir=/data/backups/base
-
+# 必须修改文件权限，否则无法启动
 chown -R mysql:mysql /usr/app/mysql-8.0.17/data
 ```
 
+此时增量备份就已经完成。需要说明的是：按照上面的情况，如果第二次备份之后发生了宕机，那么第二次备份后到宕机前的数据依然没法通过 Xtrabackup 进行恢复，此时就只能采用上面介绍的分析二进制日志的恢复方法。由此可以看出，无论是采用何种备份方式，二进制日志都是非常重要的，因此最好对其进行实时备份。
+
+## 五、二进制日志的备份
+
+
+
+## 参考资料
+
++ [Chapter 7 Backup and Recovery](https://dev.mysql.com/doc/refman/8.0/en/backup-and-recovery.html)
++ [mysqldump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)
++ [mysqlpump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)
++ [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html)
\ No newline at end of file
diff --git a/notes/MySQL_复制.md b/notes/MySQL_复制.md
index aa9be76..7884c3c 100644
--- a/notes/MySQL_复制.md
+++ b/notes/MySQL_复制.md
@@ -72,7 +72,7 @@ log-bin = mysql-bin
 log_slave_updates = 1
 ```
 
-创建用于进行复制账号，并为其授予权限：
+登录主节点 MySQL 服务，创建用于进行复制账号，并为其授予权限：
 
 ```shell
 CREATE USER 'repl'@'192.168.0.%' IDENTIFIED WITH mysql_native_password BY '123456'; 
@@ -236,29 +236,73 @@ GTID 复制的优点在于程序可以自动确认开始复制的 GTID 点。但
 
 为防止执行不受支持的语句，建议配置和上文配置一样，开启 enforce-gtid-consistency 属性， 开启后在主库上执行以上不受支持的语句都将抛出异常并提示。
 
+
+
 ## 四、半同步复制
 
 
 
+```shell
+mysql> SHOW STATUS LIKE 'Rpl_semi_sync_master_status';
++-----------------------------+-------+
+| Variable_name               | Value |
++-----------------------------+-------+
+| Rpl_semi_sync_master_status | ON    |
++-----------------------------+-------+
+```
+
+
+
+```shell
+mysql> SHOW STATUS LIKE 'Rpl_semi_sync_slave_status';
++----------------------------+-------+
+| Variable_name              | Value |
++----------------------------+-------+
+| Rpl_semi_sync_slave_status | ON    |
++----------------------------+-------+
+```
+
+
+
+```shell
+mysql> SHOW VARIABLES LIKE 'rpl_semi_sync_master_wait_point';
++---------------------------------+------------+
+| Variable_name                   | Value      |
++---------------------------------+------------+
+| rpl_semi_sync_master_wait_point | AFTER_SYNC |
++---------------------------------+------------+
+```
+
+
+
+
+
 ## 五、高可用架构
 
 不论是主主复制结构，还是一主多从复制结构，单存依靠复制只能解决数据可靠性的问题，并不能解决系统高可用的问题，想要保证高可用，系统必须能够自动进行故障转移，即在主库宕机时，主动将其它备库升级为主库。常用的有以下两种解决方案：
 
 ### 4.1 MMM
 
-1. Monitor 检测到 Master1 连接失败；
-2. Monitor 发送 set_offline 指令到 Master1 的 Agent；
-3. Master1 Agent 如果存活，下线写 VIP，尝试把 Master1 设置为 read_only=1；
-4. Moniotr 发送 set_online 指令到 Master2；
-5. Master2 Agent 接收到指令，执行 `select master_pos_wait()` 等待同步完毕；
-6. Master2 Agent 上线写 VIP，把 Master2 节点设为 read_only=0；
-7. Monitor 发送更改同步对象的指令到各个 Slave 节点的 Agent；
-8. 各个 Slave 节点向新 Master 同步数据；
+MMM (Master-Master replication manager for MySQL) 是由 Perl 语言开发的一套支持双主故障切换以及双主日常管理的第三方软件。它包含两类角色：`writer` 和 `reader `，分别对应读写节点和只读节点。使用 MMM 管理的双主节点在同一时间上只允许一个进行写入操作，当 `writer` 节点出现宕机（假设是 Master1），程序会自动移除该节点上的读写 VIP，然后切换到 Master2 ，并设置 Master2 的 read_only = 0，即关闭只读限制，同时将所有 Slave 节点重新指向  Master2。
 
-简单来说，MMM 就是暴力的将 Master1 切换到 Master2 ，它本生不会尝试去补齐丢失的数据。
+除了管理双主节点，MMM 也负责管理所有 Slave节点，在出现宕机、复制延迟或复制错误，MMM 会移除该节点的 VIP，直至节点恢复正常。MMM 高可用的架构示例图如下：
+
+
+
+
+
+MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补齐丢失的数据，所以会存在数据不一致性的风险。另外 MMM 的发布时间比较早，所以其也不支持 MySQL 最新的基于 GTID 的复制，如果你使用的是基于 GTID 的复制，则只能采用 MHA。
 
 ### 4.2 MHA
 
+MHA (Master High Availability) 是由 Perl 实现的一款高可用程序，相对于 MMM ，它能尽量避免数据不一致的问题。它监控的是一主多从的复制架构，架构如下图所示：
+
+
+
+
+
+在 Master 节点宕机后，其处理流程如下：
+
 1. 尝试从宕机 Master 中保存二进制日志；
 2. 找到含有最新中继日志的 Slave；
 3. 把最新中继日志应用到其他实例，实现各实例数据一致；
@@ -266,31 +310,22 @@ GTID 复制的优点在于程序可以自动确认开始复制的 GTID 点。但
 5. 提升一个 Slave 为 Master ；
 6. 其他 Slave 向该新 Master 同步。
 
-当 Master 宕机后， MHA 会尝试保存宕机 Master 的二进制日志，然后自动判断 MySQL 集群中哪个实例的中继日志是最新的，并将有最新日志的实例的差异日志传到其他实例补齐，从而实现所有实例数据一致。然后把宕机 Master 的二进制日志应用到选定节点，并提升为 Master 。
-
-从切换流程流程可以看到，如果宕机 Master 主机无法 SSH 登录，那么第一步就没办法实现，对于 MySQL5.5 以前的版本，数据还是有丢失的风险。对于 5.5 后的版本，开启**半同步复制**后，真正有助于避免数据丢失，半同步复制保证至少一个 （不是所有）slave 在 master 提交时接收到二进制日志事件。因此，对于可以处理一致性问题的 MHA 可以实现"几乎没有数据丢失"和"从属一致性"。
-
-### 优点
-
-- 开源，用 Perl 编写
-- 方案成熟，故障切换时，MHA 会做日志补齐操作，尽可能减少数据丢失，保证数据一
-- 部署不需要改变现有架构
-
-### 限制
-
-- 各个节点要打通 SSH 信任，有一定的安全隐患
-- 没有 Slave 的高可用
-- 自带的脚本不足，例如虚IP配置需要自己写命令或者依赖其他软件
-- 需要手动清理中继日志
+按照以上的处理流程，MHA 能够最大程序的避免数据不一致的问题。但如果 Master 所在的服务器也宕机了，那么过程的第一步就会失败。在 MySQL 5.5 后，可以开启半同步复制后来避免这个问题，从而可以保证数据的一致性和几乎无丢失。当然 MHA 集群也存在一下一些缺点：
 
+- 集群中所有节点之间需要开启 SSH 服务，所以会存在一定的安全影响。
+- 没有实现 Slave 的高可用。
+- 自带的脚本不足，例如虚拟 IP 的配置需要自己通过命令或者其他第三方软件来实现。
+- 需要手动清理中继日志。
 
+以上就是 MMM 和 MHA 架构的简单介绍，关于其具体搭建步骤，可以以下两篇参考博客： [MySQL集群搭建(3)-MMM高可用架构](https://segmentfault.com/a/1190000017286307) 和  [MySQL集群搭建(5)-MHA高可用架构](https://segmentfault.com/a/1190000017486693)。
 
 
 
 ## 参考资料
 
-+ [MHA高可用架构](https://segmentfault.com/a/1190000017486693)
++ [Chapter 17 Replication](https://dev.mysql.com/doc/refman/8.0/en/replication.html)
++ [GTID Format and Storage](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.html)
++ [MySQL半同步复制](https://www.cnblogs.com/ivictor/p/5735580.html)
++ [MySQL集群搭建(3)-MMM高可用架构](https://segmentfault.com/a/1190000017286307)
++ [MySQL集群搭建(5)-MHA高可用架构](https://segmentfault.com/a/1190000017486693)
 
-+ [MMM高可用架构](https://segmentfault.com/a/1190000017286307)
-
-+ 
\ No newline at end of file