DBA之路的博客

原创 【MHA】MySQL高可用MHA介绍3-命令详解

可以通过执行 masterha_manager 命令来启动 MHA Manager。masterha_manager 接受以下参数。

原创 【MHA】MySQL高可用MHA介绍2-安装,配置,要求与限制

MHA可以管理master1和master2，并在master1崩溃时将master2提升为新主服务器，但是MHA无法监视和恢复slave3，因为slave3从不同的主服务器（master2）复制。在MHA Manager版本0.52之前，MHA检查所有受管理的主机，并仅在所有从服务器从同一主服务器复制时才开始监视/故障转移。当MHA执行基于GTID的故障转移时，MHA会检查binlog服务器，如果binlog服务器领先于其他从服务器，MHA会在恢复之前将差异binlog事件应用于新主服务器。

原创 【MHA】MySQL高可用MHA介绍1-功能，架构，优势，案例

MHA（Master High Availability）执行自动化的主服务器故障转移和从服务器提升，最小化停机时间，通常在10-30秒内完成。MHA可以防止复制一致性问题，并节省了获取额外服务器的费用。所有这些操作都不会造成性能下降，没有复杂性（易于安装），也不需要对现有部署进行任何更改。MHA还提供了定期在线主服务器切换功能，安全地将当前运行的主服务器切换到新主服务器，仅需几秒钟的停机时间（仅阻止写入）。MHA Manager有管理程序，例如监控MySQL主数据库，控制主故障转移等。

原创 【报错】note: module requires Go 1.18

重新运行go脚本。

原创 【报错】Cannot proceed because system tables used by Event Scheduler were found damaged at server start

重启 MySQL服务。

原创 【GO】HTTP标准库1 - http协议基础知识

超文本传输协议。

原创 Go编译报错 link: running gcc failed: exit status 1（已解决）

GNU C 库是 Linux 系统中最基本的 C 库之一，它提供了许多标准 C 库函数的实现，如内存分配、字符串操作、文件操作等。是 GNU Compiler Collection 的缩写，它是一套包括编译器在内的工具集，用于编译和链接程序。允许开发者将库的代码和数据嵌入到他们的可执行文件中，这意味着在运行时不需要依赖系统上已安装的动态链接版本的。可以在构建软件时执行许多任务，如链接不同的目标文件以创建可执行文件、将可执行文件拆分成独立的目标文件等。等库文件，您可以在编译时链接到您的程序中。

原创 【MGR】MySQL Group Replication 中文官方文档

MySQL Group Replication是一个MySQL服务器插件，可以创建弹性、高可用和容错的复制拓扑。或者，对于更高级的用户，可以将组部署在多主模式下，其中所有服务器都可以接受更新，即使它们同时被发出。由于中文版的官方文档应该是通过谷歌翻译直接进行翻译，读起来晦涩难懂，刚好最近在调研MGR，所以对官方文档进行了翻译，翻译版本是5.7。第17.9节“Group Replication技术细节”提供了关于Group Replication工作原理的深入信息。解释了复制组 的架构和设置要求以及限制。

原创 【MGR】MySQL Group Replication 管理操作

第一次引导组和第二次或后续引导组之间的区别在于，在后一种情况下，已关闭组的成员可能具有彼此不同的事务集，这取决于它们停止或失败的顺序。对于Group Replication，这包括已提交和已应用的事务，位于gtid_executed GTID集中的事务，以及已认证但尚未应用的事务，位于group_replication_applier通道中。例如，在上述5台服务器的场景中，如果3台服务器同时离开，则如果这3台离开的服务器依次通知组它们正在离开，那么成员资格可以从5个调整到2个，并在此过程中保持法定人数。

原创 【MGR】MySQL Group Replication 监控

根据此结果，我们可以看到该组由三个成员组成，每个成员的主机和端口号，客户端用于连接到成员的端口号，以及成员的服务器UUID。请注意，远程成员的统计信息的刷新受group_replication_flow_control_period选项中指定的消息周期的控制，因此这些统计信息可能与在查询时收集的成员的本地统计信息略有不同。因此，它们报告一些服务器无法访问，而不是猜测它们的状态。更准确地说，事务以相同的顺序传递给所有组成员，但它们的执行不是同步的，这意味着在事务被接受提交后，每个成员以自己的速度提交。

