高可用架构类设计

问题一: mysql 的主从复制是如何工作的???

• mysql 主从复制的实现原理

  • 异步复制

  • 半同步复制

• MMM 架构只支持基于日志点的复制, 如何进行主从复制, 配置步骤:

  • master

    1. 在 master 上操作, 开启 binlog(必须), 开始 gtid(可选; v>5.6, 开启需要重启 mysql, 建议一开始的就开启);

       • select @@version;

       • show variables like 'log_bin%';

       • show variables like 'gtid_mode': 需要修改配置文件, v8.0 在使用 pt 插件的话, 需要修改认证插件;

         • 修改配置文件: gtid_mode = on 等等

    2. 建立同步所用的数据库账号

       • 创建用户 create user repl@'ip' identifyed by 'xxxx';
       • 授予用户权限 grant replication slave on *.* to repl@'ip';

    3. 使用 master_data 参数备份数据库

       • 备份数据库: mysqldump --single-transaction -uroot -p --routines --triggers --events --master-data=2 --all-databases > master.sql

    4. 将备份文件传输到 Slave 服务器

    • 将 master.sql 拷贝到 Slave 上;

  • Slave

    1. 开启binlog(可选), 开始 gtid(可选);

    2. 恢复 Master 上的备份数据(只支持 Slave 高于 Master版本)

       • mysql -uroot -p < master.sql;

    3. 使用 Change Master 配置链路

       • change master to master_host='ip', master_log_file='mysql-bin.000012(在master.sql 中查看)' master_log_pos=xxx;

       • 查看配置复制链路 show slave status\G;

    4. 使用 start slave 启动复制

       • 启动复制链路 start slave user='repl' password='xxxx'

• MHA 架构只支持基于GTID的复制, 如何进行主从复制, 配置步骤:

  1. 启动半同步复制

     • 查看安转插件: show plugins; install plugin rlp_semi_sync_master;

     • show variables like 'rpl%';

       • rpl_semi_sync_mnaster_timeout: 设置 Master 等待 Slave发送 ACK 的超时时间, 不建议设置的过大, 否则会阻塞 Master 的写操作;

       • rpl_semi_sync_master_enabled: 开始半同步复制;

     • 在 slave 安装 rpl_semi_sync_slave 插件; 同时配置这个插件

       • show variables like 'rpl%'; 只有 4 个参数的设置

       • start slave io_thread user='repl' password='xxxxx': 开启 io 线程; 启动复制链路

       • 分别在主从上检查半同步复制的相关的插件是否启动状态: show global status like 'rpl%';

       • 这个时候在 Master 上执行写; stop slave io_thread; (停止复制);

问题二: 比较一下基于 GTID 方式的复制和基于日志点的复制???

• 什么是基于日志点复制 ???

  • 传统的主从复制方式

  • Slave 请求 Master 的增量日志依赖日志偏移量

  • 配置链路时需要指定 master_log_file 和 master_log_pos 参数

  • 支持 MMM 和 MHA 架构

  • 主备切换后很难找到新的同步点

  • 方便跳过复制错误

• 什么是 GTID 的复制 ???

  • GTID = source_id:transaction_id

  • Slave 增量同步 Master 的数据依赖于其同步的事务 ID

  • 配置复制链路, Slave 可以根据已经同步的事务 ID 继续自动同步

  • 仅支持 MHA 架构

  • 基于事务 ID 复制, 可以方便找到未完成同步的事务 ID

  • 只能通过置入空事务的方式来跳过错误

  • 不兼容老版本的 Mysql 和 MariaDB

  • 更能保证主从复制的一致性

问题三: 比较一下 MMM 和 MHA 两种高可用架构的优缺点???

• MMM 和 MHA 架构共同点

  • 对主从复制集群中的 Master 的健康监控

  • 当 Master 宕机之后把写 VIP(虚拟IP) 迁移到新的 Master

  • 重新配置集群中的其他 Slave 对新的 Master 同步

• MMM(Master--Master-Mysql)适用的主从架构:

  • 两个 Master, 工作中只有一个 Master, 另一个是主备,

  • image
  • image

• MHA适用的主从架构: 配置过程中注意要关闭防火墙和sestatus;

  • 用 ssh-cope-id -i /root/.ssh/id_rsa user@ip, 进行 ssl 登录;

  • image

问题四: 如何减小主从复制的延迟???

• image

• 延时问题一(大事务):
  image

• 延时问题二(网络延时)
  image

• 延时问题三(多线程写, 单线程恢复)
  image

问题五: 说说你对 MGR 集群的认识???

• 概念:
  image

• 原理:
  image

• 架构:
  image

• 单主模式:
  image

• 多主模式:
  image

• 配置步骤:
  image

• 缺点:
  image

• 应用场景:
  image

问题六: 如何解决数据库读/写负载大的问题???

• 写的负载:
  image

• 读的负载:
  image