config server가 replica set이 아닌 3.0 이전의 3 mirrored 방식인 상황에서 아래와 같은 에러가 발생.

2019-12-10T14:44:46.542+0900 W SHARDING config servers config01:27019 and config02:27019 differ
2019-12-10T14:44:46.542+0900 E SHARDING could not verify that config servers are in sync :: caused by :: config servers config01:27019 and config02:27019 differ: { chunks: "f2dd252d097395baf36f2fbe79777293", collections: "39be6c1c9894748e0c30ad0c121b353a", databases: "466491f5ebb81884585394c039028393", shards: "a37227f62ddb33060a116c884ec66640", version: "da7c914b6c97280f13f1ce34a1548e52" } vs { chunks: "53e0589eaec717a4ac5bcf734c13d71a",collections: "39be6c1c9894748e0c30ad0c121b353a", databases: "466491f5ebb81884585394c039028393", shards: "a37227f62ddb33060a116c884ec66640", version: "da7c914b6c97280f13f1ce34a1548e52" }

 

config server들 간에 sync가 맞지 않아 chunk split과 migration이 일어나지 않는 심각한 상황.

 

기본적인 해결책은,

config server 3개 중 정상인 config server를 알아낸 후, 비정상인 config server의 데이터를 정상인 config server의 데이터로 교체하는 것.

 

config server는 다운되더라도 read/write는 문제가 없으므로 live 상태에서 해결이 가능.

 

우선 정상인 config server를 알아내야 하는데 여러가지 방법이 있으나 각 config server에 접속해서 chunks의 count()를 비교해보는 방법이 있음.

// config01
[root@config01]# $MONGO_BIN/mongo localhost:27019

MongoDB shell version: 3.0.12
connecting to: localhost:27019/test

// 인증
> use admin
switched to db admin
> db.auth(ID, PW)
1
// chunks count
configsvr> use config
switched to db config
configsvr> db.chunks.count()
100

 

이걸 각 config server마다 해보면 각각 다른 chunks 수가 나올텐데,

그냥 기본적으로 chunks.count()가 제일 높은 config server가 정상이라고 가정하면 무리가 없음.

여기선 config01의 chunks.count()가 100이고 나머지 config02, config03의 chunks.count()가 85라고 가정한다면,

config01만 정상이고 나머지 2개의 서버는 비정상.

 

이제 아래와 같은 방법으로 config01의 data를 config02, config03 서버의 data와 교체하면 됨.

// 1. config01 shutdown
[root@config01]# $MONGO_BIN/mongo localhost:27019

// 인증
> use admin
> db.auth(ID, PW)
1

// shutdown
configsvr> db.shutdown()
configsvr> quit()



// 2. config01 data 압축 (및 백업)
[root@config01]# tar cvfz config01.tgz $MONGO_DATA/config01/*



// 3. config01 data를 config02, config03에 전송
[root@config01]# scp ./config01.tgz root@config02:/root/
[root@config01]# scp ./config01.tgz root@config03:/root/



// 4. config01 재시작
[root@config01]# $MONGO_BIN/mongod -f $MONGO_CONF/config01.cfg



// 5. config02 shutdown
[root@config02]# $MONGO_BIN/mongo localhost:27019

// 인증
> use admin
> db.auth(ID, PW)
1

// shutdown
configsvr> db.shutdown()
configsvr> quit()



// 6. 원본 data 백업 및 config01 data로 교체
[root@config02]# tar cvfz config02.tgz $MONGO_DATA/config02/*
[root@config02]# rm -rf $MONGO_DATA/config02/*
[root@config02]# cp /root/config01.tgz $MONGO_DATA/config02/
[root@config02]# cd $MONGO_DATA/config02
[root@config02]# tar xvfz ./config01.tgz



// 7. config02 재시작
[root@config02]# $MONGO_BIN/mongod -f $MONGO_CONF/config02.cfg



// 8. config02도 위의 5번 ~ 7번의 과정을 동일하게 수행



// 9. 모든 mongos에 접속해서 config data flush -> db.adminCommand('flushRouterConfig') 실행

// 이제 chunk split, migration이 일어나기 시작하고 에러 로그는 생기지 않음

 

 

원인도 불명확하고 정확한 해결법인지도 애매하지만, 여하튼 chunk split, migration 은 해결됨.

 

 

Posted by bloodguy

댓글을 달아 주세요