原创 【MGR】MySQL Group Replication 要求与限制

这是因为导致由多主模式组执行的级联操作的外键约束可能导致在组的成员之间未检测到的冲突，并导致组的成员之间的数据不一致。当从MySQL 5.7.37或更早版本升级到MySQL 5.7.38或更高版本时，如果您的Group Replication服务器以前接受的事务大于新的默认限制，并且您允许group_replication_transaction_size_limit默认为旧的零限制，那么在升级到新默认值后，这些事务将开始失败。写集基于每行的主键，并且是标识已更改的行的简化和紧凑视图的标签。

原创 【MGR】MySQL Group Replication快速开始

通常，group_replication_group_seeds列表包含每个组成员的group_replication_local_address的主机名:端口，但这不是强制性的，可以选择组成员的子集作为种子。换句话说，在s2上，group_replication_bootstrap_group设置为off，您在启动Group Replication之前不需要发出SET GLOBAL group_replication_bootstrap_group=ON;但在另一个失败的情况下，组将无法继续处理写事务。

原创 【MGR】MySQL Group Replication 背景

MySQL Group Replication以及如何安装、配置和监视群组。MySQL Group Replication是MySQL服务器的插件，可以创建弹性、高可用、容错的复制拓扑结构。群组可以在单主模式下运行，具有自动主选举功能，这意味着一次只有一个服务器接受更新。或者，对于更高级的用户，群组可以部署在多主模式下，其中所有服务器都可以接受更新，即使它们同时发生。内置的群组成员服务可以保持群组的视图一致，并在任何时候为所有服务器提供可用。服务器可以离开和加入群组，视图会相应更新。

原创 Orchestrator源码解读 - 如何执行钩子脚本

如果你在该脚本中 调用了修改域名后端的IP，或者修改LVS后端的RS，在修改不成功时 ，则钩子脚本返回一个非零的值即可终止恢复流程。--> generateShellScript // 生成shell 脚本。--> applyEnvironmentVariables // 环境变量。支持钩子脚本，即在恢复过程调用的外部脚本。--> prepareCommand // 组装脚本。--> executeProcess // 执行脚本。配置了两个脚本，第一个是shell 脚本，第二个是一个go脚本，

原创 Orchestrator配置3- 半同步复制

在一些环境中，不仅控制半同步复制副本的数量很重要，还要控制副本是半同步还是异步。orchestrator可以检测到不希望的半同步配置，并切换半同步标志rpl_semi_sync_slave_enabled和rpl_semi_sync_master_enabled以纠正情况。

原创 Orchestrator配置2 - 延迟相关

该参数不会影响到新主的选举，主要影响 拓扑结构改变，从副本的移动。以及在其他从副本能否可以成为新主的从。

原创 Orchestrator配置1 - 阻塞故障发现恢复参数

小于FailureDetectionPeriodBlockMinutes时间内的同一个实例不会发现 `hostname`,`port`,`in_active_period`,`end_active_period_unixtime`,`is_actionable`都相同的故障。即不会注册该故障我第一次是发现 AllMasterReplicasNotReplicating 类型故障，第二次是发现 DeadMaster 类型的故障，两种类型的不同，所以能在60分钟发现两次故障官方文档。

原创 【MySQL复制】半同步复制

除了内置的异步复制之外，MySQL 5.7 还支持通过插件实现的半同步复制接口。本节讨论半同步复制的概念及其工作原理。接下来的部分将涵盖与半同步复制相关的管理界面，以及如何安装、配置和监控它。

原创 orchestrator介绍3.4 web API 的使用

如果已知副本具有伪 GTID 坐标，则为 true（请参阅相关。：如果副本通过 Oracle GTID 复制，则为 true。：如果使用Oracle GTID，执行的GTID集。（尝试）将一个实例的副本移动到另一个实例下方。：假设有需要恢复的内容，在给定实例上启动恢复。：（复制时）现在正在执行的master坐标（（尝试）将一个实例移动到另一个实例下方。作为您的 API 客户端，这就是它的用途。：（复制时）从主机读取的坐标（轮询的内容。：（复制时）当前正在执行的中继日志的坐标。

