参考官方文档：
https://dev.mysql.com/doc/refman/5.7/en/replication-solutions.html




16.3.1 使用复制来备份



要将复制用作备份解决方案，请将数据从主服务器复制到从服务器，然后备份数据从服务器。 从站可以暂停和关闭，而不会影响主站的运行操作，因此您可以生成“实时”数据的有效快照，否则需要关闭主站。



备份数据库的方式取决于它的大小以及是仅备份数据，还是备份数据和复制从属状态，以便在发生故障时重建从站。 因此有两种选择：

• 如果您使用复制作为解决方案以使您能够备份主服务器上的数据，并且数据库的大小不是太大，则mysqldump工具可能是合适的。
• 对于较大的数据库，其中mysqldump不切实际或效率低下，您可以备份原始数据文件。 使用原始数据文件选项还意味着您可以备份二进制文件和中继日志，以便在从站发生故障时重新创建从站。

另一种可用于主服务器或从服务器的备份策略是将服务器置于只读状态。 对只读服务器执行备份，然后将其更改回其通常的读/写操作状态。



16.3.1.1 使用 mysqldump 备份slave


使用mysqldump创建数据库副本使您能够以一种格式捕获数据库中的所有数据，该格式使信息能够导入到另一个MySQL服务器实例中。 由于信息的格式是SQL语句，因此在紧急情况下需要访问数据时，可以轻松地将文件分发并应用于正在运行的服务器。 但是，如果数据集的大小非常大，则mysqldump可能不切实际。


使用mysqldump时，应在启动转储过程之前停止从属服务器上的复制，以确保转储的数据一致：

• 阻止从服务器处理请求。 您可以使用mysqladmin在slave上完全停止复制：

shell> mysqladmin stop-slave


或者，您可以仅停止从属SQL线程以暂停事件执行：


shell> mysql -e 'STOP SLAVE SQL_THREAD;'




这使从站能够继续从主站的二进制日志接收数据更改事件，并使用I / O线程将它们存储在中继日志中，但阻止从站执行这些事件并更改其数据。 在繁忙的复制环境中，允许I / O线程在备份期间运行可能会在您重新启动从属SQL线程时加快追赶过程。

• 运行 mysqldump 去导出数据库，例如导出所有数据库：

shell> mysqldump --all-databases > fulldb.dump

• 转储完成后，再次启动从属操作：

shell> mysqladmin start-slave




16.3.1.2 从slave 中备份 原始数据


为了保证复制文件的完整性，应在从属服务器关闭时备份从属服务器上的原始数据文件。 如果MySQL服务器仍在运行，后台任务可能仍在更新数据库文件，特别是涉及具有后台进程（如InnoDB）的存储引擎的数据库文件。 使用InnoDB时，应该在崩溃恢复期间解决这些问题，但由于可以在备份过程中关闭从属服务器而不影响主服务器的执行，因此利用此功能是有意义的。


要关闭服务器并备份文件：


1.关闭 slave Mysql 服务器：
shell> mysqladmin shutdown


2.复制数据文件。 您可以使用任何合适的复制或存档实用程序，包括cp，tar或WinZip。 例如，假设数据目录位于当前目录下，您可以按如下方式归档整个目录：


shell> tar cf /tmp/dbbackup.tar ./data


3.再一次启动MYSQL 服务器:


shell> mysqld_safe &




通常，您应该备份从MySQL服务器的整个数据目录。如果您希望能够恢复数据并作为从设备运行（例如，在从设备发生故障的情况下），那么除了从设备的数据外，您还应该备份从设备状态文件，即主设备信息和中继日志信息存储库以及中继日志文件。恢复从属数据后，需要这些文件才能恢复复制环境。


如果丢失了中继日志但仍有http://relay-log.info文件，则可以检查它以确定SQL主线在主二进制日志中执行了多远。然后，您可以将CHANGE MASTER TO与MASTER_LOG_FILE和MASTER_LOG_POS选项一起使用，以告知从属设备从该点重新读取二进制日志。这要求主服务器上仍存在二进制日志。


如果您的从服务器正在复制LOAD DATA INFILE语句，则还应备份从服务器用于此目的的目录中存在的任何SQL_LOAD- *文件。从站需要这些文件来恢复任何中断的LOAD DATA INFILE操作的复制。此目录的位置是--slave-load-tmpdir选项的值。如果未使用该选项启动服务器，则目录位置是tmpdir系统变量的值。




16.3.5 在故障的时候切换Master




您可以使用CHANGE MASTER TO语句告知从站变更为新的主站。 从站不检查主站上的数据库是否与从站上的数据库兼容; 它只是从新主控二进制日志中的指定坐标开始读取和执行事件。 在故障转移情况下，组中的所有服务器通常都是从同一个二进制日志文件中执行相同的事件，因此更改事件源不应影响数据库的结构或完整性。


slave 需要使用--log-bin 选项运行，并且如果未使用GTIDs 那么应该使用--log-slave-updates 运行。在这个情况下，slave 准备成为master，不用重启slave mysqld。




16.3.10 延时复制


MySQL 5.7支持延迟复制，使得从属服务器故意滞后于主服务器至少一段指定的时间。 默认延迟为0秒。 使用CHANGE MASTER TO的MASTER_DELAY选项将延迟设置为N秒：



CHANGE MASTER TO MASTER_DELAY = N;


从主站接收的事件至少比在主站上执行的时间晚至少N秒才执行。 例外情况是格式描述事件或日志文件旋转事件没有延迟，这只会影响SQL线程的内部状态。



延迟复制可用于多种目的：

• 防止用户在主服务器上出错。 DBA可以将延迟的从站回滚到灾难发生前的时间。
• 测试滞后时系统的行为方式。 例如，在应用程序中，延迟可能是由从属设备上的重负载引起的。 但是，生成此负载级别可能很困难。 延迟复制可以模拟滞后而无需模拟负载。 它还可用于调试与滞后从站相关的条件。
• 要检查数据库很久以前的样子，而不必重新加载备份。

START SLAVE和STOP SLAVE立即生效并忽略任何延迟。 RESET SLAVE将延迟重置为0。


SHOW SLAVE STATUS有三个字段，提供有关延迟的信息：

• SQL_Delay：非负整数，表示从站必须滞后主站的秒数。
• SQL_Remaining_Delay：当Slave_SQL_Running_State等待主执行事件后的MASTER_DELAY秒时，该字段包含一个整数，指示延迟剩余的秒数。 在其他时候，此字段为NULL。
• Slave_SQL_Running_State：一个字符串，指示SQL线程的状态（类似于Slave_IO_State）。 该值与SHOW PROCESSLIST显示的SQL线程的State值相同。

当从属SQL线程在执行事件之前等待延迟时，SHOW PROCESSLIST将其状态值显示为 Waiting until MASTER_DELAY seconds after master executed event.