PlanB의 백엔드 엔지니어링

데이터베이스는 항상 백업과 복구를 할 일이 생기기 마련입니다. MongoDB에서는 dump와 restore를 위해 mongodump와 mongorestore를 사용합니다.

mongodump

MongoDB path가 환경 변수로 등록되어 있거나, 아니라면 MongoDB가 설치된 bin 디렉토리에 가서 mongodump 명령어를 사용해 MongoDB 전체나 특정 DB, 또는 컬렉션을 BSON 형태로 덤프받을 수 있습니다.

> mongodump -h localhost
2018-03-23T10:53:19.338+0900    writing admin.system.version to
2018-03-23T10:53:19.339+0900    done dumping admin.system.version (1 document)

...

2018-03-23T10:53:19.351+0900    done dumping dms.refresh_token (2232 documents)

위처럼 mongodump 명령어를 사용하면 MongoDB에 접속해서 데이터베이스의 덤프를 dump라는 폴더 아래에 내려받게 됩니다. DB별로 디렉토리가 하나씩 생기고, 그 아래에 컬렉션 별로 BSON 파일이 생성됩니다. -d 또는 --db, -c 또는 --collection 옵션을 통해 특정 데이터베이스, 또는 특정 데이터베이스의 컬렉션만 덤프받을 수도 있습니다.

> mongodump -h localhost -d test_db
2018-03-23T10:53:53.715+0900    writing dms.refresh_token to
2018-03-23T10:53:53.715+0900    writing dms.notice to

...

2018-03-23T10:53:53.725+0900    done dumping dms.refresh_token (2232 documents)

> mongodump -d dms -c refresh_token
2018-03-23T10:54:33.638+0900    writing dms.refresh_token to
2018-03-23T10:54:33.648+0900    done dumping dms.refresh_token (2232 documents)

다른 옵션들은 mongodump 매뉴얼이나 mongodump --help 커맨드를 이용해 알아볼 수 있습니다.

mongorestore

mongodump를 이용하여 BSON 파일을 얻어냈다면 같은 디렉토리의 mongorestore를 이용해 데이터베이스를 복구할 수 있습니다.

> mongorestore -h localhost ~/dump/

이 경우 mongorestore는 /dump 디렉토리 하위에 있는 데이터베이스별 디렉토리를 순회하며, BSON 파일을 통해 데이터베이스를 복구합니다. 특정 데이터베이스만 복구하려면 -d 옵션과 함께 mongorestore를 수행합니다.

> mongorestore -h localhost -d dms ~/dump/dms/

백업 디렉토리의 하위에 있는 해당 데이터베이스의 백업 디렉토리를 기입하여야 합니다. mongorestore는 단순히 insert만 있기 때문에, 겹치는 데이터가 있더라도 해당 값을 덮어쓰지 않습니다. 복구 전에 존재하는 컬렉션을 없애고 싶다면 --drop 옵션을 사용합니다.

> mongorestore -h localhost -d dms --drop ~/dump/dms/

다른 옵션들은 mongodump 매뉴얼이나 mongorestore --help 커맨드를 이용해 알아볼 수 있습니다.

Request body search에서 모든 leaf query는 context가 존재하며, 이는 query context 또는 filter context로 나뉩니다.

• Query context : '이 document가 쿼리와 얼마나 잘 일치하는가?'에 대해 응답합니다. 일치하는 정도를 결정하는 것 외에도, 다른 document에 비해 document가 얼마나 잘 일치하는지를 나타내는 _score도 함께 계산합니다.
• Filter context : '이 document가 쿼리와 일치하는가?'에 대해 응답합니다. Query context의 결과물이 _score였다면, 여기서는 bool(true/false)이 결과물입니다. SQL에서의 WHERE 절과 유사하다고 볼 수 있습니다. '타임스탬프가 2015년과 2016년 사이의 범위인가?', '상태가 "published"인가?' 등과 같은 쿼리가 filter context에 속합니다. 자주 사용되는 필터는 성능을 높이기 위해 ElasticSearch에 의해 자동으로 캐싱됩니다.

아래는 query context와 filter context에 사용되는 쿼리의 예입니다.

위의 쿼리를 해석하면, 아래와 같습니다.

• "title"이 "Search"라는 단어를 포함하고,
• "content"가 "ElasticSearch"라는 단어를 포함하고 있어야 하며,
• "status"가 정확히 "published"이고,
• "publish_date"가 2015년 1월 1일과 같거나 그 미래여야 합니다.

위 두개의 쿼리는 query context에 속하고, 아래 두개의 쿼리는 filter context에 속합니다. 그리고 위 쿼리에서 사용한 bool, must, filter는 모두 compound query기 때문에 별도의 context가 없습니다.

git pull에서 나는 충돌은 생각보다 쉽게 해결 가능했습니다. conflict난 파일을 즉시 확인할 수 있었으니까요. 그러나 pull request에서 나는 충돌은 꽤 막막합니다. 대체적으로 아래와 같은 상황입니다.

• master 브랜치에서 feature_x와 feature_y 브랜치를 동시에 생성
• feature_x는 README.md를 수정하여 master에 merge가 완료됨
• feature_y가 README.md를 수정하여 master에 pull request하는 순간 conflict 발생

동일한 저장소에서 브랜치 간 conflict

생각보다 간단합니다. Pull request 타겟 브랜치의 변경 사항을, Pull request source 브랜치로 가져오면 됩니다. 예를 들어, feature_y 브랜치에서 master 브랜치에 대해 pull request하는 과정에서 conflict가 났다면, feature_y 브랜치에서 master 브랜치의 변경 사항을 가져오는 것입니다.

> git checkout feature_y
> git pull origin master

그럼 현재 브랜치에서 conflict가 발생되고, 해당 충돌을 해결한 후 다시 commit - push하면 pull request에서 충돌이 발생하지 않습니다.

Fork된 저장소와 upstream 브랜치 간 conflict

이 상황은 해결법을 떠올리기 힘듭니다. 사실 위와 동일하게 해결하는데, 이번에는 git의 remote라는 개념을 활용합니다. 예를 들어, origin의 feature_y 브랜치에서 upstream의 master 브랜치에 대해 pull request하는 과정에서 conflict가 났다면, upstream/master 브랜치의 변경 사항을 feature_y 브랜치로 가져오면 됩니다.

> git checkout feature_y
> git remote add upstream [https://upstream_url.git]
> git pull upstream master

위처럼 현재 브랜치에서 conflict가 발생되고, 위처럼 충돌을 해결하고 나면 pull request에선 충돌이 발생하지 않습니다.