原创 orchestrator介绍3.3 web界面的使用

当您的实例或其目标主机出现问题（滞后太多、不复制等）时，将不允许删除您的实例，从而确保您的安全。如果它发现更深的块，例如没有二进制日志的目标，它可能允许删除并仍然中止操作。在以下界面中输入集群中任意一个实例的信息，可以是主服务器或副本服务器。直观地显示与复制和可访问性相关的问题：副本滞后、复制中断、实例长时间未访问、实例访问失败、实例正在维护。复杂的重构是通过执行多个这样的步骤来完成的。单击此图标将打开一个页面，其中包含该实例上的一些额外信息以及要执行的操作。关联，该名称（当前）以拓扑的主节点命名。

原创 orchestrator介绍3.2 命令行之orchestrator-client

是一个包装 API 调用的脚本，使用起来更方便。它可以自动确定，并在这种情况下将所有请求转发给Leader。有了。

原创 【MySQL源码】Seconds_Behind_Master是如何计算的

作为MySQL DBA，相信大家对参数 `Seconds_Behind_Master` 并不陌生，该字段的值可以通过 show slave status\G的输出，表示主从延迟的时间，单位为秒。监控主从延迟一般取这个值就足够了。0 表示无延迟，理想状态该值不要超过1。如果业务场景中有写后读，而且读的是从库，那么就会对主从延迟要求非常高。理解了该字段的含义，大家有没有探究过该值是如何计算的？相信大家都可以说出来 是从库的时间 减去 SQL_thread应用到的主库binlog event的时间戳。今天从官

原创 【MySQL故障】主从延迟越来越大

Relay_Master_Log_File 与 Exec_Master_Log_Pos（sql_thread 应用的relay_log对应主库文件和位点）Master_Log_File 与 Read_Master_Log_Pos （读取到的主库的binlog文件和位点）首先确认落后是在 IO_thread（拉取binlog日志） 还是在 SQL_thread（应用binlog日志）修改relay log的落盘参数，sync_relay_log 原来设置的是1 ，该大一些。

原创 Orchestrator源码解读4-计划内切换

你会发现graceful-takeover与真正的故障转移（failover）有些相似，有些操作是不同的。，更高级的用还有停止代理层的流量等。Orchestrator 提供了专门的钩子脚本来进行计划内的切换，分别用于迁移前和迁移后的一下定制需求。该操作可能需要几秒钟，在此期间您的应用程序预计会告警或者报错，因为主服务器是只读的。通常因为升级，服务器为何等原因，需要按照计划将主库迁移到其他实例的情况。将老主的一个直接副本拖拽到老主的左边，将使用。在正常的故障转移前、后过程中，您可以使用。

原创 Orchestrator源码解读3-故障处理阶段

文接上篇，，上篇介绍了如何发现故障或失败。Orchestrator会对被管理的数据库进行状态信息数据收集，在故障发现阶段在后台管理数据库（benkend）进行一个复杂查询，有些状态值已经在该复杂SQL中进行了判断。根据SQL查询的值会存储到结构体ReplicationAnalysis中，判断故障类型主要是根据结构体ReplicationAnalysis中的字段。这些故障类型有的需要进行处理，有些不需要实际处理。本篇文章主要详细解读根据故障类型 选择的 故障处理函数逻辑。

原创 Orchestrator源码解读2-故障失败发现

Orchestrator另外一个重要的功能是监控集群，发现故障。根据从复制拓扑本身获得的信息，它可以识别各种故障场景。

原创 Orchestrator源码分析1-实例/拓扑发现

