Galera replication for MySQL

这篇文章总结了之前对Galera replication的调研,内容包括Galera特性,原理,Galera cluster配置,参数及性能等

Galera replication是什么

MySQL DBA及开发应该都知道MySQL源生复制及semi-sync半同步复制,它们都基于MySQL binlog,原生复制是完全异步的,master不需要保证slave接收并执行了binlog,能够保证master最大性能,但是slave可能存在延迟,主备数据无法保证一致性,在不停服务的前提下如果master宕机让slave顶上,就会丢失数据,semi-sync在异步复制基础上增加了数据保护的考虑,master必须确认slave收到binlog后(但不保证slave执行了事务)才能最终提交事务,在没有退化(延迟较大时可能发生)成异步复制之前可以保证数据安全,此时master挂掉之后,slave可以在apply完所有relay log后切换成master提供读写服务

Galera replication是codership提供的MySQL数据同步方案,具有高可用,易于扩展等特点,它将多个MySQL节点组织成一个cluster

Galera replication特性

1. 同步复制,主备无延迟
2. 支持多主同时读写,保证数据一致性
3. 集群中各节点保存全量数据
4. 节点添加/删除,自动检测和配置
5. 行级别并行复制
6. 不需要写binlog

相对于MySQL源生复制和semi-sync,Galera replication比较有吸引力的特性:
1. 同步复制,主备无延迟,master宕机后slave可以立即顶上并提供服务(semi-sync需要apply完所有relay log)
2. 事务冲突检测保证数据一致性,多个节点可以同时读写数据,可以极大简化数据访问
3. 行级别并行复制,MySQL 5.6之前slave sql线程只有一个,这个长期饱受诟病,是导致slave落后master的主要原因

Galera replicateion限制

1. 集群至少3个节点(2个节点也可以运行)
2. 存储引擎:Innodb / XtraDB / Maria
3. 不支持的SQL:LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…
4. 不支持XA Transaction

目前可用的产品:MariaDB Galera ClusterPercona XtraDB Cluster

Galera replication原理

Galera replication是一种Certification based replication,保证one-copy serializability,理论基于这两篇论文:Don’t be lazy, be consistentDatabase State Machine Approach

算法示意图

Galera_certification
图片来自上面两篇论文

算法伪代码(Certification包含了后续流程,来自上面两篇论文)

Galera_algorithm

事务执行协议

遵守deferred update replication,事务在commit时才复制到其他节点,执行过程分为4个阶段:

1.Local read phase
  a) 本地(client连接到的节点)执行事务Ti,但不真正提交,真正提交之前进入Send phase
2.Send phase
  a) 若事务只读,直接提交,结束(多版本,只读事务不加锁)
  b) 将事务的写操作封装成WS(Write Set,基于行),广播到所有节点(包括自身)
3.Lock / Certificaion phase
  a) 对收到的WS中的每个WSi(X)
    i. 若X没有被加锁,对X加锁
    ii. 若X已被Tj加锁且Tj处于Local read phase/Send phase,回滚Tj,对X加锁
    iii. Certification based conflict detect
4.Write phase
  a) 若检测出冲突,回滚Ti
  b) 否则,执行WS,提交事务后释放锁资源
  c) 对于源节点,提交事务并向client返回结果

客户端/Galera节点信息交互图

Galera_Certification_1
图片来自mysqlperformanceblog

Galera replication采取的是乐观策略,即事务在一个节点提交时,被认为与其他节点上的事务没有冲突,首先在本地“执行”(之所以带引号,是因为事务没有执行完)后再发送到所有节点做冲突检测,存在两种情况下需要回滚事务:
1. WS复制到其它节点,被加到每个节点的slave trx queue中,与queue中前面的trxs在做certification test时发现冲突
2. WS通过了certification test后被保证一定会执行,在它执行过程中,如果该节点上有与其冲突的local trxs(Local phase),回滚local trxs

