단일 인스턴스 Mongo를 복제본 세트로 업그레이드

배경

단문 메시지 사업이기 때문에 회사의 사업이 증가함에 따라 데이터베이스에 대한 부담도 증가하고 있습니다. 현재 데이터 양은 약 70 억입니다. Mongo는 1 주일 이내에만 데이터를 저장하고 데이터 양은 거의 1 억에 달합니다. 이전에는 비용을 절감하고 싶었 기 때문에 항상 단일 인스턴스였습니다. 접속 고객이 증가함에 따라 매일 보내는 문자 메시지도 대폭 증가하기 시작했습니다. 가장 걱정스러운 것은 휴일을 보내는 것인데, 몽고가 갑자기 전화를 끊으면 걱정이 됐어요 하하! 그것은 죽음 지향적 인 프로그래밍입니다.

얽힌

몇 번의 논의 끝에 마침내 Mongo 복제본 세트 읽기-쓰기 분리 처리를 사용하기로 결정했기 때문에 서비스 변환이 시작되었습니다.

준비된

여러 서버 (192.168.0.101, 192.168.0.102, 192.168.0.103, 192.168.0.104)가 Mongo 머신에 배포되었습니다. Mongo 참조 설치 : Linux install Mongo
머신 설명 : 두 개의 Mongo는 슬레이브 라이브러리이며, 하나는 투표 노드 만 담당하고 데이터 노드는 처리하지 않습니다 (192.168.0.104).

업그레이드

키 파일

키 파일 인증을 통해 복제본 세트 의 각 mongod 인스턴스는 키 파일의 내용을 공유 비밀번호로 사용하여 배치의 다른 구성원을 인증합니다. 올바른 키 파일이있는 mongod 인스턴스 만 복제본 세트에 참여할 수 있습니다. 키 파일의 내용 길이는 6 자에서 1024 자 사이 여야하며 복제 세트의 모든 구성원이 동일해야합니다.

openssl rand -base64 756 > /key/mongodb-keyfile
chmod 400 /key/mongodb-keyfile

복제 세트의 구성원을 호스팅하는 각 서버에 키 파일을 복사하십시오. mongod 인스턴스를 실행 하는 사용자가 파일의 소유자이고 키 파일에 액세스 할 수 있는지 확인하십시오 .

각 서비스의 Mongo 구성 수정

먼저 단일 인스턴스 Mongo를 중지하고 (명령 : systemctl stop mongod) mongo 구성 파일 /etc/mongod.conf에서 net, 보안 및 복제 구성 정보를 수정합니다.

net:
  port: 27017
  bindIp: 0.0.0.0  # 允许所有ip远程连接Mongo

security:
  authorization: enabled # 用户只能访问已为其授予特权的数据库资源和操作。
  keyFile: /key/mongodb-keyfile # 秘钥文件路径

replication:
  replSetName: "S1" # 副本集名称
  enableMajorityReadConcern: false # 以为有投票节点，禁用该功能以防止存储高速缓存压力使部署无法固定。

Mongo 시작

명령 (systemctl start mongo)을 사용하여 mongo (마스터 노드가되기를 희망하는 Mongo)를 입력하고 처리 된 복제 세트 구성을 실행합니다.

rs.initiate( {
   _id : "s1",
   members: [
      { _id: 0, host: "192.168.0.101:27017" },
      { _id: 1, host: "192.168.0.102:27017" },
      { _id: 2, host: "192.168.0.103:27017" },
      { _id: 3, host: "192.168.0.104:27017",arbiterOnly:true },
   ]
})

복제 세트 구성 확인, 업그레이드 완료 (원격 연결 확인)

rs.conf();

복제본 세트에 임시 구성원 추가

rs.add( { host: "192.168.0.105:27017", priority: 0, votes: 0 } )

노트 :

새로 추가 된 보조 노드의 투표 및 우선 순위 설정이 0보다 큰 경우 초기 동기화 중에 보조 노드가 읽기를 제공 할 수 없거나 데이터가 여전히 일관성이 없어 기본 노드가 될 수없는 경우에도 보조 노드는 여전히 투표 권한이있는 구성원으로 계산됩니다. .

이로 인해 대부분의 투표 회원이 온라인 상태이지만 주요 회원을 선출 할 수없는 상황이 발생할 수 있습니다. 이러한 상황을 방지하려면 우선 순위 : 0 및 votes : 0을 사용하여 새 보조 서버를 먼저 추가하십시오. 그런 다음 구성원이 SECONDARY 상태로 전환되면 rs.reconfig ()를 사용하여 우선 순위와 투표 를 업데이트합니다.

경우 구성 문서 리턴 하여 rs.conf ()가 다섯 번째 요소 부재 그것을 우선 순위 및 로그인을 업데이트 배열 , 동작의 다음 시퀀스를 사용하여192.168.0.105:270171

var cfg = rs.conf();
cfg.members[4].priority = 1
cfg.members[4].votes = 1
rs.reconfig(cfg)

비정상적인 문제

1. 비밀 키 파일 읽기 권한이 비정상적으로 실패하여 시작 실패

{"t":{"$date":"2020-10-17T14:38:26.085+08:00"},"s":"I",  "c":"ACCESS",   "id":20254,   "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"Error reading file /key/mongodb-keyfile: Permission denied"}}}

해결책:

권한이 너무 작지 않은지 고민하던 중 777 권한을 직접 승인 한 결과 파일 권한이 너무 열려 있다는 오류가 직접보고되어 권한 프로그램이 직접 확장되었습니다.

1. 기본적으로 MongoDB mongod는 사용자 계정으로 실행됩니다. 생성 후 디렉토리의 소유자 및 그룹을 다음으로 설정합니다 mongod.

sudo chown -R mongod:mongod /key/mongodb-keyfile

2. 공식 문서에 따르면 파일 그룹을 수정하는 한 성공적으로 파일을 읽을 수 있지만 안타깝게도 여전히 파일을 읽지 못하며 다양한 검색 자료를 통해 Rad Hat linux 공식 디렉토리 권한 파일에서 최종 해결책을 찾을 수 있습니다. SELinux 정책 구성 변경

chcon system_u:object_r:mongod_var_lib_t:s0 /key/mongodb-keyfile

2. 비밀 키 파일을 읽는 동안 너무 열린 오류

해결책:

1. UNIX 시스템에서는 키 파일에 그룹 또는 월드 권한이 없어야합니다. Windows 시스템에서는 키 파일 권한이 확인되지 않습니다. 따라서 읽기 권한 만 열면됩니다. 권한이 너무 크면 안됩니다.

chmod 400 /key/mongodb-keyfile

참조 문서:

https://docs.mongodb.com/manual/

https://stackoverflow.com/questions/28251531/permission-denied-to-read-file-owned-by-user

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/chap-security-enhanced_linux-selinux_contexts