面试题：MariaDB多源复制在高可用架构下的深度应用与性能调优

基于MariaDB多源复制构建高可用架构

环境搭建
- 安装MariaDB服务器，并确保各个节点之间网络畅通且防火墙配置正确，允许数据库通信。
- 配置主节点（Master）：在主节点的配置文件（通常是my.cnf）中设置server-id，开启二进制日志（log-bin），如：

[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin.log

重启MariaDB服务使配置生效。 - 配置从节点（Slave）：同样在从节点的my.cnf中设置唯一的server-id，例如：

[mysqld]
server-id = 2

重启服务。 2. 设置多源复制 - 在从节点上，使用CHANGE MASTER TO语句配置多个主节点。例如，假设有两个主节点，IP分别为master1_ip和master2_ip，端口为3306，用户名repl_user，密码repl_password，日志文件名和位置从主节点获取：

CHANGE MASTER TO
    MASTER_HOST='master1_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_password',
    MASTER_LOG_FILE='master1_binlog.000001',
    MASTER_LOG_POS=154,
    FOR CHANNEL'master1';

CHANGE MASTER TO
    MASTER_HOST='master2_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_password',
    MASTER_LOG_FILE='master2_binlog.000001',
    MASTER_LOG_POS=154,
    FOR CHANNEL'master2';

- 启动从节点复制：

START SLAVE FOR CHANNEL'master1';
START SLAVE FOR CHANNEL'master2';

- 检查复制状态：

SHOW SLAVE STATUS FOR CHANNEL'master1'\G;
SHOW SLAVE STATUS FOR CHANNEL'master2'\G;

确保Slave_IO_Running和Slave_SQL_Running都为Yes，且Seconds_Behind_Master接近0。

处理节点故障转移

检测故障
- 可以使用监控工具（如Zabbix、Nagios等）定期检查各个节点的状态，通过执行简单的SQL查询（如SELECT 1）来判断数据库是否可用。
- 也可以利用MariaDB自带的SHOW STATUS命令监控关键指标，如Threads_connected、Uptime等，当指标异常时触发故障检测。
手动故障转移
- 当主节点故障时，选择一个从节点提升为新的主节点。首先在新主节点上停止复制：

STOP SLAVE;

- 重置二进制日志：

RESET MASTER;

- 然后在其他从节点上重新配置主节点信息，指向新的主节点。

3. 自动故障转移 - 借助工具如Orchestrator、MHA（Master High Availability）实现自动故障转移。 - Orchestrator通过监控节点状态，当检测到主节点故障时，自动选择一个从节点提升为新主节点，并重新配置其他从节点。 - MHA同样具备自动检测和故障转移功能，通过脚本和配置文件实现对多个节点的管理。

处理数据同步冲突

冲突检测
- MariaDB在复制过程中会记录冲突日志。可以通过查看从节点的错误日志（通常位于/var/log/mysql/error.log）来发现数据同步冲突。
- 常见的冲突如主键冲突、唯一键冲突等，错误日志中会有相关提示，如Duplicate entry 'value' for key 'primary_key'。
冲突解决
- 自动解决：在某些情况下，MariaDB可以自动解决一些简单的冲突。例如，对于非唯一索引列的更新冲突，如果更新的值相同，复制可以继续。
- 手动解决：对于主键冲突等无法自动解决的情况，需要手动处理。首先停止从节点复制：

STOP SLAVE;

根据冲突类型进行处理，如删除重复数据、修改冲突数据等，然后重新启动复制：

START SLAVE;

复制性能影响因素分析和调优策略

网络因素
- 影响：节点间网络延迟和带宽限制会影响数据传输速度，导致复制延迟。
- 调优策略：优化网络配置，确保节点间有足够的带宽，减少网络拥塞。可以使用高速网络设备，设置合理的网络队列长度等。对于跨地域的节点，可以考虑使用专线网络。
服务器资源
- 影响：CPU、内存和磁盘I/O性能会影响复制性能。如果主节点CPU繁忙，生成二进制日志的速度会减慢；从节点CPU、内存不足会导致SQL线程和IO线程处理缓慢；磁盘I/O瓶颈会影响日志写入和读取速度。
- 调优策略：
  - CPU：合理分配CPU资源，避免其他高负载任务与数据库争用。可以使用CPU亲和性设置，将数据库进程绑定到特定CPU核心。
  - 内存：为MariaDB分配足够的内存，适当调整innodb_buffer_pool_size参数，提高数据缓存命中率，减少磁盘I/O。
  - 磁盘：使用高速磁盘（如SSD），优化磁盘I/O调度算法，如使用deadline或noop调度算法，减少I/O等待时间。
复制参数
- 影响：一些复制相关的参数设置不当会影响性能，如slave_parallel_workers、sync_binlog、innodb_flush_log_at_trx_commit等。
- 调优策略：
  - slave_parallel_workers：根据从节点CPU核心数合理设置该参数，开启并行复制，提高复制速度。例如，对于4核CPU，可以设置slave_parallel_workers = 4。
  - sync_binlog：设置为0时，MySQL不主动将二进制日志刷盘，性能最高但数据安全性降低；设置为1时，每次事务提交都刷盘，数据安全性高但性能略有下降。可根据业务需求平衡性能和数据安全，如设置为100，表示每100次事务提交刷盘一次。
  - innodb_flush_log_at_trx_commit：取值0、1、2，1表示每次事务提交时将日志写入磁盘，数据安全性最高但性能略低；0表示每秒将日志写入磁盘，性能较好但可能丢失1秒内的数据；2表示每次事务提交将日志写入文件系统缓存，每秒刷盘，性能和安全性介于0和1之间。可根据业务需求调整该参数。

星途面试题库

面试题：MariaDB多源复制在高可用架构下的深度应用与性能调优

知识考点

面试题答案

基于MariaDB多源复制构建高可用架构

处理节点故障转移

处理数据同步冲突

复制性能影响因素分析和调优策略