몽고db 데이터를 이전하기 위해 mongodump / mongorestore 로 백업 / 복구 하였다.

그런데, 원래 그런지, 어떤 설정이 있는 것인지 인덱스 가 생성되지 않았다.
> ( 기본은 인덱스가 재 생성 되는 듯 한데, --noIndexRestore 을 주면 인덱스 미생성 )

dump / restore 중에 뭔가 이상이 있는 것인가?  또는 --gzip / --archive 옵션으로 하면 생성이 안되는 것일까?

정확한 이유는 체크해봐야 할 듯 하다.

암튼 그래서 createIndex 로 생성하려하는데, 다음과 같은 에러가 발생하였다.

2020-04-18T06:14:45.987+0000 I  NETWORK  [js] DBClientConnection failed to receive message from 127.0.0.1:27017 - HostUnreachable: Connection closed by peer
command terminated with exit code 137

몽고db - POD 에 접속을 못하는 듯 하다. 좀더 체크해보니 인덱스 생성도중에 mongod POD 가 중지 Down 되어 버린다.

해당 이슈에 대한 검색으로는 특별한 원인을 찾지 못했다. 몽고db 리플리카 셋은 kubernetes(microk8s) 로 세팅하였다.

예상되는 부분은  restore 과정중에 뭔가 데이터가 깨진것이 아닌가 예상이 된다.
그래서 pvc 를 삭제하면, 리플리카 셋이 자동으로 재생성(초기화) 되면서 pod 가 재실행되도록 하였다.

위 조치로 해결이 되었다. (일단 예상은 맞는 듯 하다)

그런데, 근본적인 작업이었던  백업 / 복구 방식이 문제였을까? ( mongodump => mongorestore )

그냥 데이터 디렉토리를 그대로 복사하는 방법으로 해야할까? 좀더 테스트를 해봐야 겠다.

[추가]

좀더 체크해보니, mongorestore 메시지에 이상이 있었다. (몽고db - pod 가 이상이 있어서 인덱스 생성 실패 케이스)

[정상]

2020-04-20T00:16:08.550+0900	restoring indexes for collection test.product from metadata
2020-04-20T00:19:35.655+0900	finished restoring test.product (5522171 documents, 0 failures)
2020-04-20T00:19:35.655+0900	restoring users from archive '/restore/restore/restore-archive.gz'
2020-04-20T00:19:35.881+0900	5522171 document(s) restored successfully. 0 document(s) failed to restore.

[이상있는 경우]
2020-04-18T07:11:49.926+0900	restoring indexes for collection test.product from metadata
2020-04-18T07:12:44.169+0900	finished restoring test.product (5522171 documents, 0 failures)
2020-04-18T07:12:44.170+0900	Failed: test.product: error creating indexes for test.product: createIndex error: connection(mongod-2.mongodb-service:27017[-11]) incomplete read of message header: EOF
2020-04-18T07:12:44.170+0900	5522171 document(s) restored successfully. 0 document(s) failed to restore.

도커는 주로 우분투(리눅스)에서 사용하고 있다. 그래야 제대로된 성능이 나오기 때문이다.

그런데, 개발/테스트 등을 위해 맥os 에서 사용하고자 한다.

설치는 쉽다. https://www.docker.com/products/docker-desktop 에서 다운로드 후 설치하면 된다.

도커를 실행하면, 로그인은 꼭 필수는 아니다.(본인의 도커 이미지등을 docker hub에 등록하고자 하면 필요)
그냥 로컬에서 실행/테스트 할때는 굳이 필요없다.

끝.

도커를 연습해 보고자 한다면, https://docs.docker.com/get-started/ 를 참조한다.

도커 데스크탑 이 쿠버네티스도 지원하는 듯 하다. 설정을 해봤다. 쓸만한 지는 체크해봐야겠다.

우분투 18.04 를 직접 설치하는 경우는 별 문제는 없을 듯 하다.

그런데, 16.04 버전에서 do-release-upgrade 로 업그레이드 한 경우 이상현상이 발생했다.

# nslookup daum.net
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find daum.net: SERVFAIL

위 처럼 도메인 질의 검색이 안된다.

현상은 16.04 에서는 resolvconf 패키지가 관리를 하는데, 18.04 에서는 systemd-resolve 가 관리하도록 바뀐 듯 하다.
(서버 버전과 데스크탑 버전의 차이도 있을 듯 하다.)

systemd-resolved 는 다음의 위치에서 관리한다.

# cat /etc/systemd/resolved.conf 

...
...

[Resolve]
#DNS=
DNS=210.220.163.82
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

이게 올바른 해결책인지는 불확실하다. ( 위 처럼 - 자신의 DNS 를 입력해준다 - IDC 쪽에서 권장하는 것으로 등록)

# systemctl restart systemd-resolved.service
# systemd-resolve --status
Global
         DNS Servers: 210.220.163.82
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

재 실행해 주면 정상 동작한다.

우분투를 18.04 를 본격적(?)으로 사용하고자 한다.(곧 20.04 가 나오지만, 충분히 안정적인 것을 선호한다)

기존 usb 장치(외장 디스크등)를 연결해제할때 보통 umount 하고 그냥 해제했던 것 같다.

[117729.890464] usb 3-4: USB disconnect, device number 4
[117729.892984] sd 6:0:0:0: [sde] Synchronizing SCSI cache
[117730.175652] sd 6:0:0:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

그런데, 위 처럼 - usb disconnect 메시지 뒤에 좀 꺼림직한 에러가 보인다.

그래서 혹시나 해서 몇가지 방법을 해봤다.

위 처럼 "안전하게 드라이브 제거(S)" 로 제거했다.( 윈도우 등도 보통 이렇게 한다 )

메시지를 보니.

[118750.327348] sd 6:0:0:0: [sde] Synchronizing SCSI cache
[118750.596130] sd 6:0:0:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[118750.660631] usb 3-4: USB disconnect, device number 7

메시지는 동일하게 나온다. 차이점은 USB disconnect 가 에러 다음에 나온다.

위 방법이 맞는 듯 하긴 하다. (에러 메시지가 원래 나오는 것인지는 모르겠다)
그외 eject 등도 해봐도 동일.

우분투 18.04 이 기본 gdm 을 사용하는데, 외부 접속(vnc)시 이상현상이 있어 lightdm 으로 바꿨다.

그런데, 바꾸고 나서, 부팅시 자동로그인이 동작을 하지 않는다.

다음의 설정을 확인한다.

/etc/lightdm/lightdm.conf

[SeatDefaults]
autologin-user=USERID
autologin-user-timeout=0
user-session=ubuntu

맨 위의 한 줄만 있을 것이다. (2~3 줄을 추가해준다)

추가후 재부팅해보니 정상동작한다.