Galera提供了两个状态参数记录冲突:
wsrep_local_cert_failures:certification test中未通过的trx数目
wsrep_local_bf_aborts:apply trxs(已经通过certification test)时,回滚的local trxs(open but not commit)数目

因此事务在commit节点广播后,节点之间不交换“是否冲突”的信息,各个节点独立异步的处理该事务,certification based replication协议保证:
1. 事务在所有节点上要么都commit,要么都rollback/abort
2. 事务在所有节点的执行顺序一致

Certification based replication所依赖的基础技术:
Group Communication System
1) Atomic delivery (事务传输要么成功传给了所有节点,要么都失败)
2) Total order (事务在所有节点中的顺序一致)
3) Group maintenance (每个节点知道所有节点的状态)

传统的2PC(两阶段提交)做法

1. 2PC 事务结束时,所有节点数据达到一致
2. 协调者与参与者之间通信,参与者之间无连接
3. 受网络状态影响较大
4. 两次通信,需要得到每个参与者的反馈后才能决定是否提交事务

因此Galera replicateion相对于2PC减少了网络传输次数,消除了等待节点返回“决定是否冲突”的时间,从而可以提高了性能

Galera replication原理总结

1. 事务在本地节点执行时采取乐观策略,成功广播到所有节点后再做冲突检测
2. 检测出冲突时,本地事务优先被回滚
3. 每个节点独立、异步执行队列中的WS
4. 事务T在A节点执行成功返回客户端后,其他节点保证T一定会被执行,因此有可能存在延迟,即虚拟同步
Galera_latency

Galera flow control

galera是同步复制(虚拟同步)方案,事务在本地节点(客户端提交事务的节点)上提交成功时,其它节点保证执行该事务。在提交事务时,本地节点把事务复制到所有节点后,之后各个节点独立异步地进行certification test、事务插入待执行队列、执行事务。然而由于不同节点之间执行事务的速度不一样,长时间运行后,慢节点的待执行队列可能会越积越长,最终可能导致事务丢失。

galera内部实现了flow control,作用就是协调各个节点,保证所有节点执行事务的速度大于队列增长速度,从而避免丢失事务。实现原理和简单:整个galera cluster中,同时只有一个节点可以广播消息(数据),每个节点都会获得广播消息的机会(获得机会后也可以不广播),当慢节点的待执行队列超过一定长度后,它会广播一个FC_PAUSE消息,所以节点收到消息后都会暂缓广播消息,直到该慢节点的待执行队列长度减小到一定长度后,galera cluster数据同步又开始恢复

flow control相关参数:

gcs.fc_limit:待执行队列长度超过该值时,flow control被触发,对于Master-Slave模式(只在一个节点写)的galera cluster,可以配置一个较大的值,对启动多写的galera cluster,较小的值比较合适,因为较大待执行队列长度意味着更大的冲突,默认值16
gcs.fc_factor:当待执行队列长度开始小于(gcs.fc_factor*gcs.fc_limit)时,数据同步恢复,默认0.5
gcs.fc_master_slave:galera cluster是否为Master-Slave模式,默认

安装MariaDB Galera Cluster

安装准备:

1. MariaDB Galera Cluster 5.5.28a RC
1) https://downloads.mariadb.org/mariadb-galera/5.5.28a/
2) patched MariaDB 5.5.28,代码中增加了Galera Library API(wsrep API),并在事务、锁、handler等模块添加/修改了调用逻辑

2. Galera wsrep provider
1) https://launchpad.net/galera/+download
2) Galera Library的实现,其中实现了group communication system, certification

编译安装

1. MariaDB Galera Cluster 5.5.28a RC
1) 与MariaDB基本相同,cmake时增加两项:-DWITH_WSREP=ON , -DWITH_INNODB_DISALLOW_WRITES=1.
2. Galera wsrep provider: 源码编译后得到libgalera_smm.so(需要用到scons)

参数配置(每个节点)

