mongomirror를 사용하여 AWS의 MongoDB에서 Atlas로 데이터 가져 오기

관련

MongoDB Atlas의 LiveMigration을 사용할 때의 각서
AWS의 MongoDB를 Atlas로 LiveMigration
NLB에서 TLS 종단을 수행하고 Atlas의 LiveMigration 수행

경위

Atlas 제공 LiveMigration을 사용하면 오류가 발생하는 몇 번이있었습니다.



LiveMigration 측에서 에러가 발생하면 유저적으로는 블랙박스에서 Troubleshooting이나 채팅 지원에서는 해결책을 찾아낼 수 없었기 때문에, mongomirror 를 이용해 데이터를 임포트하기로 했다.

절차

mongomirror를 실행하는 인스턴스 준비

To avoid contention for network and CPU resources, do not run mongomirror on the same hosts that provide your replica set’s mongod instances.

mongomirror must have network access to the source replica set.
mongomirror must have network access to the target cluster.
mongomirror has approximately the same performance impact on your source replica set as a secondary:
For the initial sync stage, the load scales with the size of your data set.
Once an initial sync completes, the load scales with oplog gigabytes used per hour.

EC2의 DB 및 Atlas에 연결할 수 있는 곳이어야 함 = app 서버와 동일한 서브넷에 DB 서버와 동일한 사양으로 인스턴스 생성

mongomirror 설치

mkdir mongomirror_work
cd mongomirror_work

curl https://s3.amazonaws.com/mciuploads/mongomirror/binaries/linux/mongomirror-linux-x86_64-enterprise-amzn64-0.8.0.tgz -o mongomirror-linux-x86_64-enterprise-amzn64-0.8.0.tgz
tar -zxvf mongomirror-linux-x86_64-enterprise-amzn64-0.8.0.tgz


curl https://downloads.mongodb.org/linux/mongodb-shell-linux-x86_64-amazon-4.2.0.tgz -o mongodb-shell-linux-x86_64-amazon-4.2.0.tgz
tar -zxvf mongodb-shell-linux-x86_64-amazon-4.2.0.tgz

소스 측의 DB(EC2)에 마이그레이션용 사용자를 작성한다.

Set up MongoDB user in the source replica set

use admin
db.createUser(
  {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "clusterMonitor", "readAnyDatabase" ]
  }
)

Atlas 측에 AtlasAdmin 권한으로 사용자 만들기

Set up MongoDB user in the target Atlas cluster

여기에서 만든 사용자는 Save as temporary user를 선택합니다.

소통 확인

mongodb-linux-x86_64-amazon-4.2.0/bin/mongo "mongodb+srv://<Atlasのホスト>/admin"  --username <Atlasに作成したユーザー>

mongomirror 시작

참조 htps //w w. s에서 멋지다. 네 t / 몽고 db / 몽고 db ぉ 또는 l-se t ぇ-2019-be stp 등 c 치세 s

nohup mongomirror-linux-x86_64-enterprise-amzn64-0.8.0/bin/mongomirror \
--host <srcのレプリカセット名>/srcのホスト1:27017,srcのホスト2:27017,srcのホスト3:27017 \
--username "<srcに作成した移行用のユーザー>" \
--password "<srcに作成した移行用のユーザーのパスワード>" \
--authenticationDatabase "admin" \
--destination "<Atlas上のレプリカセット名>/<Atlasクラスターのホスト1>:27017,<Atlasクラスターのホスト2>:27017,<Atlasクラスターのホスト3>:27017" \
--destinationUsername "<Atlas側に作成したユーザー>" \
--destinationPassword "<Atlas側に作成したユーザーのパスワード>" \
--httpStatusPort 8000 \
-j 16 > mongomirror.log 2>&1 &

이 때 Atlas의 복제본 세트 이름과 연결 정보를 확인하는 방법은
htps : // / cs. 아 tぁs. 몽고 db. 코 m / 이 m 포 rt / 몽고 미로 r / # 코 py ぇ- r 게 t c ぅ s r ho st
잘 읽으십시오.

연결정보가 잘못되면

2019-10-08T05:27:30.881+0000    Error initializing mongomirror: could not initialize destination connection: could not connect to server: server selection error: server selection timeout
current topology: Type: ReplicaSetNoPrimary
Servers:

같은 오류가 발생하고 mongomirror가 멈 춥니 다.

-j 옵션 정보

collection 복사본의 병렬도를 결정합니다.
numParallelCollections

--numParallelCollections , -j
Default: 4

The number of collections to copy and restore in parallel.

서포트에게 물었을 때,

we recommend this parameter to be in line with the number of CPU cores on the host machine hosting mongomirror. 

라는 것이므로, CPU 사이즈에 맞춘다.
기본값은 4. 아마 LiveMigration도 뒤에서는 mongomirror를 4로 기동하고 있는 것이 아닐까 생각한다.
이번 16으로 하면, LiveMigration에서는 16h 걸려 있던 것이 6h 정도로 단축되었다.

mongomirror 로그를 읽는 방법

initializing ~ initial sync 로그

nohup: ignoring input
mongomirror version: 0.8.0
git version: a5cbb2d5babea8ed87191b31b12ffc6f3a3fa485
Go version: go1.12.4
   os: linux
   arch: amd64
   compiler: gc
