2020. 6. 12. 11:13
'컴이야기 > MariaDB' 카테고리의 다른 글
| Maxscale (0) | 2020.06.30 |
|---|---|
| CRUD (0) | 2020.06.12 |
| List of Galera Cluster Status variables (0) | 2020.06.08 |
| sysbench Test (0) | 2020.06.02 |
| Maxscale Fail-Over, Switch-Over, Re-Join (0) | 2020.05.26 |
'갈레라클러스터'에 해당되는 글 5건
- 2020.06.12 Using Galera Replication to Create Geo-distributed Clusters
- 2020.06.08 List of Galera Cluster Status variables
- 2019.06.14 Galera Cluster error
- 2019.03.18 Galera Cluster Replication.
- 2018.11.02 Galera cluster 설치 삽질과정 (완료)
2020. 6. 8. 11:20
https://mariadb.com/kb/en/galera-cluster-status-variables
Galera Cluster Status Variables
Galera Cluster Status Variables
mariadb.com
wsrep_applier_thread_count
설명 :이 유형의 슬레이브 스레드 수를 명확하게하기 위해 현재의 적용자 스레드 수를 저장합니다.
wsrep_apply_oooe
설명 : 병렬화 효율성의 지표 인 쓰기 세트가 순서대로 적용되지 않은 빈도입니다.
wsrep_apply_oool
설명 : 시퀀스 번호가 낮은 쓰기 세트를 시퀀스 번호가 낮은 쓰기 세트보다 먼저 적용하여 쓰기 세트가 느리다는 것을 나타냅니다.
wsrep_apply_window
설명 : 가장 높고 가장 낮은 동시 적용 seqno 사이의 평균 거리.
wsrep_cert_deps_distance
설명 : 병렬로 적용 할 수있는 가장 높은 시퀀스 번호와 가장 낮은 시퀀스 번호 사이의 평균 거리 또는 가능한 병렬화 수준.
....
'컴이야기 > MariaDB' 카테고리의 다른 글
| CRUD (0) | 2020.06.12 |
|---|---|
| Using Galera Replication to Create Geo-distributed Clusters (0) | 2020.06.12 |
| sysbench Test (0) | 2020.06.02 |
| Maxscale Fail-Over, Switch-Over, Re-Join (0) | 2020.05.26 |
| Maxscale serversize ,weightby (0) | 2020.05.22 |
2019. 6. 14. 13:03
| WSREP_SST: [ERROR] xtrabackup_checkpoints missing, failed innobackupex/SST on donor (20190614 19:30:21.392) WSREP_SST: [ERROR] Cleanup after exit with status:2 (20190614 19:30:21.394) |
MariaDB 버전변경하면서 테스트를 하던 중 Galera Cluster를 새로 구성하면서, 다른 2 node 들이 위와 같은 에러가
발생하면서 DB 구동이 실패가 되었었다.
무슨 문제였는지 알수가 없었다.
wsrep_sst_method 옵션을 변경해도 error 가 발생되면서 DB 구동이 실패가 되었었다.
첫번째 노드의 data가 들어있는 디렉토리를 살펴보면,
innobackup.backup.log 라는 파일이 있다.
다른 노드에서 sst를 요청하면 과정과 결과가 기록이 된다.
| 2019-06-14 19:30:21 140471879198592 [ERROR] InnoDB: Tablespaces for test/t1 have been found in two places; Location 1: SpaceID: 21550 File: ./test/t1.ibd Location 2: SpaceID: 21550 File: /data/test/test/t1.ibd You must delete one of them. 190614 19:30:21 [ERROR] mysqld got signal 6 |
이러한 기록들이 있었다.
저 테이블에 문제가 있었나보다.
실제로 첫번째 node 의 데이터를 mysqldump 로 백업하려했더니 저 테이블때문에 계속 실패했다. 다른 한 테이블도
그래서 제외시켜서 백업했더니 잘 되었었다.
| mysqldump -uroot -predhat --databases test --ignore-table=test.t1 --ignore-table=test.t2 > /mysqldump/test.sql |
결국 첫번째 노드에서 문제있었던 두 테이블을 삭제하니
Galera Cluster도 정상으로 되었다.
'컴이야기 > MariaDB' 카테고리의 다른 글
| wsrep_sst_method with IPv6 (0) | 2019.10.21 |
|---|---|
| Maxscale 2.3.6 (1) | 2019.07.12 |
| Galera Cluster Replication. (0) | 2019.03.18 |
| maxscale 을 사용해보자. [진행중] (0) | 2018.11.07 |
| Galera cluster 설치 삽질과정 (완료) (0) | 2018.11.02 |
2019. 3. 18. 15:01
2개의 Galera Cluster를 만들고, 각 클러스터의 한 노드끼리 서로간의 Replication 설정을 했다.
그러나 왠걸 Replication 설정을 한 노드들끼리의 복제는 되지만, 다른 노드에서 실행하면 클러스터 내부에서만 복제가 되고, 다른 클러스터로는 복제가 되질 않았다.
무엇일까... 찾아보게 되었고,
서로 Replication을 맺어준 노드에서 my.cnf 에
이 옵션값을 선언해 주어야지만 다른 노드에서의 명령도 전달복제가 되었다.
log_slave_updates 의 값을 선언을 해주어야 한다.
log_slave_updates
- Description: If set to
0, the default, updates on a slave received from a master during replication are not logged in the slave's binary log. If set to1, they are. The slave's binary log needs to be enabled for this to have an effect. Set to1if you want to daisy-chain the slaves. - Commandline:
--log-slave-updates - Scope: Global
- Dynamic: No
- Data Type:
boolean - Default Value:
OFF
'컴이야기 > MariaDB' 카테고리의 다른 글
| Maxscale 2.3.6 (1) | 2019.07.12 |
|---|---|
| Galera Cluster error (0) | 2019.06.14 |
| maxscale 을 사용해보자. [진행중] (0) | 2018.11.07 |
| Galera cluster 설치 삽질과정 (완료) (0) | 2018.11.02 |
| xtrabackup 설치해보기 1 - 의존성 리스트 (0) | 2018.10.25 |
2018. 11. 2. 16:12
설치환경은 Centos 1804
설치 DB 는 mariadb 10.3.10 으로 진행했다.
총 3대의 가상머신에서 진행을 하는 중이다.
node 1, 2, 3 이고
IP는 192.168.1.140~142로 할당을 해주었고,
Galera cluster 가 사용하는 포트는 4444, 4567,4568 이기 때문에
OS 방화벽 허용리스트에 포함해주었다.
관련 문서링크
http://galeracluster.com/documentation-webpages/firewallsettings.html
방화벽 포트 확인
|
[root@galera2 ~]# firewall-cmd --list-ports |
MariaDB 10.3.x 부터는 SST에서 xtrabackup-v2를 지원하지 않기 때문에
mariabackup을 사용하기로 정했다.
node 1의
my.cnf 에
아래와 같이 설정을 추가해주었다.
|
[galera] |
그리고 Mariadb 데몬을 실행시켜주었다.
|
/etc/init.d/maria start --wsrep-new-cluster |
그리고 DB에 접속해서
상태를 보았다.
|
MariaDB [(none)]> show status like 'wsrep%'; |
node1 에서는 잘 실행되는 것 같다 .
node2에서
my.cnf에 아래와 같이 추가를 해주었다.
|
[galera] |
DB 구동이 실패했다.
|
[root@galera2 ~]# systemctl start maria |
journalctl 을 이용해보았다.
|
-- Unit maria.service has begun starting up. |
maria.err 에 기록이 되었단다. 열어보자.
|
2018-11-02 10:13:08 0 [Note] WSREP: Read nil XID from storage engines, skipping position init 2018-11-02 10:13:09 0 [Note] WSREP: view(view_id(PRIM,75a27987,4) memb { 2018-11-02 10:13:10 2 [Warning] WSREP: Failed to prepare for incremental state transfer: Local state UUID (00000000-0000-0000-0000-000000000000) does not match group state UUID (07112bf5-dce0-11e8-bd0f-fe56e4bea91e): 1 (Operation not permitted) |
이러한 것들이 기록이 되었다.
그리고 node1에서 이러한 기록이 보인다.
innobackup.backup.log 파일을 열어본다.
|
181102 14:51:08 Connecting to MySQL server host: localhost, user: galera, password: set, port: not set, socket: /tmp/maria.sock |
계정 문제?
이미 계정을 생성해주었고, 모든권한을 주었는데... 엑세스 거부라니...뭘까...
node1에서
mysql 접속한 다음.
drop user galera@localhost;
drop user galera@127.0.0.1;
drop user galera@'%';
를 한다음
다시 생성해보았다.
그리고 node2에서
systemctl start maria
된다....
node3에서 같은 문제가 발생했지만,
node1을 systemctl stop maria를 하여
중지한 다음 my.cnf 에
wsrep_cluster_address="gcomm://" 에 모든 노드의 IP를 추가해준다음
node1에서
systemctl start maria
서비스가 시작되고 갈레라클러스터가 제대로 작동된것을 확인후
node2에서 서비스 중지 후 my.cnf의
wsrep_cluster_address="gcomm://" 부분을 node1과 node3으로 변경해서
서비스를 시작 정상 작동 후 갈레라클러스터도 확인 정상
node3을 시작했더니.... 되더라..
|
MariaDB [(none)]> show status like 'wsrep_%'; |
험난하다 험난해...
가상머신을 다시 만들어서 해봐야겠다.
된다!
'컴이야기 > MariaDB' 카테고리의 다른 글
| Maxscale 2.3.6 (1) | 2019.07.12 |
|---|---|
| Galera Cluster error (0) | 2019.06.14 |
| Galera Cluster Replication. (0) | 2019.03.18 |
| maxscale 을 사용해보자. [진행중] (0) | 2018.11.07 |
| xtrabackup 설치해보기 1 - 의존성 리스트 (0) | 2018.10.25 |