mysql架构~ Orchestrator基础

一 架构支持

   1 除了5.6的并行复制不支持以外,针对开源版的mysql都支持

   2 针对5.7的普通复制开启的并行复制 需要添加 slave_preserve_commit_order 开启有序复制,gtid方式不需要,这种在软件称为 Pseudo-GTID(伪GTID)

   3 部分支持mysql8.0的单主模式(包括显示拓扑图 角色详细等信息)

二 伪GTID概念

   1 伪GTID只在主服务器注入,过程是在binlog上写入一条GTID信息

   2 HA会每5s注入一条GTID信息到binlog中

   3 确保主从服务器采用的binlog格式都是ROW(个人建议)

三 如何发现复制关系

   1 定时任务 api方式

    定时任务

    0 0 * * * root "/usr/bin/perl -le 'sleep rand 600' && /usr/bin/orchestrator-client -c discover -i this.hostname.com"

   2 由参数DiscoverByShowSlaveHosts控制

       1 在主库通过show slave hosts发现从库,从库必须得设置report_host

       2 如果没有设置report_host则是通过 processlist表发现

         具体查询语句为 select substring_index(host, ':', 1) as slave_hostname from information_schema.processlist where command IN ('Binlog Dump', 'Binlog Dump GTID'); 

         通过这种方式发现有问题 1 如果主从端口不一致会导致有问题 2 如果其他伪装成dump的进程也会被错误识别

    3 推荐参数设置为true,然后在每个真正的从库上设置report_host,report_port默认为slave的端口,不用特意指定

四 web操控

  ①：Home下的status：查看orch的状态：包括运行时间、版本、后端数据库以及各个Raft节点的状态。

  ②：Cluster下的dashboard：查看orch下的所有被管理的MySQL实例。

  ③：Cluster下的Failure analysis：查看故障分析以及包括记录的故障类型列表。

  ④：Cluster下的Discover：用来发现被管理的MySQL实例。

  ⑤：Audit下的Failure detection：故障检测信息，包含历史信息。

  ⑥：Audit下的Recovery：故障恢复信息以及故障确认。

  ⑦：Audit下的Agent：是一个在MySQL主机上运行并与orchestrator通信的服务，能够向orch提供操作系统，文件系统和LVM信息，以及调用某些命令和脚本。

  ⑧：导航栏里的图标，对应左边导航栏的图标：

   第1行：集群别名的查看修改。

   第2行：pools。

   第3行：Compact display，紧凑展示。

   第4行：Pool indicator，池指示器。

   第5行：Colorize DC，每个数据中心用不同颜色展示。

   第6行：Anonymize，匿名集群中的主机名。

   注意：左边导航栏里的图标，表示实例的概括：实例名、别名、故障检测和恢复等信息。

   ⑧：导航栏里的图标，表示是否禁止全局恢复。禁止掉的话不会进行Failover。

   ⑨：导航栏里的图标，表示是否开启刷新页面（默认60一次）。

   ⑩：导航栏里的图标，表示MySQL实例迁移模式。

Smart mode：自动选择迁移模式，让Orch自己选择迁移模式。
Classic mode：经典迁移模式，通过binlog和position进行迁移。
GTID mode：GTID迁移模式。
Pseudo GTID mode：伪GTID迁移模式。