PERCONA XTRADB CLUSTER介绍及使用(一)http://www./software/percona-xtradb-cluster #software FAQ: 2.为什么使用5.6版本?
3.xtradb cluster和Oracle MySQL有什么不同? 1. 节点之间的复制(replication)仅支持InnoDB引擎, 其它类型的write不会复制(包括mysql.*表),DDL语句以statement级别复制,即意味着create user ... 和 grant ...可以复制，但是insert into mysql.user .... 不会被复制。 2. 没有主键的表在各节点可能以不同的顺序显示出来,比如select ... limit..., DELETE操作在没有主键的表中不被支持。不要使用没有主键的表(也可能基于row格式的复制) 3. 不要开启 query cache(默认关闭); 4. 由于commit的时候可能会回滚(rollback), 不支持XA事务; 5. 事务大小, Galera Cluster没有限制事务大小, 为了避免大事务(比如LOAD DATA)对节点的影响, wsrep_max_ws_rows和wsrep_max_ws_size限制了事务行数为128K,事务大小1GB。 6. 基于集群级别的并发控制, 一个事务的提交可能会被取消掉。 7. 不支持Windows系统. 8. 不要使用binlog-do-db和binlog-ignore-db, 这些选项仅支持DML语句, 不支持DDL语句, 使用这些选项可能会引起数据的错乱。 9. 如果选择rsync方式传输, 就不要指定character_set_server为utf16, utf32或ucs2字符集, Server可能会崩溃. 一. percona XtraDB Cluster 术语说明 LSN: 每个InnoDB page(通常16kb大小)含有一个日志序列(log sequence number),称作LSN。LSN是整个database的系统版本号。每个page的LSN表示了最近该页的变动(change)。 GTID: Global transaction id. 在XtraDB中GTID由UUID和一个用来标识顺序更改的序列数字组成. UUID: 全局唯一标识，唯一标识了状态和节点的序列改变. HAProxy: 一个基于TCP和HTTP协议的应用，用来提供快速，稳定的高可用服务,包括负载均衡，代理协议等。 Primary Component: 如果一个单节点失效， cluster可能会因为网络的原因分裂成多个部分。在这种状况下，仅有一个部分可以持续修改数据库的状态以避免引起分歧，该部分则成为Primary Component(PC)， SST: State Snapshot Transfer. 状态(数据)快照传输，全量的从一个node传输到另一个node. 当一个新node加入Cluster的时候, 必须从已有的node传输数据到新node. SST传输方式有三种: mysqldump, rsync, xtrabackup.前两种传输时会锁表, xtrabackup仅在传输系统表的时候锁表. IST: Incremental State Transfer. 用来替代SST传输数据的方式, 只有在写集(writeset)还存在于donor的writeset cache中时,IST才可以抓取批量收到的writeset. donor node: 被选举为提供状态传输(SST或IST)的节点。 Xtrabackup: 支持MySQL热备的开源工具, 备份InnoDB期间不会加锁, 该工具由percona公司开发。 cluster replication: 为cluster members提供的正常replication, 能以单播或多播的方式进行加密。 joiner node: 要加入到cluster中的node, 通常也是状态传输的目标。 node:一个集群的节点就是一个处于集群中的MySQL实例。 quorum: 多数节点( > 50%), 在一个网络区域中, 只有cluster保持有quorum, 并且quorum中的node默认处于Primary状态。 primary cluster: 一个持有quorum的cluster. 一个non-primary集群不会允许任何操作，并且任何试图read或write的client端都会返回’Unknown command error’错误。 split brain: 当集群中的两部分(part)不能连接，一部分(one part)确信另一个部分(the other part)不在运行的时候则发生分裂(splite brain), 这种情况会造成数据不一致。 .opt: MySQL在每个database中都有一个.opt后缀的文件保存该database的选项信息(比如charset, collation). 二. percona XtraDB Cluster生成文件说明 GRA_x.log：在row格式下执行失败的事务(比如drop一个不存在的表等),这些文件保存了这些事务的binlog events。该功能禁止了slave thread应用这些执行失败的事务。warning或error信息会在mysql error log中显示。比如在一个node中drop不存在的表, 其他node会生成GRA_x.log文件,error log中也会显示一下信息: Jun 5 11:34:42 cz-test2 mysqld-3321: 2014-06-05 11:34:42 26423 [ERROR] Slave SQL: Error 'Unknown table 'percona.list'' on query. Default database: 'percona'. Query: 'drop table list', Error_code: 1051 galera.cache: 该文件存储主要的写集(writeset), 被实现为一个永久的环路缓冲区(ring-buffer),在node初始化的时候,它被用来在磁盘上预分配空间,默认128M, 这个值过大的话，更多的写集会被缓冲, 而且重新加入的的节点(rejoining node)更倾向于采用IST来取代SST传输数据。 grastate.dat：保存了Galera的状态信息。 三. Percona XtraDB Cluster 如何保证写一致性(consistency of writes) 所有的query在本地node执行， 并且仅在commit存在特殊的处理。当commit有问题时， 事务必须在所有node验证, 没有验证通过则返回error信息. 随后，事务被应用到本地node。 commit响应时间包括: 网络轮询时间； 验证时间； 本地应用；(远程apply事务不影响commit响应时间)。 两个重要的特性: 1. 控制wsrep_slave_threads参数来实现多并发replication.
2. 一些其它因素，比如master的性能更好,执行事件要比slave快，这就造成了短暂的同步不一致(out-of-sync),这时候读取slave结果就为空, wsrep_causal_reads参数用来控制读取slave的行为，它使得操作一直等待直到事件被执行；
四. 监控 wsrep_cluster_conf_id: 次变量用来表示node是否在它相应的cluster中。cluster中所有node的该变量值应该一样， 不一样则表示nodes被分隔开了, node恢复的时候该变量也会恢复。 wsrep_cluster_size: 表示cluster中有多少node节点， 等于预期的数量则表示所有node连接到了cluster。 wsrep_cluster_status: 正常情况下值为Primary, 如果不为Primay,则该node当前不能操作(归咎于多成员关系的改变和quorum的缺失), 同时也可能满足split-brain的条件。 如果cluster中没有node 连接上(connected) PC(就是所有node属于同一部分,但是node都是non-primary状态), 可以参考http:///documentation-webpages/quorumreset.html#id1来操作Reset quorum。 1. 关闭所有node节点；
2. 从最近更新(most advanced node)的node节点开始重启所有的nodes(检查 wsrep_last_committed状态变量找到最近更新的node节点)。
2. 节点状态检查 wsrep_connected: 值为OFF,表示该node没有连接到任何cluster 部分。 3. 复制健康检查 wsrep_cert_deps_distance: 该变量表示平均有多少事务可以并发的执行。wsrep_slave_threads的值不应该超过该变量的值。 4. 检测网络延迟问题 五. cluster故障恢复 一旦一个node或多个node断开连接, 剩下的node则会进行quorum的选举操作; 在断开之前，如果总nodes里的多数node保持连接,则保留分区。对于网络分区(network partition) 一些node可能在非连接(network disconnect)区域内继续存活(alive and active),这种状况下只有quorum是一直运行的，没有quorum运行的分区中的节点则会进入non-primary状态。 鉴于以上的原因，在2个node的集群中做自动故障恢复几乎是不可能的， 因为失败的node节点会使得剩下的node进入non-primary状态(只有一个node没法做quorum)。更多的，在网络不连通的时候，不同交换机下的两个node可能会有一点满足分裂(split brain)条件的可能性,这时候不会保留quorum,并且两个node都会进入non-primary状态。所以对自动故障恢复来说，以下的’3 原则’值得推荐: 单交换机下的cluster至少应该有3个node； 分布不同交换机下的cluster, 应该至少跨越3个交换机； 分布不同网络(子网)下的cluster, 应该至少3个网络； 分布于不同数据中心下的cluster, 应该至少3个数据中心； 以上是在预防自动故障恢复工作过程中的防止分裂的方法。当然出于成本的考虑，增加交换机、数据中心等在很多情况下是不太现实的，Galera arbitrator(仲裁)是个可选的方式，它可以参与到quorum的选举，以组织split brain发生，但是它不会保留任何数据，也不会启动mysqld服务, 它是一个独立的deamon程序，详见http:///documentation-webpages/arbitrator.html 关于quorum举例如下: 2 nodes cluster配置(pc.ignore_quorum 和 pc.ignore_sb):http://www./2012/07/25/percona-xtradb-cluster-failure-scenarios-with-only-2-nodes/ |
|
|
来自： 瓜瓜2uuq7332fe > 《待分类》
