2.8 集群同步协调&状态管理

2.8.1 概述

大多数时候,dble结点是无状态的,所以可以用常用的高可用/负载均衡软件来接入各个结点。
这里不讨论各个负载均衡软件的使用。
主要讨论一下某些情况下需要同步状态的操作和细节。
注:本部分内容需要额外部署zookeeper用于管理集群的状态和同步。

2.8.2 相关配置

2.8.2.1 cluster.conf

以ZK为例

# 开启集群模式
clusterEnable=true   
# 集群模式元数据中心为zk
clusterMode=zk   
# zk地址
clusterIP=10.186.19.aa:2281,10.186.60.bb:2281
#zk为dble提供的根目录
rootPath=/dble  
#本组dble的组名
clusterId=cluster-1 
# 是否需要同步Ha状态 
#needSyncHa=false  
# 拉取一致性binlog线的超时时间
#showBinlogStatusTimeout=60000  
#自增序列类型
sequenceHandlerType=2  
#自增序列默认开始时间
#sequenceStartTime=2010-11-04 09:42:54 
#自增序列类型为3时,instanceId是否由ZK生成
#sequenceInstanceByZk=true

2.8.2.2 bootstrap.conf

instanceName 实例名称,用于发起集群任务或者汇报自己完成集群任务的标记 instanceId (自增序列使用,根据类型范围为0到1023 或者0到511)

2.8.3 初始化状态

方式1.

通过执行脚本init_zk_data.sh方式将某个结点的配置文件等数据写入ZK,所有结点启动时都从ZK拉取配置数据。

方式2.

在第一个结点第一次启动时自动将自己的配置文件写入ZK,其他结点启动时从ZK拉取。
第一个结点的判定:用分布式锁抢占的方式,未抢占到结点会阻塞等待直到获取到分布式锁,如果此时初始化标记已经被设置,则从ZK拉取配置,否则将自己本地配置写入。
初始化流程

2.8.4 状态同步

A.DDL

做DDL时候会在执行的某个节点成功后,将消息推给ZK,ZK负责通知其他结点做变更。流程如下图:

DDL流程 类似于二阶段按提交的方式

注:

  1. 新结点启动时,加载元数据前会检测是否有其他结点在做DDL变更,如果有,则等待。
    否则加分布式锁防止加载元数据期间其他结点做DDL变更, 直到元数据加载完释放分布式锁 。
  1. "等待其他节点执行完成子任务" 指的是:每个节点完成任务后,都会创建子节点用来告知分布式协调器自己已经完成,执行主任务的节点负责检查所有结点是否都创建了子节点(即检查是否都完成了任务),如果完成则删除父结点(回收资源)。此操作为原子操作。
  1. 发起结点故障:如果执行DDL的结点故障下线,其他结点会侦听到此消息,保证解开对应结点的tablemeta锁,并记录故障告警(如果配置了告警通道),需要运维人工介入修改ZK对应ddl结点的状态,检查各个结点meta数据状态,可能需要reload metadata。
  1. 逻辑上不应该有某个监听节点上加载meta失败的情况,如果发生了,告警处理

    (人工介入对应结点的meta是不正确的,需要reload meta)

  1. 注:view目前是异步模式,可能存在某个间隙view修改成功,查询仍旧拿到旧版的view结构。

B.reload @@config/ reload @@config_all

执行流程如下图:

reload流程

注:如果在部分结点失败,则会返回错误及错误原因以及结点名。 设计影响面:db.xml,sharding.xml, userxml ,sequence_conf.properties 和sequence_db_conf.properties

C.拉取一致性的binlog线

目的:

获得后端数据库实例的一致性binlog位置。由于两阶段提交的第二阶段执行在各结点无法保证时序性和同步性,所以直接下发show master status获取binlog可能会造成不一致。

实现方式:

如下图,当前端收到show @@binlog.status 语句时,遍历当前所有活动session查看状态 。
若session处于绿色区域,则在进入红色区域前等待知道show @@binlog.status结果返回
若存在session处于红色区域,则需要等待所有红色区域的session返回结果走出红色区域后下发show master status。

binlog流程

超时处理:

此处有可能有死锁发生。
场景:session1 正在更新tableA,处于绿色区域,session2下发有关于tableA 的DDL,等待 metaLock解锁,处于红色区域.session3 下发show @@binlog.status.
此时session1 等待session3, session2等待session1,session3等待session2.
因此引入超时机制。如果session3 等待超过showBinlogStatusTimeout(默认60s,可配置),自动放弃等待,环状锁解除。

集群协调:

1.收到请求后同步通知ZK,先等待本身结点准备工作结束,之后zk通知其他结点处理。
2.所有结点遍历各自的活动的session,进入红色区域的等待处理完成,绿色区域的暂停进入红色区域。
3.结点将准备好/超时将状态上报给ZK
4.主节点等待所有结点状态上报完成之后,判断是否可以执行任务,若是,则执行show @@binlog.status并返回结果,否则报告本次执行失败。
5.主节点通过ZK通知各结点继续之前的任务

集群超时处理:

若有结点超时未准备好,主节点会报超时错误,并通过ZK通知各结点继续之前的任务。

故障处理:

主节点执行过程中故障下线,其他结点会感知,保证自己结点一定时间后自动解锁继续原有任务。
ZK状态需要人工干预。人工等待所有结点超时之后,手动删除/修改zk上的状态信息以便下次执行时不出问题。

D.View管理

在使用集群模式是,使用zk进行view视图信息的管理,使得整个dble集群能够进行视图信息的同步 由于视图只用于数据查询且不会造成数据异常的属性,在视图同步时采用异步同步的方法

binlog流程

注 在zk上的view数据信息如下形式 key schema.table value {"serverId":"create_Server_id", "createSql":"view_create_sql"}

E.online状态

dble启动时候会在online的目录下注册自己的信息,如果此时正在做DDL,会阻塞一段时间,防止表结构元数据不一致。
功能:
1.作为集群协调时候检查哪些dble完成了对应任务的标准 2.dble故障后同集群的其他实例会发现状态并处理完收尾的状态,主要是DDL状态残留,拉取一致性binlog线或者暂停流量的残余。

F.高可用命令同步

当启用needSyncHa时候,此选项才生效

F.1 disable工作流程:

1.申请分布式锁
2.本地执行disable
3.将信息写入集群
4.等待所有结点完成disable
5.完成并清理
6.释放分布式锁

F.2 enable工作流程:

1.申请分布式锁
2.本地执行enable
3.将信息写入集群
4.释放分布式锁
5.其他订阅结点异步完成enable

F.3 switch工作流程:

1.申请分布式锁
2.本地执行switch
3.将信息写入集群
4.释放分布式锁
5.其他订阅结点异步完成switch

G.暂停流量(一般用于扩容迁移等)

G.1 pause流程
  1. 申请分布式锁 pause_node.lock
  2. 通知其他结点
  3. 本结点停流量
  4. 等待其他结点完成停流量 或者超时
  5. 返回暂停成功或者失败
  6. 释放分布式锁
G.2 resume流程
  1. 申请分布式锁 pause_node.lock
  2. 本结点恢复流量
  3. 通知其他结点
  4. 等待其他结点完成恢复流量 或者超时
  5. 返回暂停成功或者失败
  6. 释放分布式锁

2.8.5 XA日志管理

在使用集群模式时,未完成的XA日志会存放在zookeeper上,更加安全,防止某台机器硬盘物理损坏导致日志丢失(此处可能会有并发高吞吐引发的性能及其他问题,待测试)。

2.8.6 ZK整体目录结构

rootPath(配置在cluster.cnf中的)
    clusterId(配置在cluster.cnf中的)
        conf
            inited
            status
                operator
                    instanceName(临时的,key为bootstrap.cnf配置内容。功能:reload响应id)
            sharding(sharding.xml的json信息)
            db(db.xml的json信息)
            user(user.xml的json信息)
            migration(用于暂停流量)
                pause
                    instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)
                resume
                    instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)
            sequences
                instanceid //zk 分布式方式
                incr_sequence//批量步长方式
                    table_name
                common(sequence_conf.properties 或者sequence_db_conf.properties)
        binlog_pause
            status (发生时建立,结束后回收)
                instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)
        lock
            syncMeta.lock(临时的,启动时防止元数据变更)
            confInit.lock  
            confChange.lock
            binlogStatus.lock
            ddl_lock/schema.table
            view_lock/`schema`.`table`
            dbGroup_locks/groupName
            pause_node.lock
        online
            instanceName(临时的,key为bootstrap.cnf配置内容。)
                ddl
                    schema.table.PREPARE(ddl操作的第一阶段,用于加锁)
                        instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)
                    schema.table2.COMPLETE(ddl操作的第二阶段,此时 ddl 已执行完成,开始同步元数据)
                        instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)
                    schema.table3.PREPARE
        xalog 
            node1
            node2
        view
            schema:view         
            operator (订阅目录)
                schema.view:(update/delete,注意:create当作update处理)
                    instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)             

        dbGroups     
            dbGroup_status
                groupName
            dbGroup_response
                instanceName(临时的,key为bootstrap.cnf配置内容。功能:响应结点)

2.8.7 全局序列

类twitter snowflake 方式,ZK完成的工作是生成每个节点的instanceID。
类offset-step 方式,ZK完成的工作是存储当前的Step值。

2.8.8 附录

legend

results matching ""

    No results matching ""