wsrep_provider = /path/to/libgalera_smm.so
wsrep_cluster_address = cluster connection URL(后面详细介绍)
binlog_format = ROW
default_storage_engine = INNODB
innodb_autoinc_lock_mode = 2
innodb_locks_unsafe_for_binlog = 1

选配:(可以提高性能,galera保证不丢数据)
innodb_flush_log_at_trx_commit = 2

构建集群(三个节点)

3-node-cluster
节点名称 ip地址
galera_node1 10.0.0.11
galera_node2 10.0.0.22
galera_node3 10.0.0.33

新建Galera Cluster

以galera_node1作为第一个节点新建集群,在my.cnf中配置参数:

wsrep_cluster_address = gcomm://
wsrep_cluster_name = galera_cluster
wsrep_node_address = 10.0.0.11
wsrep_node_name = galera_node1
wsrep_sst_method = rsync

添加galera_node2节点

在my.cnf中配置wsrep_cluster_address为node1的ip或者hostname

wsrep_cluster_address = gcomm://10.0.0.11
wsrep_cluster_name = galera_cluster
wsrep_node_address = 10.0.0.22
wsrep_node_name = galera_node2
wsrep_sst_method = rsync

添加galera_node3节点

在my.cnf中配置wsrep_cluster_address为node1的ip或者hostname

wsrep_cluster_address = gcomm://10.0.0.11
wsrep_cluster_name = galera_cluster
wsrep_node_address = 10.0.0.33
wsrep_node_name = galera_node3
wsrep_sst_method = rsync

多实例配置

因为测试机器资源有限,需要在同一台机器上启动多个mysqld实例,为每个mysqld配置两个端口号(一个是mysql server端口号,默认3306;另外一个是wsrep端口号,默认4567),并修改部分wsrep配置参数,例如:

galera-cluster
节点名称 ip地址 server port wsrep port wsrep配置
galera_node1 127.0.0.1 3306 4405 wsrep_cluster_address=gcomm:// wsrep_node_address=127.0.0.1:4405 port=3306
galera_node2 127.0.0.1 3307 4407 wsrep_cluster_address=gcomm://127.0.0.1:4405 wsrep_node_address=127.0.0.1:4407 port=3307
galera_node3 127.0.0.1 308 4409 wsrep_cluster_addres=gcomm:// 127.0.0.1:4405 wsrep_node_address=127.0.0.1:4409 port=3308

启动后在每个节点执行:

mysql> show status like ‘wsrep%;

当看到下述状态时:

wsrep_connected=ON
wsrep_ready=ON
wsrep_cluster_status =Primary
wsrep_cluster_size=3(节点个数)

则galera集群建立成功,如下图所示:

Galera_status

说明:
1. MariaDB Galera Cluster 5.5.28a RC源码安装,在编译时若没有打开-DWITH_WSREP=ON, -DWITH_INNODB_DISALLOW_WRITES=1,或者没有配置任何wsrep相关参数,它运行时就是一个普通的mysqld实例
2. Galera cluster复制不依赖于binlog文件,因此mysql-binlog和log-slave-updates都可以不配置,当然如果需要记录binlog,也可以打开
3. 需要以wsrep_cluster_address = gcomm://启动第一个节点后,才能相继添加其他节点

Galera相关参数配置

InnoDB 相关参数

galera补丁版的mysql在cmake时需要指定:
-DWITH_WSREP=ON , -DWITH_INNODB_DISALLOW_WRITES=1

galera 目前只支持Innodb/xtradb/mariad存储引擎
default_storage_engine = INNODB

为了降低冲突,下列两项需要设置
innodb_autoinc_lock_mode = 2
innodb_locks_unsafe_for_binlog = 1(gap不加锁)

选配:(可以提高性能,galera保证不丢数据)
innodb_flush_log_at_trx_commit = 2

选配:galera可以不写binlog,注释binlog路径理论上可以提高性能
#log-bin
#log-slave-updates=1

wsrep 相关参数

