Percona-XtraDB-Cluster-运维实践PPT.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,3,#,Percona,xTRAdb cLUSERT,运维实践,Sohu,徐国强,1,2025/4/14 周一,XtraDB Cluster,特征,1,，,同步复制,复制动作是同步的，,实际上数据并不是完全同步的,，数据的同步存在一个间隙，只能称为虚同步。,2,，,多,master,每一个节点都可以作为,master,，并将改动发送到其他节点。,3,，,并行复制,复制可以指定多个线程，并且复制是以事务为单位的，多个事务同时并行推送到所有集群节点。,4,，,新节点自动部署,只需要修改合适的参数，启动新节点的,mysqld,进程并成功加入集群后，数据完全自动的部署到新节点。,5,，数据一致性,严格的数据一致,6,，高可用性,单点故障不影响可用性,7,，与传统,mysql,几乎完全兼容,数据可以直接使用不需要任何转换，程序上也仅仅事务处理机制有变化，并且还可以完全规避,2,2025/4/14 周一,XtraDB Cluster,缺陷,1,，默认工作在,InnoDB,引擎表上，因此对其他引擎的表支持的很差，甚至根本不支持，所以不要考虑在,PXC,上使用,MyISAM,或者其他的存储引擎,2,，所有的表都必须要有主键,3,，不支持的操作：,LOCK/UNLOCK TABLES,、,lock functions(GET_LOCK(),RELEASE_LOCK().),4,，,query log,日志不能存放在表里面，必须存放在文件,6,，由于集群是基于乐观的并发控制（,optimistic concurrency control,），事务冲突的情况可能会在,commit,阶段发生,7,，不支持,XA,事务，因为,XA,事务有可能在,commit,的时候出现异常发生,rollback,8,，整个集群的吞吐量,/,性能取决于最慢的那个节点（成本）,9,，最小建议的集群节点数为,3,，否则很容易产生脑裂（成本）,10,，加入新节点，开销大，有多少个节点就有多少重复的数据,11,，不能有效的解决写缩放问题所有的写操作都将发生在所有节点上,3,2025/4/14 周一,XtraDB Cluster,性能,-,-,测试环境,1,，,PXC,和,Master-Slave,均为,3,个节点,2,，,SAS,、,SSD,磁盘,3,，,Percona XtraDB Cluster 5.5.28,4,，,Percona Sever 5.5,5,，,Oracle Linux 6.3,2.6.39-200.24.1.el6uek.x86_64,6,，,DELL R710,CPU Xeon 5620,*,2,Memory 64GB,7,，,Sysbench,8,，,haproxy,和,LVS,4,2025/4/14 周一,XtraDB Cluster,性能,LVS,只读测试,可以看到随着并发线程数的增加，三节点的只读操作：,1,，在使用,SSD,磁盘的情况下，,PXC,与,MS,结构的查询性能基本一致，偶有误差也基本保持在一个数量级,上；,SAS,盘时，,PXC,性能会弱小一些,2,，从响应时间上来看，也差不多是这个情况,3,，但是在实际的应用中，如果达到了,100,个实时活动的连接，那么系统就已经非常繁忙了，,MasterSlave,结构，如果有写入操作，那么一致性就很难保证,5,2025/4/14 周一,XtraDB Cluster,性能,LVS,单节点写测试,PXC,的写入性能是公开的表示了会比较差，这个差的比例约会低下,1/4,，但是如果使用了,SSD,磁盘，,则会有较大的改观，但是依然会保持比较差的总体状况，具体原因后续会有分析：,1,，,PXC,整体上落后,MS,结构,2,，响应时间也是同样落后一些,3,，,SSD,磁盘会带来相当大的提升,6,2025/4/14 周一,XtraDB Cluster,性能,业务模拟测试,1,，同时启,2,个,sysbench,，一个只读，另一个只写,2,，写请求只发送到某一个固定节点，读请求负载均衡到集群环境的所有节点,3,，,2,个,sysbench,的读写请求数比例设置约为,9,：,1,，保证测试时间约等于或大于,1,小时,4,，数据量为,1.5,亿,6,，依次对,pxc/ms,lvs/haproxy,各种环境进行测试，共,4,项：,pxc-ssd-lvs,pxc-ssd-haproxy,ms-ssd-lvs,ms-ssd-haproxy,7,，,ms,测试导致主备不同步，暂时忽略其对测试的影响。需等待,ms,同步后再进行下一项测试,8,，分别对集群环境中存在单节点、,2,节点、,3,节点测试,3,组,9,，每组测试,5,轮。每秒请求数计算：,SUM(,读请求数,+,写请求数,)/SUM(,读执行时间,+,写执行时间,),GROUP BY,测试项,7,2025/4/14 周一,XtraDB Cluster,性能,业务模拟测试,如果排除延迟问题，,MS,确实比,PXC,的性能更好（但是实际情况下，,MS,的延迟已,经非常严重，测试了一小时，基本上延迟越来越大）,8,2025/4/14 周一,基于,Galera,实现,Percona,的这个,Cluster,实际上就是基于,Galera,实现，添加了一些,mysql,的参数，并调用,Galera,的接口，这是整体的工作流程：,1,，客户端提交,MySQL,数据库访问请求,2,，通过,wsrepAPI,调用,Galera,将数据变化复制到集群中其他节点,9,2025/4/14 周一,数据复制流程（一）,描述两个节点间的数据复制。,要点：,1,，只有当发生,Commit,操作时，才,发送数据验证请求到其他节点。,2,，传输,/,返回验证数据时间和其他,节点的数据验证时间，将影响到当,前数据操作节点真正,commit,的时,刻。,3,，其他节点只要验证成功了，就,会返回成功的信号，即使当前数据,并没有真正的写入当前节点，这段,时间内，将造成数据的不一致。,10,2025/4/14 周一,数据复制流程（二）,11,2025/4/14 周一,数据复制流程（三）,根据前面描述的数据复制流程，可以得到这样的结论：,当多个事务同时操作相同的数据资源时，这个资源在集群中是不受任何一个,Session,影响的，直到有一个,Session,对这个数据资源进行了成功的,Commit,操作，这时，其他的,Session,的所有操作实际上已经不可能成功了，当其他的事务尝试做,Commit,，会直接返回一个因为,deadlock,事务失败回滚的信息。,这与,mysql,默认的机制不同，在,mysql innodb,默认的情况下，当我们在其他事务中对某个,id,的数据进行,update,；此时我们发起一个事务对这个数据进行需要获得排它锁的操作，操作将会进行等待，直到超时失败或者现在持有排它锁的事务提交，当前事务将继续。,(,注意：这里的每个,Session,来源于不同节点，单节点的死锁机制遵循,mysql innodb,默认的工作模式,),那么上图的,session,中，那些会成功呢？,只有,SessionB,12,2025/4/14 周一,节点状态变化,节点变化过程中用到的,部分,术语：,SST,（,State Snapshot Transfer,）,用于节点间传送数据，发生在节点初始化，或者节点故障需要全部重置数据的时候，相当于整个,copy,一份数据到新节点，这个过程影响非常大，会造成,Donor,节点的无法访问,IST,（,Increment Snapshot Transfer,）,用于节点间传送数据，发生在节点初始化，或者节点故障，但是能够从,galera.dat,中获得增量同步点的情况，仅仅做必要的增量同步，是最理想的数据恢复方法。,Donor,当发生,SST,时，集群中被选中作为数据源的节点，可以手动指定也可以自动选择，被选中为,Donor,的节点可以进行,Select,，但是新的数据变化情况无法被应用，会被缓存在当前节点的,cache,文件中。当,SST,过程结束，,Donor,节点将变为,JOINED,状态，并应用这些缓存的内容，从而返回,SYNCED,状态。,13,2025/4/14 周一,新节点加入流程,14,2025/4/14 周一,名词解释,Global Transcation ID,（,GTID,）,当通过客户端对数据库进行有顺序的一系列修改时（不一定仅仅是数据库），集群中所有的节点都对这个修改动作进行同步。在,wsrep API,中，通过,GTID,对这个修改进行标识，从而在所有节点达到一致。,GTID,由俩部分组成，一个标识对象的,UUID,，和一个标识这次修改状态的,sequence,（对应每一个动作），例如：,45eec521-2f34-11e0-0800-2a36050b826b:94530586304,State Snapshot Transfer,（,SST,）,节点初始化,/,重做方法，使用指定的,sst,策略，来做数据的全量同步。,Incremental State Transfer(IST),Galera 2.x,开始支持。当一个节点加入，他当前的,GUID,与现集群相同，且缺失的数据能够在,donor,的,Writeset,的,cache,中找到，则可以进行,IST,，否则只能全部初始化数据，进行,SST(State Snapshot Transfer),。,15,2025/4/14 周一,SST,方式的选择,MySQL Dump,需要锁定,Donor,节点，无法提供访问,速度慢,Rsync,需要锁定,Donor,节点，无法提供访问,速度快,Xtrabackup,只需要短时间锁定,Donor,，基本不影响访问,速度较快,16,2025/4/14 周一,Rolling Schema Upgrade,Schema Upgrade,指的是任何修改数据库结构的,DDL,语句，这种语句不具有事务性。,Total Order Isolation(TOI),默认的工作方式，在这种模式下，,DDL,语句的表现将和在一个单机数据库上一样，将会锁定整个集群库。并且这个语句将会同时发 送到所有的集群节点去执行。,Rolling Schema Upgrade(RSU)wsrep,是通过设置,wsrep_OSU_method,参数，,DDL,语句将会在当前节点执行，并且在执行过程中不锁 定其他节点，当这个节点的,DDL,操作完成，将会应用操作过程中延迟的,replication,，然后你在手工的一个一个节点的去做,DDL,操作。这个滚动 升级的过程中，集群中会有部分服务器有新的表结构，部分有旧的表结构。,17,2025/4/14 周一,节点故障,任何的硬件故障、软件崩溃、网络连接异常，都将造成节点故障。判断故障节点的依据，是根据他是否还能够连接,PC（Primary component），,而,PC,是从当前集群中随机选择的，因此不能简单的根据服务 器是否能够,ping,通等外部的方式来判断，需要根据各个节点的,wsrep_local_state,来进行投票。,故障侦测 节点每隔,evs.inactive_check_period,接收一次数据包。假如在,evs.keepalive_period,间隔都没有任何信息发出，则发出一个,heartbeat,信 号。假如某一个节点在,evs.suspect_timeout,都没有任何信息发出，则这个节点被标识为,suspected，,当所有的,cluster,成员节点都认为这个节点 是,suspected，,则认为这个节点,failed。,同理，假如某个节点认为另一个节点有问题，则也必须所有的节点都保持一致的想法，才能够定性。,综上，这些节点状态参数的设置应该遵循：,evs.keepalive_period=evs.inactive_check_period=evs.suspect_timeout=evs.inactive_timeout=evs.consensus_timeout,18,2025/4/14 周一,Galera Arbiter,0.8.2,的,Galera,开始支持一个,Arbitrator,节点，来预防脑裂,(split-brain),；在如下图的情况下，如果有其中一个,node,无法正常连接,WAN,，那么 另外一个,node,仍然可以通过和,Arbitrator,的联系来确认状态正常，并且继续提供服务。,需要注意的是，,Arbitrator,需要能够看到所有的网络流量，尽管它不用这些数据做任何事，因此，它会给网络带来额外的压力。,19,2025/4/14 周一,部分参数调整,当网络状况不好时考虑调整的参数设置：,wsrep_provider_options=evs.keepalive_periodPT3S;evs.inactive_check_period=PT10S;evs.suspect_timeout=PT30S;evs.inactive_timeout=PT1M;evs.consensus_timeout=PT1M,evs.keepalive_period,参数控制多久发送一次,keepalive,请求信号,evs.inactive_check_period,参数控制多久检测一次节点活动,/,静止状态,evs.suspect_timeout,参数控制某个节点是否被标识为,suspected,状态的时间间隔,evs.inactive_timeout,参数控制节点不活动时检测周期evs.consensus_timeout,参数控制多久检测一次节点一致性 通过上面的设置，可以使节点超时时间为,30,秒,evs.inactive_timeout,参数必须不小于,evs.suspect_timeout，evs.consensus_timeout,必须不小于,evs.inactive_timeout。,wsrep_slave_threads,建议每个,core,启动,4,个复制线程，这个参数很大程度上受到,I/O,能力的影响，官方甚至在,ThinkPad R51,一个,4200,转硬盘、单核心的机器上设置,32,个线程，并且执行良好。可以通过观察,wsrep_cert_deps_distance,这个状态变量来获得当前最佳的线程数，这个参数实际上表示单位时间平均多少个,writesets,能被执行掉。,20,2025/4/14 周一,监控要点,wsrep_flow_control_paused,这个变量标识当前节点落后于集群的程度，,0.0-1.0,0.0,为没有落后，,1.0,为,flow control,已经停止了。应该尽量保证这个变量值为,0.0,。如果落后实在太厉害，则应该适当增加复制线程数,wsrep_slave_threads,，如果还没有改善，则应该从集群中删除最慢的节点。,wsrep_cert_deps_distance,这个变量标识当前节点平均时间内并行执行的事务数，这个数据可以用来作为,wsrep_slave_threads,的参考，同时当并发量很高的时候，这个数值也会很大。,wsrep_flow_control_sent,表示,flow_control,发出,FC_PAUSE,事件的次数，暂停的次数越多，表示接受到的请求频繁堵满,slave,队列，这种情况下不是队列长度不足，就是机器性能太差。（如果集群中多个机器都有 这个情况，则考虑调整,slave,队列长度的相关参数，如,gcs.fc_limit,等）,wsrep_local_recv_queue_avg,这个参数表示本地节点平均的接收队列长度，如果这个参数不为,0.0,，则表示接收来的数据不能被及时应用（立即应用了则不会进入队列）。,wsrep_local_send_q_avg,这个参数表示本地节点发送数据的队列长度，如果这个参数不为,0.0,，则表示向外发送数据的速度比较慢，有堆积。,21,2025/4/14 周一,高负载下的宕机风险,利用,sysbench,通过,Haproxy,对三节点的,Cluster,进行并发读写，并发线程数,300,。,此时，整体每个节点的,IO,负载都比较低，没有造成瓶颈，但是,CPU,资源消耗很大,22,2025/4/14 周一,高负载下的宕机风险,此时三个节点的日志中均频繁出现如下内容。,此时发生过一次三个节点均无法通信，导致脑裂，三个节点 均变为只读状态的故障。,同时观察,wsrep_*,的相关状态参数，发现了,wsrep_cert_deps_distance,的值，与集群的稳定性息息相关。在当时的测试情况下，当该值超过,1300,，则集群崩溃的可能性非常大。,这种宕机一般不会引起数据丢失和不一致，但是将会终止数据库的可用性。,23,2025/4/14 周一,高负载引起宕机风险的防治,参考建议的监控数据，严格控制,对应用的入口,SQL,详细审核，避免不正常的,SQL,运行,使用一些策略，例如,Iptables,限制单位时间的并发量、包个数，来避免宕机,24,2025/4/14 周一,节点故障与恢复,任何的硬件故障、软件崩溃、网络连接异常，都将造成节点故障。判断故障节点的依据，是根据他是否还能够连接,PC,（,Primary component,），而,PC,是从当前集群中随机选择的，因此不能简单的根据服务 器是否能够,ping,通等外部的方式来判断，需要根据各个节点的,wsrep_local_state,。,前面说过，故障侦测 节点每隔,evs.inactive_check_period,接收一次数据包。假如在,evs.keepalive_period,间隔都没有任何信息发出，则发出一个,heartbeat,信 号。假如某一个节点在,evs.suspect_timeout,都没有任何信息发出，则这个节点被标识为,suspected,，当所有的,cluster,成员节点都认为这个节点 是,suspected,，则认为这个节点,failed,。同理，假如某个节点认为另一个节点有问题，则也必须所有的节点都保持一致的想法，才能够定性。,综上，这些节点状态参数的设置应该遵循：,evs.keepalive_period=evs.inactive_check_period=evs.suspect_timeout=evs.inactive_timeout=evs.consensus_timeout,25,2025/4/14 周一,节点故障与恢复,一旦节点发生故障，分不同的情况，如果无法进行,IST,，则需要做,SST,，即需要进行完全的,state snapshot transfer,，代价非常巨大。,Donor,选择：有自动选择和手动指定,Donor,两种方式，通过,wsrep_sst_donor=DONOR_NAME,来指定，不指定则在当前集群中随机选择。,需要注意的是，当某个,node,被选为,Donor,时，如果使用,Rsync,或者,Dump,，这个节点是不能提供客户端服务的，即使使用,Xtrabackup,这个节点的性能和稳定性也会受到很大影响，基于这种情况，建议手动选择一个,Donor,，避免高负载的机器被用来做,Donor,。,26,2025/4/14 周一,节点故障与恢复,节点故障后获取,GTID,的方法,执行,mysqld,加,-wsrep-recover,参数，可获得,GTID,，,如,mysqld-defaults-file=/DATA/my6000/f-log_error=/dev/stdout-wsrep-recover,再调用,-wsrep_start_position=,设置,GTID,，,启动,mysqld,默认情况下，目前的版本似乎会自动这样做，看源码是从,innodb,redolog,记录的,checkpoint,里获得的,GTID,27,2025/4/14 周一,谢 谢,完,28,2025/4/14 周一,