안녕하세요. 제 경험 기준으로 말씀드리자면 아직 DB서버를 docker에 구성해서 서비스를 하는 건 시기상조라고 말씀드리고 싶습니다. 물론 제 경험 기준이긴 하지만 아직까지 제가 다녔던 회사에서도 db를 docker기반에서 서비스했던 적은 없었고 제 주변의 동료들을 봐도 그런 곳은 아직 없었습니다. 다만 빠르게 테스트를 해볼 수 있는 환경을 구성하는 경우 docker기반에서 준비하는 것이 빠르게 구성할 수 있는 장점이 될 수 있을 거 같습니다. "DB이외에 많은 다른 서비스들이 docker기반의 환경에서 구성되고 서비스되는 상황을 보면서 db도 하나의 SW 인데 왜 db는 안될까?" 라는 생각이 든다거나 "db를 docker기반에서 구성한다면 어떤 점들이 필요하고 어떤 것들이 테스트되어야 할까?" 와 같이 기술적인 호기심 같은 것이 생겼을때 그런 것들을 해소하기 위한 목적이나 테스트의 목적으로 사용해 보시는 건 docker 기반의 환경을 이해하는 데 큰 도움이 될 수 있을 거라고 생각합니다. docker기반의 환경에서는 아직이지만 vm을 이용해서 DB서버를 구성하고 서비스하는 것은 사례도 많고 Public cloud에서도 많이 사용되고 있는 기술입니다.
안녕하세요. -h 옵션은 수행되는 docker의 hostname을 지정해 주는 옵션입니다. --hostname , -h Container host name 상세 옵션은 아래 페이지에서 확인하실 수 있습니다. https://docs.docker.com/engine/reference/commandline/run/
안녕하세요. 제가 테스트했던 환경은 아래 cenos7 이미지를 이용한 환경이었습니다. 혹시 가능하시다면 위 이미지를 이용해서 테스트 해보시기 바랍니다. 말씀하신 amazon linux 이미지로는 테스트 해보진 않았는데. 시간이 되는대로 해당 이미지로도 테스트 해보고 다시 말씀드릴께요.
안녕하세요. 혹시 아래와 같이 yum search 결과가 어떻게 나오나요? $ yum search gluster7 Loaded plugins: fastestmirror Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast Determining fastest mirrors * base: download.cf.centos.org * centos-gluster7: download.cf.centos.org * extras: download.cf.centos.org * updates: download.cf.centos.org ======================================================================================================== N/S matched: gluster7 ======================================================================================================== centos-release-gluster7.noarch : Gluster 7 packages from the CentOS Storage SIG repository Name and summary matches only, use "search all" for everything.
안녕하세요. 공유해 주신 메세지 내용으로 보면 외부망하고 연결이 안되서 발생하는 문제인 걸로 보이는데요. 혹시 테스트하는 서버에서 아래와 같이 외부 서비스에 대해서 ping이 되는 상태인가요? $ ping www.google.com PING www.google.com (172.217.175.36) 56(84) bytes of data. 64 bytes from nrt20s19-in-f4.1e100.net (172.217.175.36): icmp_seq=1 ttl=45 time=34.3 ms 64 bytes from nrt20s19-in-f4.1e100.net (172.217.175.36): icmp_seq=2 ttl=45 time=33.9 ms $ ping download.docker.com PING d2h67oheeuigaw.cloudfront.net (54.192.175.35) 56(84) bytes of data. 64 bytes from server-54-192-175-35.icn55.r.cloudfront.net (54.192.175.35): icmp_seq=1 ttl=240 time=4.52 ms 64 bytes from server-54-192-175-35.icn55.r.cloudfront.net (54.192.175.35): icmp_seq=2 ttl=240 time=4.14 ms 64 bytes from server-54-192-175-35.icn55.r.cloudfront.net (54.192.175.35): icmp_seq=3 ttl=240 time=4.04 ms 64 bytes from server-54-192-175-35.icn55.r.cloudfront.net (54.192.175.35): icmp_seq=4 ttl=240 time=4.09 ms 64 bytes from server-54-192-175-35.icn55.r.cloudfront.net (54.192.175.35): icmp_seq=5 ttl=240 time=4.02 ms
안녕하세요. 올려주신 내용을 보니 Yum repo 설정이 먼가 다르게 세팅이 되어 있는 듯 합니다. 제가 테스트했을 때 참조하는 repo url과 사용하시는 yum repo url이 달라서 필요한 패키지를 가져오지 못하고 있는 상황으로 보입니다. 혹시 아래 url에 있는 내용이 도움이 될 수도 있을 거 같아 공유드립니다. https://linuxhostsupport.com/blog/how-to-set-up-and-use-yum-repositories-on-centos-7/
안녕하세요. 다양한 시스템 장애에 대해서 문의해 주셨는데요. 말씀하신 것처럼 시스템의 장애는 종류도 다양하고 이에 따라 처리/대응 방식도 달라질 수 있습니다. DBA의 관점에서 볼 수 있는 장애는 대략적으로 아래와 같이 구분 해볼 수 있겠는데요. HW 장애(DB서버의 문제) DB서버에 하드웨어적인 문제가 생겨서 서비스가 불가한 경우 보통은 부품의 교체나 최악의 경우 서버의 교체가 필요할 수 있기 때문에 Master 서버의 장애가 발생한 경우는 Slave로 빠르게 Fail over를 해주고 문제가된 서버를 교체해서 데이터를 복구한 후 변경된 Master의 Slave로 다시 추가해 줍니다. SW 장애(DBMS SW의 문제) MySQL 자체의 문제(버그)로 서비스가 불가한 경우 원인을 빠르게 찾아서 해결할 수 있으면 좋겠지만 그렇지 못한 경우는 빠른 서비스 복구를 위해서 문제가 되는 Master 를 Slave로 Failover하고 기존 Master의 SW적인 문제를 해결한 후에 데이터를 복구해서 변경된 Master의 Slave로 다시 추가해 줍니다. Network 장애(App서버와 DB서버간의 중단 or Master와 Slave사이의 중단) Network 장애인 경우는 좀 더 다양한 케이스가 있을 거 같은데요. App-Master 간의 문제가 있고 App-Slave간에는 문제가 없는 경우 역시 Master를 failover해서 연결이 가능한 Slave를 Master로 승격시켜서 서비스를 지속시킬 수 있습니다. App-모든DB서버 간에 네트워크 연결이 불가능한 경우는 DB레벨에서 조치할 수 있는 게 없고 네트워크 엔지니어를 통해서 네트워크가 복구될 때까지 기다리는 방법밖에 없을 거 같습니다. 이외에도 더 다양한 케이스가 있을 수 있겠지만 일단 쉽게 떠올릴 수 있는 것들은 이 정도인 거 같습니다. 감사합니다.
