MySQL系列~orc高可用

2024-01-04  本文已影响0人  开心的蛋黄派

一 日常管理

orchestrator-client -c discover -i master_ip:master_port  填写主库连接信息 orc集群介入新集群

orchestrator-client -c topology -i master_ip:master_port  展示新集群信息,确认是否正常

orchestrator-client -c graceful-master-takeover-auto -alias cluster_name -d new_master:ip_port 手工进行维护-切换

orchestrator-client -c ack-cluster-recoveries -alias cluster_name -r "Manually failover" 手工进行维护-ack信息确认

orchestrator-client -c forget-cluster -alias cluster_for_forget 下线整个集群

orchestrator-client -c forget -i instance.to.forget.com:3306 下线某个实例

二   元信息维护

   MYSQL集群设计一张cluster元数据表(env,cluster_name,cluster_vip_domain,datacenter,hostname,port,promotion_rule) orc 自身数据库会同步这个cluster表,Detect相关配置选项会查询orc自身数据库的同步表展示到orc信息中

三   切换流程

1 优先判断从节点binlog的位置:比较执行位点 ExecBinlogCoordinates最新的则优先选择主库.(Relay_Master_log_file,Exec_Master_log_file)

2 如果binlog位置相同情况下,按照以下逻辑比较:

  1 开启中继日志  2 小于主库版本 3 binlog格式  4 同机房 5 按照优先级规则 must,Prefer,neutral,Prefer_not,must_not  

四 切换失败场景

   1 当主库故障,所有从库都出现高于阈值的延时(ReasonableReplicationLagSeconds=300s)  2 当主库故障,所有从库存在复制状态异常

五  从库复制调整

set global slave_net_timeout=4 配置文件同步添加

stop slave && CHANGE MASTER TO MASTER_CONNECT_RETRY=1,MASTER_RETRY_COUNT=86400, master_heartbeat_period=2 && start slave

最高切换延时为8S 

六 故障检测机制

Orchestrator在集群的所有节点各启动三个线程,每隔InstancePollSeconds重建连接,监控主库和所有从库复制是否正常;

当检测到主库故障时,会通过从库的连接查询复制关系是否正常,如果主库故障且所有从库复制关系异常(不能连接到从库或IO Thread异常),判定主库故障(二次确认)

上一篇 下一篇

猜你喜欢

热点阅读