2019-10-08T05:31:42.724+0000    Initializing HTTP status service on port 8000
2019-10-08T05:31:42.801+0000    Attempting initial sync from: 10.0.1.17:27017
2019-10-08T05:31:43.015+0000    Creating collection <DB名>.<コレクション名AAA>
2019-10-08T05:31:43.015+0000    Creating collection <DB名>.<コレクション名BBB>
2019-10-08T05:31:43.078+0000    Copying documents to collection <DB名>.<コレクション名AAA>
2019-10-08T05:31:43.116+0000    Copying documents to collection <DB名>.<コレクション名BBB>
2019-10-08T05:31:46.015+0000    [........................]       <DB名>.<コレクション名AAA>   39316/1033602  (3.8%)
2019-10-08T05:31:46.015+0000    [#.......................]       <DB名>.<コレクション名BBB>   50015/1161614  (4.3%)

컬렉션마다의 진척이 인디게이터풍에 3초마다 출력된다.
여기서 J옵션으로 지정한 병렬도가 효과가 온다.

색인 복사

문서 복사가 끝나면 색인 작성이 시작됩니다.

2019-10-08T05:43:32.944+0000    Copied 11043565 documents to <DB名>.<コレクション名AAA>
2019-10-08T05:43:32.944+0000    [########################]  <DB名>.<コレクション名AAA>  11043565/11043565  (100.0%)
2019-10-08T05:43:32.993+0000    Tailing the oplog on the source cluster starting at timestamp: {1570512697 1}
2019-10-08T05:43:32.994+0000    Oplog tailer has shut down. Oplog applier will exit.
2019-10-08T05:43:32.994+0000    Current lag until the end of initial sync: 0s
2019-10-08T05:43:33.032+0000    createIndexes for collection: `<DB名>.<コレクション名AAA>`, finished in 36.390104ms
2019-10-08T05:43:33.032+0000    createIndexes for collection: `<DB名>.<コレクション名BBB>`, finished in 36.834095ms

여기서 주의하고 싶은 것이, createIndexes for collection 의 로그 출력은, index 구축 완료 후에 표시되므로, 큰 컬렉션으로 Index 작성 자체에 몇분 걸리는 것이 있는 경우, 로그의 출력이 멈추어 버린다.
로그 출력이 없는 경우라도 mongomirror의 프로세스는 살아 있으므로 그럴 때는 http서버 기능(후술)으로 현재의 스테이터스를 확인할 수 있으므로 당황하지 않는다.

initial sync ~ oplog sync 로그

문서의 사본, Index의 구축이 끝나면, mongomirror는 oplog sync 상태에 있다.
이 lag 시간이 0s인 경우에 컷오버할 수 있다.

2019-10-08T06:00:48.161+0000    Index builds completed.
2019-10-08T06:00:48.161+0000    Initial sync from 10.0.1.17:27017 completed at oplog timestamp: {{1570513407 1} {1570513407 1}}
2019-10-08T06:00:48.161+0000    Proceeding to tail oplog.
2019-10-08T06:00:48.174+0000    Current lag from source: 17m20s
2019-10-08T06:00:48.174+0000    Tailing the oplog on the source cluster starting at timestamp: {1570513407 1}
2019-10-08T06:00:58.185+0000    Current lag from source: 0s
2019-10-08T06:01:08.175+0000    Current lag from source: 0s

http 서버 기능으로 상태 확인

시작 옵션에서 지정한 --httpStatusPort 8000에 대해 GET 요청을 수행하면 mongomirror 프로세스의 현재 상태를 알 수 있습니다.

curl -X GET http://localhost:8000 | python -m json.tool

{
    "details": {
        "<DB名>.<コレクション名AAA>": {
            "complete": true,
            "createIndexes": 2
        },
        "<DB名>.<コレクション名AAA>": {
            "complete": true,
            "createIndexes": 4
        },
        ....
    },
    "phase": "copying indexes",
    "stage": "initial sync"
}

mongomirror 정지

ps aux | grep mongomirror
kill <pid>

2019-10-08T06:10:28.175+0000    Current lag from source: 0s
2019-10-08T06:10:38.175+0000    Current lag from source: 0s
2019-10-08T06:10:48.130+0000    signal 'terminated' received; attempting to shut down
2019-10-08T06:10:48.130+0000    Quitting...
2019-10-08T06:10:48.131+0000    Current lag from source: 0s
2019-10-08T06:10:49.130+0000    Timestamp file written to /home/ec2-user/mongomirror_work/mongomirror.timestamp.

이 때 작성된 mongomirror.timestamp 는 다음의 mongomirror 실행시에, bookmarkFile 옵션 로서 지정하는 것으로, 계속부터 실행할 수가 있다.
--bookmarkFile 를 지정해 기동했을 때의 로그는 이하와 같은 출력이 된다.

git version: a5cbb2d5babea8ed87191b31b12ffc6f3a3fa485
Go version: go1.12.4
   os: linux
   arch: amd64
   compiler: gc
2019-10-10T01:51:16.723+0000    Initializing HTTP status service on port 8000
2019-10-10T01:51:16.791+0000    Read timestamp from bookmark file: {1570671675 1}
2019-10-10T01:51:16.791+0000    Proceeding to tail oplog.
2019-10-10T01:51:16.792+0000    Current lag from source: 10m0s
2019-10-10T01:51:16.792+0000    Tailing the oplog on the source cluster starting at timestamp: {1570671675 1}
2019-10-10T01:51:26.803+0000    Current lag from source: 0s
2019-10-10T01:51:36.793+0000    Current lag from source: 0s