wsrep参数都是以wsrep_开头的(30+个),其中有一个字符串参数(wsrep_provider_options)可以配置50+个更底层的参数。
可以通过“show variables like wsrep%”查看,wsrep_开头参数,点击查看详情

列举几个重要的参数:

wsrep_auto_increment_control:控制auto_increment_increment=#nodes和auto_increment_offset=#node_id,默认ON
wsrep_causal_reads:默认是在本地节点读,读到的可能不是最新数据,开启后将读到最新数据,但会增加响应时间,默认OFF
wsrep_certify_nonPK:为没有显示申明主键的表生成一个用于certification test的主键,默认ON
wsrep_cluster_address: 启动节点时需要指定galera cluster的地址,作为cluster中第一个启动的节点,wsrep_cluster_address=gcomm://,对于后续启动的节点,wsrep_cluster_address=gcomm://node1,node2,node3	
wsrep_cluster_name: 所有node必须一样, 默认my_test_cluster
wsrep_convert_LOCK_to_trx:将LOCK/UNLOCK TABLES转换成BEGIN/COMMIT,默认OFF
wsrep_data_home_dir:galera会生成一些文件,默认使用mysql_data_dir,默认mysql_data_dir
wsrep_node_name:节点名称
wsrep_on:session/global,设置为OFF时,事务将不会复制到其他节点,默认ON
wsrep_OSU_method:Online Schema Update设置,TOI/RSU(MySQL >= 5.5.17),默认TOI
wsrep_provider:libgalera_smm.so的路径,若没有配置,galera复制不会启动,默认none
wsrep_provider_options:很长的字符串变量,可以配置很多group communication system相关参数,很长很长...
wsrep_retry_autocommit:事务在冲突时重新尝试的次数,默认1
wsrep_slave_threads:并行复制的slave线程数,默认4
wsrep_sst_method:Snapshot State Transter方法:mysqldump/rsync/xt,默认mysqldump

wsrep_provider_options
该参数是一个字符串,包含了group communication system中很多参数设置,配置时使用分号隔开:
wsrep_provider_options=”key_a=value_a;key_b=value_b;key_c=value_c”,点击查看详情

列举其中部分重要参数:

evs.send_window:节点一次可以发送的消息数目,默认4
evs.user_send_window:其与evs.send_window之间的差别类似于max_connections与max_user_connection,默认2
gcs.fc_factor:flow control参数,默认0.5
gcs.fc_limit:flow control参数,默认16
gcs.fc_master_slave:flow control参数,默认NO
gcs.recv_q_hard_limit:接收队列的占用的最大内存,默认LLONG_MAX
gcs.recv_q_soft_limit:当接收队列占用内存超过(gcs.recv_q_hard_limit*gcs.recv_q_soft_limit),复制被延迟,默认0.25
gmcast.listen_addr:节点用于接收其它节点消息的地址,默认tcp://0.0.0.0:4567
pc.checksum:是否对发送的消息做checksum,默认true
pc.ignore_sb:是否忽略split brain,默认false

一个例子

binlog_format=row 
default-storage-engine = INNODB 
innodb_autoinc_lock_mode = 2 
innodb_locks_unsafe_for_binlog = 1
wsrep_provider = /u01/mariadb-galera/lib/libgalera_smm.so 
wsrep_cluster_address = "gcomm://192.168.xxx.01" 
wsrep_cluster_name = galera 
wsrep_node_address = 192.168.xxx.xxx 
wsrep_node_name = slave 
wsrep_sst_method = rsync 
wsrep_slave_threads = 16 
wsrep_provider_options="gcache.page_size=128M;gcache.size=2G;gcs.fc_limit=512;gcs.fc_factor=0.9;evs.send_window=256;evs.user_send_window=128"

Galera status variables

Galera提供了很多以wsrep_开头状态参数监控mysql状态,通过show status like ‘wsrep%’可以查看:

