注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

曾国藩的博客

 
 
 

日志

 
 

MariaDB cluster on CentOS VMs not working 解决问题和方法 用  

2014-06-06 10:47:43|  分类: SQL/Oracle/Mysql |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
http://stackoverflow.com/questions/23637694/mariadb-cluster-on-centos-vms-not-working

I have successfully configured MariaDB-Galera clusters on my CentOS 6.3 VMs in the past. All of a sudden things are just not working. This seems to be an issue that started as of the MariaDB-Galera-server.x86_64 version 5.5.37-1.el6. The last time I remember this working was with version 5.5.36. Did something change with the setup?

I have tried this with CentOS 6.3 and 6.5 without success.

asked May 13 at 17:16

1  
You are going to need to provide significantly more information than this if you hope to get anything even resembling meaningful assistance from anyone. –  Etan Reisner May 13 at 17:37
    
Ok. I am running three CentOS VMs on my Macbook. Each of these runs a MariaDB-Galera-server instance. Each database instance comes up and runs just fine individually. I can bring up the first node as the first node in the cluster, but when I go to add the second node it just sits with "Starting MySQLSST in progress, setting sleep higher....." and the dots keep coming. –  user3633574 May 13 at 18:44
    
Let me try to add more info here: –  user3633574 May 13 at 18:51
    
I will try again:140513 13:48:52 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out) at gcomm/src/pc.cpp:connect():141 140513 13:48:52 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():202: Failed to open backend connection: -110 (Connection timed out) 140513 13:48:52 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1291: Failed to open channel 'cluster1' at 'gcomm://192.168.33.32': -110 (Connection timed out) 140513 13:48:52 [ERROR] WSREP: gcs connect failed: Connection timed out 140513 13:48:52 [ERROR] WSREP: wsrep::connect() failed: –  user3633574 May 13 at 18:53
    
Even after the error log says that "/usr/sbin/mysqld: Shutdown complete" the "Starting MySQLSST in progress" message keeps running. I have to kill the processes on this system to get them to stop. –  user3633574 May 13 at 18:55
show 2 more comments

1 Answer

OK. I have tried a few different things and finally came back to using the previous version. Something has changed from 5.5.36 and 5.5.37 that causes the transfer of datafiles to the new node fail.

I am using SST method of rsync.

My test environment consists of three CentOS 6.5 VMs on my Macbook. I use yum to install MariaDB and Galera. The only difference is in the MariaDB.repo file. The installation that works uses: baseurl = http://yum.mariadb.org/5.5.36/centos6-amd64

The installation that does not work uses: baseurl = http://yum.mariadb.org/5.5/centos6-amd64

Everything else is identical.

The log file on the primary node contains the following when I start the second node:

140515 10:30:44 [Note] WSREP: declaring e18ac23e-dc45-11e3-a9cf-226f3dddee1e stable
140515 10:30:44 [Note] WSREP: Node d08d572e-dc45-11e3-927e-ffff30b2f80d state prim
140515 10:30:44 [Note] WSREP: view(view_id(PRIM,d08d572e-dc45-11e3-927e-ffff30b2f80d,2) memb {
    d08d572e-dc45-11e3-927e-ffff30b2f80d,0
    e18ac23e-dc45-11e3-a9cf-226f3dddee1e,0
} joined {
} left {
} partitioned {
})
140515 10:30:44 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 2
140515 10:30:44 [Note] WSREP: STATE_EXCHANGE: sent state UUID: e1b4f3cf-dc45-11e3-826a-7ffb98deb745
140515 10:30:44 [Note] WSREP: STATE EXCHANGE: sent state msg: e1b4f3cf-dc45-11e3-826a-7ffb98deb745
140515 10:30:44 [Note] WSREP: STATE EXCHANGE: got state msg: e1b4f3cf-dc45-11e3-826a-7ffb98deb745 from 0 (box1)
140515 10:30:45 [Note] WSREP: STATE EXCHANGE: got state msg: e1b4f3cf-dc45-11e3-826a-7ffb98deb745 from 1 (box2)
140515 10:30:45 [Note] WSREP: Quorum results:
    version    = 3,
    component  = PRIMARY,
    conf_id    = 1,
    members    = 1/2 (joined/total),
    act_id     = 0,
    last_appl. = 0,
    protocols  = 0/5/2 (gcs/repl/appl),
    group UUID = 672cb2c5-dc41-11e3-827f-e25ede7fb9ba
140515 10:30:45 [Note] WSREP: Flow-control interval: [23, 23]
140515 10:30:45 [Note] WSREP: New cluster view: global state: 672cb2c5-dc41-11e3-827f-e25ede7fb9ba:0, view# 2: Primary, number of nodes: 2, my index: 0, protocol version 2
140515 10:30:45 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
140515 10:30:45 [Note] WSREP: REPL Protocols: 5 (3, 1)
140515 10:30:45 [Note] WSREP: Assign initial position for certification: 0, protocol version: 3
140515 10:30:45 [Note] WSREP: Service thread queue flushed.

The log file on the second node contains the following:

140515 10:30:42 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140515 10:30:42 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.PFBl11' --pid-file='/var/lib/mysql/box2.vagrant-recover.pid'
140515 10:30:44 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1
140515 10:30:44 [Note] WSREP: wsrep_start_position var submitted: '00000000-0000-0000-0000-000000000000:-1'
140515 10:30:44 [Note] WSREP: Setting wsrep_ready to 0
140515 10:30:44 [Note] WSREP: Read nil XID from storage engines, skipping position init
140515 10:30:44 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so'
140515 10:30:44 [Note] WSREP: wsrep_load(): Galera 25.3.2(r170) by Codership Oy <info@codership.com> loaded successfully.
140515 10:30:44 [Note] WSREP: CRC-32C: using "slicing-by-8" algorithm.
140515 10:30:44 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
140515 10:30:44 [Note] WSREP: Passing config to GCS: base_host = 192.168.33.32; base_port = 4567; cert.log_conflicts = no; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.proto_max = 5
140515 10:30:44 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1
140515 10:30:44 [Note] WSREP: wsrep_sst_grab()
140515 10:30:44 [Note] WSREP: Start replication
140515 10:30:44 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
140515 10:30:44 [Note] WSREP: protonet asio version 0
140515 10:30:44 [Note] WSREP: Using CRC-32C (optimized) for message checksums.
140515 10:30:44 [Note] WSREP: backend: asio
140515 10:30:44 [Note] WSREP: GMCast version 0
140515 10:30:44 [Note] WSREP: (e18ac23e-dc45-11e3-a9cf-226f3dddee1e, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
140515 10:30:44 [Note] WSREP: (e18ac23e-dc45-11e3-a9cf-226f3dddee1e, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
140515 10:30:44 [Note] WSREP: EVS version 0
140515 10:30:44 [Note] WSREP: PC version 0
140515 10:30:44 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.33.31:,192.168.33.32:,192.168.33.33:'
140515 10:30:44 [Warning] WSREP: (e18ac23e-dc45-11e3-a9cf-226f3dddee1e, 'tcp://0.0.0.0:4567') address 'tcp://192.168.33.32:4567' points to own listening address, blacklisting
140515 10:30:44 [Note] WSREP: (e18ac23e-dc45-11e3-a9cf-226f3dddee1e, 'tcp://0.0.0.0:4567') address 'tcp://192.168.33.32:4567' pointing to uuid e18ac23e-dc45-11e3-a9cf-226f3dddee1e is blacklisted, skipping
140515 10:30:45 [Note] WSREP: declaring d08d572e-dc45-11e3-927e-ffff30b2f80d stable
140515 10:30:45 [Note] WSREP: Node d08d572e-dc45-11e3-927e-ffff30b2f80d state prim
140515 10:30:45 [Note] WSREP: view(view_id(PRIM,d08d572e-dc45-11e3-927e-ffff30b2f80d,2) memb {
    d08d572e-dc45-11e3-927e-ffff30b2f80d,0
    e18ac23e-dc45-11e3-a9cf-226f3dddee1e,0
} joined {
} left {
} partitioned {
})
140515 10:30:45 [Note] WSREP: discarding pending addr without UUID: tcp://192.168.33.33:4567
140515 10:30:45 [Note] WSREP: discarding pending addr proto entry 0x7f48c30b2080
140515 10:30:45 [Note] WSREP: gcomm: connected
140515 10:30:45 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 32636
140515 10:30:45 [Note] WSREP: Shifting CLOSED -> OPEN (TO: 0)
140515 10:30:45 [Note] WSREP: Opened channel 'my_wsrep_cluster'
140515 10:30:45 [Note] WSREP: Waiting for SST to complete.
140515 10:30:45 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 1, memb_num = 2
140515 10:30:45 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
140515 10:30:45 [Note] WSREP: STATE EXCHANGE: sent state msg: e1b4f3cf-dc45-11e3-826a-7ffb98deb745
140515 10:30:45 [Note] WSREP: STATE EXCHANGE: got state msg: e1b4f3cf-dc45-11e3-826a-7ffb98deb745 from 0 (box1)
140515 10:30:45 [Note] WSREP: STATE EXCHANGE: got state msg: e1b4f3cf-dc45-11e3-826a-7ffb98deb745 from 1 (box2)
140515 10:30:45 [Note] WSREP: Quorum results:
    version    = 3,
    component  = PRIMARY,
    conf_id    = 1,
    members    = 1/2 (joined/total),
    act_id     = 0,
    last_appl. = -1,
    protocols  = 0/5/2 (gcs/repl/appl),
    group UUID = 672cb2c5-dc41-11e3-827f-e25ede7fb9ba
140515 10:30:45 [Note] WSREP: Flow-control interval: [23, 23]
140515 10:30:45 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 0)
140515 10:30:45 [Note] WSREP: State transfer required: 
    Group state: 672cb2c5-dc41-11e3-827f-e25ede7fb9ba:0
    Local state: 00000000-0000-0000-0000-000000000000:-1
140515 10:30:45 [Note] WSREP: New cluster view: global state: 672cb2c5-dc41-11e3-827f-e25ede7fb9ba:0, view# 2: Primary, number of nodes: 2, my index: 1, protocol version 2
140515 10:30:45 [Warning] WSREP: Gap in state sequence. Need state transfer.
140515 10:30:45 [Note] WSREP: Setting wsrep_ready to 0
140515 10:30:45 [Note] WSREP: [debug]: closing client connections for PRIM
140515 10:30:47 [Note] WSREP: waiting for client connections to close: 2
140515 10:30:47 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'joiner' --address '192.168.33.32' --auth 'root:o4guk8x' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --parent '19293''

I am not sure just how that all fits yet.

  评论这张
 
阅读(1930)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018