该函数执行期间 每1秒执行一次 UpdateInstanceLastAttemptedCheck 更新 last_attempted_check 字段。每秒执行一次该函数：访问给定实例之前更新数据库中的时间戳。这是一种防范机制，用于处理访问实例时发生挂起的情况。如果时间戳新于，则表示出现了问题，可能是由于实例访问挂起导致的。and port =?`,

原创 TIDB PTCA真题

原创 【MySQL变更】gh-ost原理解读

所有现有的在线表结构变更工具都以相似的的原理：它们创建一个与原始表结构相同的幽灵表，在该表为空时进行表结构变更，缓慢并增量地将数据从原始表复制到幽灵表，同时将正在进行的更改（任何INSERT, DELETE,UPDATE应用于源表）应用到幽灵表。最后，在适当的时候，他们用幽灵表替换原表。gh-ost使用相同的模式。然而，它与所有现有工具的不同之处在于不使用触发器。因为触发器是许多限制和风险的来源。gh-ost 使用二进制日志流来捕获表数据变化，并将它们异步应用到ghost表上。

原创 【MySQL工具】pt-online-schema-change源码分析

通过阅读源码 更加深入了解原理，以及如何进行全量数据同步，如何使用触发器来同步变更期间的原表的数据更改。(＾－＾)V。

原创 【MySQL工具】pt-online-schema-change 详细介绍

无锁表修改表结构工具。

原创 【MySQL命令】show slave status\G 超详细全面解释

这个命令是DBA日常运维中常用来查看主从状态的命令，很多备份，监控工具也会使用到该命令监控主从状态是否正常，主从延迟，获取位点信息等。作为常用日常命令，一定要完全理解该命令的输出。今天主要结合 官方文档 和 实际输出 详细解释该命令。达到完全搞懂！该语句提供有关副本线程的基本参数的状态信息。它需要 SUPER 或特权。建议使用\G。

原创 【MySQL备份】MySQL备份工具-MyDumper

MyDumper是一个MySQL逻辑备份工具。mydumper负责导出 MySQL 数据库的一致备份myloader从 mydumper 读取备份，连接到目标数据库并导入备份。这两个工具都使用多线程功能。MyDumper优势有哪些速度更快 - 多线程并发备份性能更好 - 避免昂贵的字符集转换，整体代码高效易于管理的输出文件 -（比如每个表都能生成单独的备份文件，备份的元数据信息文件metadata记录位点信息等等，便于查看/解析数据）

原创 如何写出高质量博客的思考

4 实践出真知或者原来的经验总结 ，自己亲手去实践，在实际应用中积累的经验，也是写技术文章很宝贵的财富。否则很多东西浮于表面。1 首先翻译阅读官方文档 ，如果你想要学习和了解的技术产品有官方文档 一般是最权威 ，最全面的。2 有能力的话可以查看源码，从源码层面了解某个产品的工作原理，写出来的文章很有说服力。3 参考其他的优秀的博客文章，但在这种方式中需要取其精华去其糟粕，还要识别一些错误。最近一直在写博客 ，产生了一些思考 在这里记录一下。大家有什么好的方法或经验吗？

原创 mysqldump --set-gtid-purged参数详解

系统变量（ gtid_purged) 的全局值 @@GLOBAL.gtid_purged是一个 GTID 集合，包含已提交但不存在于binlog中的所有 GTID 组成。可以手动设置 gtid_purged 的值，以便在服务器上记录某个 GTID 集中的事务已被应用，尽管它们不存在于服务器上的任何二进制日志中。在开启了GTID模式的数据库，如果你对数据库的部分数据进行了备份，如果不加参数--set-gtid-purged=OFF，该备份中也会包含该数据库的所有GTID。

原创 MySQL GTID详解

GTID 全局事务唯一标识（ global transaction identifier）

原创 【TiDB理论知识10】TiDB6.0新特性

TiDB6.0新特性

原创 【TiDB理论知识09】TiFlash

TiFlash 主要有等几个核心特性。

原创 【TiDB理论知识04】TiKV-分布式事务与MVCC

下面一个事务 里面有两个更新,分别将id=1的Tom改为Jack,将id=2的zhangsan 改为 lisi。在MySQL中这个事务很普通，但是在分布式数据库TiDB 中的会遇到什么问题呢？比如(1,‘Tom’) 存储在一个TiKV中 ，(2,'zhangsan')存储在另一个TiKV中，

原创 【MySQL工具】my2sql-快速解析binlog

go版MySQL binlog解析工具，通过解析MySQL binlog ，可以生成原始SQL、回滚SQL、去除主键的INSERT SQL等，也可以生成DML统计信息。类似工具有binlog2sql、MyFlash、my2fback等。