面试题：MariaDB binlog事件实现原理在数据一致性与容灾中的深度应用

记录模式：
- Statement模式：记录的是SQL语句本身。例如，执行INSERT INTO users (name, age) VALUES ('John', 25)，binlog会记录这条完整的SQL语句。优点是日志量小，但在不同数据库环境执行可能因函数、变量等差异导致数据不一致。
- Row模式：记录的是数据行的变化。比如上述插入操作，会记录插入行的具体列值变化。优点是能精准记录数据改变，在不同环境执行一致性高，但日志量较大。
- Mixed模式：结合上述两种模式，默认采用Statement模式，对一些可能导致不一致的操作（如含有不确定函数的SQL）采用Row模式。
写入流程：
- 事务执行过程中，相关的修改操作先记录到redo log（用于崩溃恢复），同时在内存中生成binlog event。
- 当事务提交时，先将内存中的binlog event写入到文件系统缓存（write），然后调用fsync将缓存数据持久化到磁盘（fsync），完成binlog的写入。

主从复制：
- 配置：主库开启binlog功能，从库配置主库的连接信息，包括主库的IP、端口、复制账号等。
- 过程：
  - 主库执行事务，写入binlog。
  - 从库的I/O线程连接主库，请求主库发送binlog，主库的dump线程将binlog发送给从库I/O线程。
  - 从库I/O线程将接收到的binlog写入本地的relay log。
  - 从库的SQL线程读取relay log，重放其中的binlog事件，从而在从库上执行与主库相同的操作，保证数据一致性。
多数据节点同步：
- 基于binlog的同步机制：类似于主从复制，每个数据节点将自己的binlog发送给其他相关节点。例如，在一个三节点的分布式数据库中，节点A执行事务写入binlog后，将binlog发送给节点B和C，节点B和C接收到后重放binlog事件，使三个节点数据保持一致。
- 协调机制：可以引入一个协调器（如ZooKeeper），用于管理节点间的状态和同步顺序。协调器记录各个节点的状态，确保在同步过程中不会出现数据冲突或不一致。

检测主库故障：
- 从库通过心跳机制检测主库是否可用。如果从库在一定时间内没有收到主库的心跳响应，则判定主库故障。
选择新主库：
- 可以通过选举算法（如基于ZooKeeper的选举）选择一个从库晋升为主库。
数据同步：
- 新主库从原主库的binlog中获取未同步的部分。原主库故障时，可能存在一些已经写入binlog但还未同步到从库的事务。新主库需要确定这些未同步的binlog位置。
- 其他从库重新连接新主库，新主库将自己的binlog发送给从库，从库重放binlog事件，从而实现数据同步，确保数据不丢失、不重复。

故障检测：
- 其他节点通过心跳或监控机制发现故障节点。
数据恢复：
- 当故障节点恢复后，它需要从其他正常节点获取故障期间缺失的binlog。
- 正常节点将故障节点缺失的binlog发送给故障恢复节点。
- 故障恢复节点重放接收到的binlog事件，恢复到故障前的数据状态，保证数据不丢失、不重复。

日志位置跟踪：
- 主库和从库都需要记录binlog的位置信息（如文件名和偏移量）。主库通过这些信息告知从库从哪里开始获取binlog，从库通过这些信息记录自己同步到了哪里，确保同步的连续性和准确性。
事务一致性保证：
- binlog记录事务的完整操作，通过重放binlog事件，能保证在不同节点上事务执行的一致性。在分布式环境中，通过协调机制和binlog同步，确保所有节点对事务的执行结果相同。
故障处理机制：
- 在主从切换和节点故障恢复过程中，利用binlog的可重放性和位置跟踪，快速定位并恢复缺失的数据。同时，选举机制保证在故障发生时能快速确定新的主节点，维持系统的可用性和数据一致性。

星途面试题库