mysql-高可用架构类设计中会遇到的问题???

作者: Joah_l | 来源:发表于2019-09-29 11:55 被阅读0次

高可用架构类设计

问题一: 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