随着 MySQL 8.0.16 的发布，我们为 MGR 添加了一些功能，以增强其高可用性。其中一个功能是能够在某些情况下启用已离开组的成员自动重新加入，而无需用户干预。
创新互联公司凭借在网站建设、网站推广领域领先的技术能力和多年的行业经验，为客户提供超值的营销型网站建设服务，我们始终认为：好的营销型网站就是好的业务员。我们已成功为企业单位、个人等客户提供了网站建设、成都网站制作服务，以良好的商业信誉，完善的服务及深厚的技术力量处于同行领先地位。
为了理解这个功能的好处以及如何使用它，我们将快速查看它背后的概念以及它首先存在的动机。
介绍
MGR 允许 MySQL 用户轻松管理高可用组，并完成保证系统高可用所需的所有特征，例如容错或故障检测。
MGR 中提供的基本保证之一是该组呈现给用户的是一个不可分割的整体，这意味着一旦成员加入或离开该组，该更改将立即被其他成员得知。默认情况下，组内的数据本身最终是一致的，尽管可以被修改。为了实现这种保证，MGR 使用组成员服务，以及通过一致性算法检测有冲突的事务并中止它们。MGR 的这一方面超出了本文的范围，与成员自动重新加入功能并不完全相关，本文不作赘述。
组内新成员必须符合一些条件。其中新成员需要在事务方面赶上组进度（是通过选择组内一个成员来将已处理的事务流式传输给他，在 MGR 中称为“捐赠”）。最后，只要在此“分布式恢复”过程中没有遇到任何错误，组内新成员将被声明为 ONLINE 状态。
MGR 依靠组通信层 (GCS) 来管理组。该层实现了用于解决冲突事务的一致性算法，并强制执行一些通信特性。对于实现前面提到的组的不可分割视图，这些特性至关重要，如消息的总顺序、安全传递或视图同步等。
GCS 需要能够检测组中哪些成员失效或看起来失效。一旦这些成员被检测为失效，就将其从该组中移除，以便保持该组正常使用。为此 GCS 在每个成员中引入了一个故障检测器，用于分析组内交换的消息。如果它在一段时间内没有收到来自指定成员的消息，则故障检测器将对该成员产生“怀疑”，并认为该成员可能已经失效。成员从“怀疑”到真正失效的等待时间是可以配置的。
重新加入成员存在的问题
我们已经了解 MGR 必须为了高可用提供的策略，以及它如何实现，接下来请看示例：
一个小组由三个成员组成，其中一个成员偶尔会遇到丢失数据包、断连或者其它导致无法解决的错误情况的影响组内通信。还要考虑这些错误持续时间超过 group_replication_member_expel_timeout的值。
其中一个组员发生故障，小组的其他成员将决定踢出该成员。问题是，一旦该成员重新入组，他将被组驱逐加入失败，需要通过手动干预。
如果该成员的驱逐超时属性设置不为 0，则它将在被驱逐前等待满足该时间量（将超时设置为 0 意味着他将永远等待）。超时后成员将被驱逐并重新建立连接，并且无法重新加入旧组，需要再次手动干预。
于此，当存在网络故障时，显然需要手动干预。
在 MySQL 8.0.16 中，我们引入了自动重新加入组的功能，一旦成员被驱逐出组，它就会自动尝试重新加入该组，直到达到预设的次数为止。有时每次重试之间至少等待5分钟。
如何启动自动重新加入？
可以通过将group_replication_autorejoin_tries设置为所需的重试次数来开启并使用自动重新加入功能。
SET GLOBAL group_replication_autorejoin_tries = 3
默认值为 0，表示服务器禁用自动重新加入。
如何验证自动重新加入？
与 MySQL 中的许多功能一样，自动重新加入过程是可以监测的。自动重新加入的可检测性依赖于性能模式基础架构，阶段式收集有关数据。
他们获取以下信息：
事件发生的线程ID（THREAD_ID）
活动名称（EVENT_NAME）
起止时间戳以及事件的总持续时间（TIMER_START，TIMER_END 和 TIMER_WAIT）
在事件停止之前完成的工作单位和预估工作单位（WORK_COMPLETED，WORK_ESTIMATED）
因此，当自动重新加入过程开始时，它将在performance schema中注册一个名为“stage / grouprpl / Undergoing auto-rejoinprocedure”的事件。使用表performance_schema.events_stage_current， performance_schema.events_stages_summary_global_by_event_name和performance_schema.events_stages_history_long我们可以观察到以下内容：
是否正在进行自动重新加入程序
到目前为止，已经减少重试的次数
直到下一次重试的估计剩余时间
自动重新加入过程状态
可以通过过滤包含“auto-rejoin”字符串的活动事件来查找自动重新加入过程状态（即，是否正在进行）：
SELECT COUNT(*) FROM performance_schema.events_stages_current
WHERE EVENT_NAME LIKE '%auto-rejoin%';
COUNT(*)
1
查询结果存在，证明服务器上运行了自动重新加入过程。
到目前为止的重试次数
如果正在进行自动重新加入程序，我们可以通过选择阶段事件上的工作单元数来检查到目前为止尝试的重试次数：
SELECT WORK_COMPLETED FROM performance_schema.events_stages_current WHERE
EVENT_NAME LIKE '%auto-rejoin%';
WORK_COMPLETED
1
在这个例子中，到目前为止只有一次尝试。
预计到下次重试的剩余时间
在每次重新加入尝试之间，服务器将处于 5 分钟的可中断睡眠中。 重新加入尝试直到成功或失败之间的时间是无法估计的。 因此，为了粗略估计剩余时间，我们可以将到目前为止尝试的重试次数乘以 5 分钟，并减去到目前为止的阶段事件所花费的时间，以估计我们还需要多长时间：
SELECT (300.0 - ((TIMER_WAIT*10e-12) - 300.0 * num_retries)) AS time_remaining FROM
(SELECT COUNT(*) - 1 AS num_retries FROM
performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%') AS T,
performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%';
time_remaining
30.0
所以在这个例子中，在下一次重新加入之前还有 30 秒。注意性能模式表中的所有时间记帐都以微秒精度保持，因此我们将 TIMER_WAIT 缩放为秒。
使用自动重新加入与驱逐超时的权衡
到目前为止，在这篇文章中我们只关注自动重新加入。实际上，有两种不同的方法可以实现离开组的成员的重新加入：
设置自动重新加入尝试次数来实现自动重新加入
设置该成员的驱逐超时时间然后配合手动干预
能有延缓删除组内可疑成员，并且如果配置为足够长的驱逐超时时间，则增加了重新建立连接的机会，再次与组进行交互。
虽然这两个功能实现了相同的目标，但它们的工作方式是不同的，并且需要权衡。通过使用驱逐超时，您可以维护组中可疑的成员，其缺点是您无法添加或删除成员或选择新的主机。如果通过使用自动重新加入，该成员将不再是该组的正常组员，将保持在 superreadonly 模式，直到重新加入该组。但在此期间，重新加入成员的同步旧数据的可能性将增加。自动重新加入过程可监控，而驱逐超时不是真正可监控的。
所以，总结一下：
驱逐超时的优点
- 该成员一直在该组内
- 可能更适合足够小的网络故障
驱逐超时的缺点
- 在怀疑某个成员时，无法在该组上添加/删除成员
- 在怀疑某个成员时，无法选择新的主机
- 您无法监控此过程
自动重新加入的优点
- 该组将在没有重新加入成员的情况下运行，您可以添加/删除成员并选择新的主机
- 您可以监控该过程
自动重新加入的缺点
- 您增加了重新加入成员上过时读取的可能性
- 可能不适合足够小的网络故障
总而言之，我从启用自动重新加入中获得了什么？
通过启用自动重新加入，您可以减少对MySQL实例的手动干预的需要。您的系统
更加适应瞬间网络故障，同时满足对容错性和高可用的保证。
摘要
我们引入了一个名为group_replication_autorejoin_tries的新系统变量，允许用户设置 MGR 成员在被驱逐或与组的大多数人失去联系后尝试重新加入组的次数。
默认情况下，此自动重新加入过程处于关闭状态。它能帮助用户在面对瞬间网络故障时避免对 MGR 成员进行手动干预。
停止mysql
# /etc/init.d/mysqld stop
安全模式进入mysql
# /usr/sbin//mysqld_safe --skip-grant-tables
完成以后就可以不用密码进入MySQL了
# mysql -u root
按下列步骤建立 root 用户：
insert into mysql.user (host, user, password) values ('localhost', 'root', password('密码'));
flush privileges;
grant all on *.* to 'root'@'localhost';
1、查找以前是否装有mysql
命令：rpm
-qa|grep
-i
mysql
可以看到如下图的所示：
说明之前安装了：
MySQL-client-5.5.25a-1.rhel5
MySQL-server-5.5.25a-1.rhel5
2、停止mysql服务、删除之前安装的mysql
删除命令：rpm
-e
–nodeps
包名
#
rpm
-ev
MySQL-client-5.5.25a-1.rhel5
#
rpm
-ev
MySQL-server-5.5.25a-1.rhel5
3、查找之前老版本mysql的目录、并且删除老版本mysql的文件和库
find
/
-name
mysql
查找结果如下：
[root@localhost
~]#
find
/
-name
mysql
/var/lib/mysql
/var/lib/mysql/mysql
/usr/lib64/mysql
删除对应的mysql目录
rm
-rf
/var/lib/mysql
rm
-rf
/var/lib/mysql
rm
-rf
/usr/lib64/mysql
具体的步骤如图：查找目录并删除
注意：卸载后/etc/my.cnf不会删除，需要进行手工删除
rm
-rf
/etc/my.cnf
4、再次查找机器是否安装mysql
rpm
-qa|grep
-i
mysql
无结果，说明已经卸载彻底、接下来直接安装mysql即可
如果你要恢复的数据库是包含授权表的mysql数据库，您将需要使用--skip赠款-tables选项来运行服务器恢复整个数据库
- 首先，。否则，服务器会抱怨不能找到授权表。恢复表后，执行mysqladmin冲水privileges告诉服务器装载授权表，并用它们来启动。数据库目录到其他地方的原始内容
复制。例如，您可以使用它们在以后的事后分析检查表（验尸）的崩溃。
酒店与最新的数据库备份文件重新加载。如果您打算使用mysqldump的所加载的文件，则需要输入它们作为mysql的。如果您打算使用从数据库文件直接拷贝（例如，使用tar或CP），它会复制他们直接回数据库目录中。然而，在这种情况下，你应该在关闭之前，该服务器复制这些文件，然后重新启动它。在备份过程中
重做日志，然后查询更新数据库表中。对于所有可用的更新日志，你可以使用它作为mysql的输入。指定--one-database选项，因此MySQL只是要还原的数据库执行查询。如果你意识到有必要使用所有的更新日志文件，可以使用包含以下命令日志的目录：
％LS-TRL更新（0-9）* | xargs的猫| mysql--。一个数据库DB_NAME
ls命令生成一个单独的日志文件更新列表，更新日志文件根据服务器（你知道，如果你其中的任何文件，排序顺序生成的顺序进行排序会发生变化，这将导致在更新日志中以错误的顺序使用）。有限公司您可能需要使用一些更新日志。例如，如果日志，因为命名update.392备份，pdate.393等产生的，可以在命令重新运行它们：
％的mysql - 一个数据库DB_NAME 录入。 392
％的mysql - 一个数据库DB_NAME updata.393 ...
如果您正在运行的恢复，并打算使用更新日志恢复由于失误降数据的基础上，DROPTABLE或DELETE语句和丢失的信息时，一定要在开始更新日志删除这些语句。
恢复单个表
恢复单个表是非常困难的。如果是的mysqldump备份文件生成的，它只是不包含数据，您需要一个表，你需要提取的相关线路，并利用它们作为mysql的输入，这部分比较容易。困难的是，提取在该表的更新日志中使用的片段。你会发现：mysql_find_rows工具在这方面有所帮助，它可以提取多行从更新日志查询。另一种可能性是使用另一台服务器
恢复整个数据库，然后将该文件复制到表的原始数据库。这其实很容易！当文件被复制回数据库目录，确保原始数据库服务器关闭。
使用mysql中的日志功能。
首先：将最近的二进制类型的日志文件存成文本文件导出，命令如下：
mysqlbinlog F:/wamp/mysql-bin.000045 F:/test.txt
其次：打开保存的txt文件，文件格式如下：
其中at 1099代表第1099个命令（姑且这么记），查询这些命令，看看需要回复的命令在什么地方，然后执行命令。
最后：执行回复命令，如下：
mysqlbinlog --start-position="123" --stop-position="531" F:/wamp/mysql-bin.000045 F:/test.txt | mysql -uroot -p
这样就可以完成数据库的回复了！！！
