작성
·
29
0
안녕하세요, 강의내용 중 질문이 있어 글 올립니다.
orchestrator와 proxysql로 auto failover 구성시
db001(master), db002(slave1), db003(slave2)
상태에서
db001을 종료(docker stop db001)하여
db002(master), db003(slave) 상태가 되고
db001을 다시 실행(docker start db001)하게 되면,
강의 내용 처럼
db001 접속후 read_only 설정, db002를 master로 지정하는 slave작업을 하기전에
app_test_insert.sh 로 테스트 해보면
db001, db002 양쪽으로 저장이 됩니다.
이걸 막을 방법이 없나요?
실제 운영시 사용자가 없는 시점에서 db001을 실행해야되는건지
아니면 docker-compose에서 db설정 파일인 conf를 호스트 파일로 마운트 하고
호스트에 있는 파일을 수정후 db001을 실행해야될까요?
답변 1
0
안녕하세요, 씨에이비시스템님, 인프런 AI 인턴입니다.
질문해 주신 내용을 기반으로 보았을 때, 발생하는 문제는 장애 복구 후 미처리된 설정으로 인해 db001
이 실행되면서 예상치 못한 데이터베이스 상태가 되는 것으로 보입니다.
Read-Only 설정 미리 적용: db001
이 다시 시작될 때 자동으로 read_only
상태로 시작하도록 설정할 수 있습니다. 이는 MySQL 설정 파일(my.cnf 또는 my.ini)에서 read_only
설정을 미리 적용해 두는 방법이 있습니다. 이렇게 하면 db001
이 시작될 때 기본적으로 read_only
모드로 실행됩니다.
정확한 동작 시퀀스 확보: 사용자가 없는 시점에 작업을 수행하는 것은 실제 운영 시에도 일반적인 권장 사항입니다. 실행 순서(순차적으로 db001
을 read-only로 설정하고 그 후 db002
를 master로 지정)를 철저히 따르는 것도 중요합니다.
호스트 파일로 설정 마운트: Docker 환경에서는 컨테이너를 시작할 때 설정 파일을 호스트에서 마운트하여 설정의 변경을 용이하게 하는 것이 좋습니다. 그렇게 하면 컨테이너 내부의 설정을 직접 수정하는 번거로움을 피할 수 있습니다.
강의 내 내용과 관련하여 구체적인 적용 방법에 대한 질문이 있으실 경우, 강의 자료 내에서 강사님의 설명을 재확인하거나 추가적인 예제를 참조하실 수도 있습니다.
여기에서 다룬 다양한 해결 방법과 관련하여 더 자세한 내용이 필요하시다면 추가 질문을 주시면 곧 강사님께서 응답을 드릴 것입니다. 아래 링크에서 추가로 관련된 내용을 찾을 수도 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.