Galera replication for MySQL

By | 2014 年 4 月 13 日

这篇文章总结了之前对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)

36 thoughts on “Galera replication for MySQL

  1. yhy

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

    Reply
    1. gpfeng Post author

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

      Reply
  2. liangry

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

    Reply
    1. gpfeng Post author

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

      Reply
  3. daviswei

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

    Reply
  4. Terry

    博主您好

    是否每个节点都COMMIT成功后,Client才会收到成功的反馈,来执行下一个写的请求.

    Reply
    1. gpfeng Post author

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

      Reply
  5. Pingback: 理解 OpenStack 高可用(HA) (5): MySQL HA

  6. welyss

    帮助很大,但看完还是有几个问题没弄明白,可能是自己的基础知识和理解还是不够透彻,希望能帮忙解答!不胜感激!
    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,怎么保证复制的一致性= =
    貌似废话多了点。。。。

    Reply
    1. gpfeng Post author

      抱歉这么晚才回复

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

      Reply
    2. shiyifei

      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吗?

      Reply
      1. gpfeng Post author

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

        Reply
  7. 孙红亮

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

    Reply
    1. gpfeng Post author

      没有尝试过1个节点的galera集群,但是猜测这个问题可能和gcache有关

      Reply
      1. 孙大圣

        后来发现开始binlog以后这个问题就神奇的没有了,就是不知道为什么会是这样

        Reply
    1. gpfeng Post author

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

      Reply
  8. wangl

    博主,你好!我使用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

    Reply
    1. gpfeng Post author

      建库建表能够同步说明集群配置是OK的,建议检查MySQL报错信息,根据配置应该是/var/lib/mysql/mysqld.err

      Reply
  9. shiyifei

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

    Reply
  10. shiyifei

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

    Reply
    1. gpfeng Post author

      事务A或者B,其中1个会被回滚,这取决于哪个事务先被广播到group中

      Reply
  11. shiyifei

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

    Reply
  12. shiyifei

    Local read phase 执行的sql语句所涉及到的行已经被之前的写集加锁了,这时候会发生死锁的状况吗?

    Reply
    1. gpfeng Post author

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

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

      Reply
  13. shiyifei

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

    Reply
      1. shiyifei

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

        Reply
        1. gpfeng Post author

          印象中有个参数,可以开启一致性读,可以深入研究一下,只是这样集群性能就下去了

          Reply
  14. shiyifei

    iii. Certification based conflict detect

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

    Reply
    1. gpfeng Post author

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

      Reply

发表评论

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