MariaDB wsrep_provider_options (gcache)
1. wsrep_provider_options
wsrep 의 연관 parameter 중 서비스 운용상 상당히 중요한 파라미터이다.
특히 SST (초기적재) 상황을 피하기 위해서는 적절한 값 셋팅이 필요하다.
2.
Default options for wsrep_provider_options
아래의 값은 3 Node 클러스터에서
기본 값을 조회한 결과로 각각의 값은
클러스터 구성에 따라 다른 default 값을 가져갈 수 있다.
노란색으로 표시한 Variables 는 gcache 와
관련 있는 셋팅이다.
l wsrep_provider_version = 23.2.4(r147)
base_host = 172.18.187.136;
base_port = 4567;
cert.log_conflicts = no;
evs.causal_keepalive_period = PT1S;
evs.debug_log_mask = 0x1;
evs.inactive_check_period = PT0.5S;
evs.inactive_timeout = PT15S;
evs.info_log_mask = 0;
evs.install_timeout = PT15S;
evs.join_retrans_period = PT1S;
evs.keepalive_period = PT1S;
evs.max_install_timeouts = 1;
evs.send_window = 4;
evs.stats_report_period = PT1M;
evs.suspect_timeout = PT5S;
evs.use_aggregate = true;
evs.user_send_window = 2;
evs.version = 0;
evs.view_forget_timeout = PT5M;
gcache.dir = /home/maria/mariadb/data/;
gcache.keep_pages_size = 0;
gcache.mem_size = 0;
gcache.name = /home/maria/mariadb/data//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;
gmcast.listen_addr = tcp://0.0.0.0:4567;
gmcast.mcast_addr = ; gmcast.mcast_ttl = 1;
gmcast.peer_timeout = PT3S;
gmcast.time_wait = PT5S;
gmcast.version = 0;
ist.recv_addr = 172.18.187.136;
pc.checksum = true;
pc.ignore_quorum = false;
pc.ignore_sb = false;
pc.linger = PT20S; pc.npvo = false;
pc.version = 0; pc.weight = 1;
protonet.backend = asio;
protonet.version = 0;
replicator.causal_read_timeout = PT30S;
replicator.commit_order = 3
3. gcache
gcache.dir -> default = datadir
gcache.keep_pages_size -> default = 0
gcache.mem_size -> default = 0
gcache.name -> default = galera.cache
gcache.page_size -> default = 128 M
gcache.size -> default = 128 M
default 값은 위와 같다.
위에서 SST 회피를 위해 추가 셋팅해야 할 Variable 은 gcache.size 이다.
Galera Cluster Membership 에 새로운 노드가 추가되면 IST (증분) 를 확인하고 이게 불가능하면 SST (초기적재) 를
진행하는데 IST (증분) 처리를 하기 위한 변경을 적용할 내용이 gcache.size 를 사용한다.
variables 셋팅은 다음과 같이 한다.
wsrep_provider_options = ‘a=b;’
wsrep_provider_options = ‘a=b;c=d’
wsrep_provider_options = ‘a=b;c=d;e=f’
여기서는 gcache.size 만 셋팅한다.
vi my.cnf (Dynamic variable 이 아니기에 conf 파일을 수정해야 하며, restart 해야 적용된다.)
wsrep_provider_options=’gcache.size=512M’
4. Status related to gcache
gcache.size 를 지정하기에 앞서 어떤 크기로 지정할 것인가에 대한 의문이 있다.
gcache 라는 것은 결국 변경에 대한 내용을 담고 있어, 이를 통해 최신의 클러스터 멤버 상태와
동일하게 만들어주는 역할을 한다.
모든 변경 내역이라고도 말할 수 있는데 (binary logs 와는 다르다) 그렇기에 아래와 같은
Status 로 추정할 수 있을 것이다.
주의점으로는 통계와 관계 있는 status 의 값들은 대다수가 누적값이다.
값의 변화량을 알기 위해서는 두 시점의 값이 필요하다.
|
MariaDB [(none)]> show global status like '%byte%'; +--------------------------------+-----------+ | Variable_name | Value | +--------------------------------+-----------+ | Binlog_bytes_written | 29111617 | | Bytes_received | 5480 | | Bytes_sent | 21650 | | Innodb_buffer_pool_bytes_data | 259162112 | | Innodb_buffer_pool_bytes_dirty | 0 | | wsrep_replicated_bytes | 33392647 | | wsrep_repl_keys_bytes | 5580357 | | wsrep_repl_data_bytes | 12311715 | | wsrep_repl_other_bytes | 0 | | wsrep_received_bytes | 67546463 | +--------------------------------+-----------+ |
5. GCACHE.SIZE & BINLOG_BYTES_WRITTEN
GCACHE.SIZE 에 따른 IST, SST 여부를 판단하기 위해 테스트 데이터를 만들었다.
|
MariaDB [tmall]> select * into outfile '/home/maria/test.load' from prd a limit 20000;
MariaDB [test]> create table prd as select * from mall. prd limit 0; |
위 과정을 통해 120 메가의 파일이 만들어졌다.
더불어 데이터를 로드할 빈 데이터의 테이블을 만들었다.
|
MariaDB [test]> load data infile '/home/maria/test.load' replace into table prd; |
log-bin 셋팅이 되어 있으므로 binlog_bytes_written status 값을 가지고 gcache 사이즈 사용량과의 관계를 살펴보도록 하겠다.
위 과정을 통해 118 메가바이트가 쓰여졌다. (binlog_bytes_written 에서 산정)
위 과정을 통해 아래와 같은 메시지를 전 노드에서 얻었다.
141002 18:06:45 [Note] WSREP: Created page /home/maria/mariadb/data/gcache.page.000000 of size 134217728 bytes
위의 값은 128M 이다.
노드 하나를 shutdown 후 위 작업을 반복했다.
binlog_bytes_written 의 변화량도 동일한 118M 였고 err 파일에 다음과 같은 내용이 남았다.
141002 18:15:30 [Note] WSREP: Created page /home/maria/mariadb/data/gcache.page.000001 of size 134217728 bytes
gcache.page 의 번호가 1 증가했고, 이전에 만들어졌던 0 은 사라진 걸 확인할 수 있었다.
이제 shutdown 했던 노드 하나를 Cluster Membership 에 다시 넣어보겠다.
Donor node 의 err 로그
|
141002 18:20:28 [Note] WSREP: Service thread queue flushed. 141002 18:20:28 [Warning] WSREP: Releasing seqno 400075 before 400076 was assigned. 141002 18:20:28 [Note] WSREP: Deleted page /home/maria/mariadb/data/gcache.page.000001 141002 18:20:30 [Note] WSREP: Member 0.0 (xvmdb3) requested state transfer from 'xvmdb1'. Selected 1.0 (xvmdb1)(SYNCED) as donor. 141002 18:20:30 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 400075) 141002 18:20:30 [Note] WSREP: IST request: 6928da41-3e03-11e4-bbf7-4ec7061d8d46:400073-400075|tcp://172.18.174.161:4568 141002 18:20:30 [Note] WSREP: IST first seqno 400074 not found from cache, falling back to SST |
Joiner node 의 err 로그
|
141002 18:20:30 [Note] WSREP: Prepared SST request: rsync|172.18.174.161:4444/rsync_sst 141002 18:20:30 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 141002 18:20:30 [Note] WSREP: REPL Protocols: 5 (3, 1) 141002 18:20:30 [Note] WSREP: Service thread queue flushed. 141002 18:20:30 [Note] WSREP: Assign initial position for certification: 400075, protocol version: 3 141002 18:20:30 [Note] WSREP: Service thread queue flushed. 141002 18:20:30 [Note] WSREP: Prepared IST receiver, listening at: tcp://172.18.174.161:4568 141002 18:20:30 [Note] WSREP: Member 0.0 (xvmdb3) requested state transfer from 'xvmdb1'. Selected 1.0 (xvmdb1)(SYNCED) as donor. 141002 18:20:30 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 400075) 141002 18:20:30 [Note] WSREP: Requesting state transfer: success, donor: 1 141002 18:21:05 [Note] WSREP: 1.0 (xvmdb1): State transfer to 0.0 (xvmdb3) complete. 141002 18:21:05 [Note] WSREP: Member 1.0 (xvmdb1) synced with group. WSREP_SST: [INFO] Joiner cleanup. (20141002 18:21:05.759) WSREP_SST: [INFO] Joiner cleanup done. (20141002 18:21:06.302) 141002 18:21:06 [Note] WSREP: SST complete, seqno: 400075 |
로그를 보면 SST 로 처리된 것을 볼 수 있었다.
파일 사이즈가 115M, binlog_bytes_written 변화량이 118M, gcache.size 가 128M 였으나 SST 가 발생했다.
18000 ROWS 로 제한하여 위의 테스트를 다시 진행해 보았다.
|
MariaDB [tmall]> select * into outfile '/home/maria/test2.load' from prd a limit 18000; |
위의 출력 파일 크기는 다음과 같았다.
SIZE : 105 MB
더불어 Binlog_bytes_written 는 107 MB 정도였다.
아까와 마찬가지로 load 를 수행하였고 이번에는 error log 에 아무런 메시지가 없었다.
처음의 경우에는 다음의 메시지가 1, 2번 노드에 기록되었었다.
141002 18:15:30 [Note] WSREP: Created page /home/maria/mariadb/data/gcache.page.000001 of size 134217728 bytes
3번 노드를 클러스터에 다시 추가했을 때 IST 로 처리되었으며 에러로그는 다음과 같았다.
Donor node 의 err 로그
|
141006 18:08:49 [Note] WSREP: Member 0.0 (xvmdb3) requested state transfer from 'xvmdb1'. Selected 1.0 (xvmdb1)(SYNCED) as donor. 141006 18:08:49 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 400077) 141006 18:08:49 [Note] WSREP: IST request: 6928da41-3e03-11e4-bbf7-4ec7061d8d46:400075-400077|tcp://172.18.174.161:4568 141006 18:08:49 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 141006 18:08:49 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'donor' --address '172.18.174.161:4444/rsync_sst' --auth 'galera:testgalera' --socket '/tmp/maria.sock' --datadir '/home/maria/mariadb/data/' --defaults-file '/home/maria/mariadb/conf/my.cnf' --gtid '6928da41-3e03-11e4-bbf7-4ec7061d8d46:400075' --bypass' 141006 18:08:49 [Note] WSREP: sst_donor_thread signaled with 0 141006 18:08:49 [Note] WSREP: async IST sender starting to serve tcp://172.18.174.161:4568 sending 400076-400077 WSREP_SST: [INFO] Bypassing state dump. (20141006 18:08:49.419) 141006 18:08:58 [Note] WSREP: async IST sender served |
Joiner node 의 err 로그
|
141006 18:08:46 [Warning] WSREP: Gap in state sequence. Need state transfer. 141006 18:08:48 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'joiner' --address '172.18.174.161' --auth 'galera:testgalera' --datadir '/home/maria/mariadb/data/' --defaults-file '/home/maria/mariadb/conf/my.cnf' --parent '408'' 141006 18:08:49 [Note] WSREP: Prepared SST request: rsync|172.18.174.161:4444/rsync_sst 141006 18:08:49 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 141006 18:08:49 [Note] WSREP: REPL Protocols: 5 (3, 1) 141006 18:08:49 [Note] WSREP: Service thread queue flushed. 141006 18:08:49 [Note] WSREP: Assign initial position for certification: 400077, protocol version: 3 141006 18:08:49 [Note] WSREP: Service thread queue flushed. 141006 18:08:49 [Note] WSREP: Prepared IST receiver, listening at: tcp://172.18.174.161:4568 141006 18:08:49 [Note] WSREP: Member 0.0 (xvmdb3) requested state transfer from 'xvmdb1'. Selected 1.0 (xvmdb1)(SYNCED) as donor. 141006 18:08:49 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 400077) 141006 18:08:49 [Note] WSREP: Requesting state transfer: success, donor: 1 WSREP_SST: [INFO] Joiner cleanup. (20141006 18:08:50.324) WSREP_SST: [INFO] Joiner cleanup done. (20141006 18:08:50.869) 141006 18:08:50 [Note] WSREP: SST complete, seqno: 400075 141006 18:08:50 InnoDB: The InnoDB memory heap is disabled |
위 2가지를 비교하면 IST 냐 SST 냐는 Donor 측 err 로그에서 확인이 가능하다.
SST 의 경우는 FALL BACK TO SST 라는 메시지를 볼 수 있고, IST 의 경우엔 볼 수 없다.
6. Modify GCACHE.SIZE
Binlog_bytes_written 의 size 와 gcache.size 는 정확히 1:1 관계를 이루진 않는다.
위 사이즈 관계를 미세하게 컨트롤 테스트 하진 않았지만 107MB 에서 IST 처리가 된 것으로 보아,
굳이 추측을 하자면 Binlog_bytes_written * 1.2 크기가 gcache.size 보다 작으면 IST 처리가 될 것으로 보인다.
처음 SST 가 일어난 케이스는 Binlog_bytes_written = 118M 이었고 여기에 1.2 를 곱하면 142M 가 나온다.
테스트로 1번 노드에 대해 gcache.size= 142M 으로 변경하고, 전 노드 동작 상태에서 3번을 내린 후 118M 의 데이터를
load 했을 때 1번 노드는 아무런 err 메시지가 없었으나 2번 노드의 경우에는 새로운 캐시 페이지가 만들어졌다.
그리고 3번 노드를 1번을 Donor 로 추가했을 때 IST 로 처리되었다.
더불어 위의 결과를 통해 wsrep_provider_options 은 일부 노드 수정이 가능하다는 걸 알았다.
7.
Setting gcache.size on wsrep_provider_options
기존에 운용중에 gcache.size 를
조정하기 위해서는 다음의 흐름을 따라갈 것이다.
A. a 노드 shutdown, variables 수정 (my.cnf)
B. a 노드 startup
C. b 노드 shutdown, variables 수정 (my.cnf)
D. b 노드를 a 노드 donor 로 startup
E. c 노드를 shutdown, variables 수정 (my.cnf)
F. a 혹은 b 노드를 donor 로 startup
gcache.size 는 앞서 살펴 본 1.2 가중치를 생각하면 시간 당 2453MB 의 BINLOG 가 쌓인다면 2944MB 의 gcache.size 가 필요하다.
실제 위의 시간을 고려하여 size 셋팅을 했을 때 정말 그 정도의 시간에 대해 IST 처리가 가능한지에 대해서는 테스트가 필요하다.
8. References
A.
Understanding
gcache in Galera
http://www.severalnines.com/blog/understanding-gcache-galera
B.
wsrep_provider_options
https://mariadb.com/kb/en/mariadb/documentation/replication-cluster-multi-master/galera/wsrep_provider_options/