wsrep_local_state_uuid:应该与wsrep_cluster_state_uuid一致,如363acc29-9160-11e2-0800-4316271a76e4
wsrep_last_committed:已经提交事务数目,所有节点之间相差不大,可以用来计算延迟
wsrep_replicated:从本地节点复制出去的write set数目
wsrep_replicated_bytes:从本地节点复制出去的write set的总共字节数
wsrep_received:本地节点接收来自其他节点的write set数目
wsrep_received_bytes:本地节点接收来自其他节点的write set的总共字节数
wsrep_local_commits:从本地节点发出的write set被提交的数目,不超过wsrep_replicated
wsrep_local_cert_failures:certification test失败的数目
wsrep_local_bf_aborts:certification test通过的write set执行过程中回滚的与其冲突的本地事务
wsrep_local_replays:事务被回滚(bf abort)重做的数目
wsrep_local_send_queue:发送队列的长度
wsrep_local_send_queue_avg:从上次查询状态到目前发送队列的平均长度,>0.0意味着复制过程被节流了
wsrep_local_recv_queue:接收队列的长度
wsrep_local_recv_queue_avg:从上次查询状态到目前接收队列的平均长度,>0.0意味着执行速度小于接收速度
wsrep_flow_control_paused:从上次查询状态到目前处于flow control的时间占比,如0.388129
wsrep_flow_control_sent:从上次查询状态到目前节点发送出的FC_PAUSE消息数目,如1
wsrep_flow_control_recv:从上次查询状态到目前及节点接收的FC_PAUSE消息数目,如1
wsrep_cert_deps_distance:可以并行执行的write set的最大seqno与最小seqno之间的平均差值,如1851.825751
wsrep_apply_oooe:队列中事务并发执行占比,值越高意味着效率越高
wsrep_commit_window:平均并发提交窗口大小
wsrep_local_state:节点的状态,取值1-6
wsrep_local_state_comment:节点的状态描述,比如Synced
wsrep_incoming_addresses:集群中其它节点的地址,多个地址之间用逗号分隔
wsrep_cluster_conf_id:集群节点关系改变的次数(每次增加/删除都会+1)
wsrep_cluster_size:集群节点个数
wsrep_cluster_state_uuid:集群uuid,所有节点应该一样,如:363acc29-9160-11e2-0800-4316271a76e4
wsrep_cluster_status:集群的目前状态,取值:PRIMARY(正常)/NON_PRIMARY(不一致)
wsrep_connected:节点是否连接到集群,取值:ON/OFF
wsrep_local_index:节点id
wsrep_provider_name:默认Galera
wsrep_provider_vendor:默认Codership Oy <info@codership.com>
wsrep_provider_version:wsrep版本,如:2.2(rXXXX)
wsrep_ready:节点是否可以接受查询了,取值:ON/OFF

一个截图:

Galera_status_1

如何检查节点是否加入到集群

1. wsrep_cluster_state_uuid应该与其它所有节点相同
2. wsrep_cluster_conf_id应该与其它所有节点相同
3. wsrep_cluster_size应该是所有节点的数目
4. wsrep_cluster_status取值应该是:Primary
5. wsrep_ready取值应该是ON
6. wsrep_connected取值应该是ON

判断复制过程是否出现问题

wsrep_flow_control_paused,正常情况下,其取值应该接近于0.0,大于0.0意味着有‘慢节点’影响了集群的速度,可以尝试通过增大wsrep_slave_threads来解决

找出最慢的节点

wsrep_flow_control_sent,wsrep_local_recv_queue_avg两个值最大的节点

参考:galera statusgalera monitoring

性能测试

由于galera同步复制在每个写事务提交时都增加了replicate trx和certification test的开销,因此性能远远低于异步MySQL实例

测试场景

使用TPCC进行测试,包含3组数据:
1、normal mysql: baseline,单个mysql server
2、galera (RTT: 0.5ms): 2-nodes galera cluster,单节点读写
3、galera (RTT: 15.2ms): 2-nodes galera cluster,单节点读写

tpmC结果:
Galera_performance
TPS结果:
Galera_performance_tps

