mysql 自定义序列号_在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(*)

查询结果存在，证明服务器上运行了自动重新加入过程。

到目前为止的重试次数

如果正在进行自动重新加入程序，我们可以通过选择阶段事件上的工作单元数来检查到目前为止尝试的重试次数：

SELECT WORK_COMPLETED FROM performance_schema.events_stages_current WHERE

EVENT_NAME LIKE '%auto-rejoin%';

WORK_COMPLETED

在这个例子中，到目前为止只有一次尝试。

预计到下次重试的剩余时间

在每次重新加入尝试之间，服务器将处于 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 模式，直到重新加入该组。但在此期间，重新加入成员的同步旧数据的可能性将增加。自动重新加入过程可监控，而驱逐超时不是真正可监控的。

所以，总结一下：

驱逐超时的优点

- 该成员一直在该组内

- 可能更适合足够小的网络故障

驱逐超时的缺点

- 在怀疑某个成员时，无法在该组上添加/删除成员

- 在怀疑某个成员时，无法选择新的主机

- 您无法监控此过程

自动重新加入的优点

- 该组将在没有重新加入成员的情况下运行，您可以添加/删除成员并选择新的主机

- 您可以监控该过程

自动重新加入的缺点