测试结论:

1. 相对于异步MySQL实例,Galera replication性能下降约50% ~ 60%左右
2. Galera最大性能不受RTT影响,RTT 较小时(0.5ms),在达到最大性能之前(32并发),性能下降并不明显 (32并发下降25%,16并发性能下降更低),RTT较大时(15.2ms),在达到最大性能之前(64并发),相对于norml mysq性能下降一直到很明显,当压力逐渐增大,由于group io的原因,galera性能在达到最大时还会提高

Galera replication for MySQL学习资料

1. codership官网
2. mysqlperformanceblog搜索中PXC(Percona XtraDB Cluster)

《Galera replication for MySQL》上有36条评论

  1. 博主:
    你好!看了你写的文章,感觉清晰易懂。但是我还是有些问题:
    1.Certification的伪代码中,如果其他server Certification没有通过,那么应该整个事务都回滚,但图中和伪代码中都没有看出哪里执行了这一点。
    2.按理说,应该是等其他所有server都commit成功后,才最终把成功状态返回客户端,图中也没有体现啊。
    3.看到有的人说如果发现出现冲突就直接让节点挂掉,这个是怎么实现的,而且我觉得这样不合理啊

    1. 所有节点certification结果是一样的 因为每个计算冲突时用的数据是一致的 事务传输的时候会附上当前节点已commit的最大事务id

  2. 一个小白问题:是否必须使用MariaDB?原生的MySQL 5.5是否能够支持Galera?如果不行,通过打补丁是否可以达到目的?

    1. 想要使用原生MySQL的话必须打patch,因为Galera需要将binlog处理成他们的格式,而且在事务提交阶段需要注入数据复制的钩子函数,patch方式难度略微有些大,较难保证不弄出新的bug

  3. 请教一下,能通过编译来安装mariaDB的galera吗,我在官网下载的tar包,解压出来好像已经可以直接执行install-db了,我想将tcmalloc编译进去……

    1. 不是的,接受服务的master节点只负责write set广播出去了就可以返回client,每个节点数据一致性是由底层的group communication决定的,确保了其他节点certification test的结果是一致的

  4. 帮助很大,但看完还是有几个问题没弄明白,可能是自己的基础知识和理解还是不够透彻,希望能帮忙解答!不胜感激!
    1 如果client向node1发出1个(对数据a进行了修改)写事务,则在node1上乐观提交该事务,并writeset到其他node,假设各自node验证都通过,则此时node1物理提交并返回给client
    假设这时该事务在node2上还处在队列中,虽然是保证一定执行,但是还未物理提交的话,这个时候如果有新的读请求发到client2上,请求读取刚才那个数据,那是不是要等队列刷到最新,才能保证这个数据是最新的?这个逻辑具体是怎么样的?
    引用下galera官document里对sync replic的解释:
    Synchronous Replication Uses the approach of eager replication. Nodes keep all replicas synchronized by updating all replicas in a single transaction. In other words, when a transaction commits, all nodes have the same value
    这里的eager和最后那句感觉和这个说的有点冲突。这个点一直没想明白。
    2 我看了那2篇论文里的一篇中有说到atomic broadcast comunication是通过paxos算法实现的,在galera中有没有用到,具体是哪里有用到?
    3 有两个配置项愣是没想明白:
    gcs.fc_master_slave这个参数的作用没想明白
    还有个是开启UDP模式,官方还说大型的集群推荐配上,我想不明白的是用了不可靠的udp,怎么保证复制的一致性= =
    貌似废话多了点。。。。

    1. 抱歉这么晚才回复

      1. galera不是完全的同步复制,master在broadcast writeset后不需要等待其他节点是否冲突需要rollback的回复信息,读数据有两个模式:强一致性读和当前读
      2. atomic broadcast communication算法比较复制,我看源代码也是一头雾水,但它是galera的基础,保证了writeset序列在所有节点是相同的顺序,因此各个节点可以独立做certification test并执行相同的commit/rollback操作

    2. 1. WS复制到其它节点,被加到每个节点的slave trx queue中,与queue中前面的trxs在做certification test时发现冲突

      针对这句话,我有几个问题:
      1. slave trx queue中的trx 如何冲突的? 是因为与队列之前的trx有相同主键的记录吗?
      2. 有主键冲突也不会验证失败啊,如果不是同一个GTID,前一个先执行后会修改GTID的啊,也不应该验证失败的吧?
      3.是不是每一个客户端提交的事务都会生成一个GTID, 即global Transaction ID ?
      4. 多个节点提交的事务可以拥有相同的GTID吗?

      1. 1. 基于主键做冲突检测
        2. 事务是有上下文的,WS会有关联的last_comitted trx,last_comitted之前的事务不参与冲突检测
        3. 每个事务都对应唯一的GTID
        4. 不会

  5. 博主,想请教一个问题,对一个节点的Galera集群进行写入,50的并发,CPU占41%,其中IOWait占21%,磁盘写入速度在1875左右,隔30s左右还会出现一个5500左右的写入峰值,但是同等测试条件下,单机状态下CPU在28%左右,写入在420-480之间,没有峰值,基本没有IOWait。我想问的是为什么单节点的Galera集群写入会有这么多的磁盘写入???

    1. 用的是标准的TPCC做的benchmark,主要关注相对性能,cpu,内存大小及磁盘类型都会影响测试结果,galera集群的最大性能遵守『木桶原理』,建议测试时3个节点硬件及配置保持一致

  6. 博主,你好!我使用MariaDB 10.1和10.2的版本组建了集群,建库、建表都能实时同步,但插入、删除记录均不能同步,不知道是哪里配置错了,请不吝赐教,谢谢!
    配置信息如下:
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    user=mysql
    binlog_format=ROW
    bind-address=0.0.0.0
    default_storage_engine=innodb
    innodb_autoinc_lock_mode=2
    innodb_flush_log_at_trx_commit=0
    innodb_buffer_pool_size=122M
    wsrep_provider=/usr/lib64/galera/libgalera_smm.so
    wsrep_provider_options=”gcache.size=300M; gcache.page_size=300M”
    wsrep_cluster_name=”example_cluster”
    wsrep_cluster_address=”gcomm://192.168.254.73,192.168.254.75,192.168.254.76″
    wsrep_sst_method=rsync
    wsrep_node_addr=192.168.73
    wsrep_node_name=test1

  7. 多主模式下,A节点提交的事务是不是只要在本节点上认证通过了(不用管其他节点的认证结果),然后就可以提交并返回给客户端了?

  8. 如果节点A提交一个事务,节点B同时也提交一个事务,这两个事务更新的是同一条记录,那么在认证测试时会发生冲突吗?为什么?

  9. 如果节点A提交一个事务,节点B同时也提交一个事务,没有其他终端操作的情况下 上次GTID 顺序号为3, 那么这两个事务执行过程中会产生几个GTID呢?

    1. 存在这样的情况下,local read phase加锁,但是遇到节点apply write set时的锁冲突,这时local trx会锁等待,最终超时,事务回滚

      另外一种情况,节点延迟,但local trx早于write set,本地发起commit后,broadcast到所有节点,但是certification test会失败,最终也是事务回滚

  10. 如果某一行数据被A节点修改并提交,此时客户端读取B节点的这一行数据,但是B节点还未执行完A节点上的修改,那么此时B节点会返回给客户端什么数据?是修改前的还是修改后的数据呢?

      1. 读取A节点是新数据,读取B节点是旧数据,那整个集群查出的这条记录就会有两种结果,这样的话集群就不能保证强一致性了吧?

  11. iii. Certification based conflict detect

    这一句话,具体会做些什么工作呢?是发现了有锁冲突然后又做了些什么呢?

    1. 有锁冲突就进入锁等待了,如果锁等待超时,就报错并回滚事务:
      ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

回复 gpfeng 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注