詳細検索

MyISAM과 MySQL이 혼합된 환경 백업에 관한 노트

아바타
글쓴이 komi

MyISAM과 MySQL이 혼합된 환경 백업에 관한 노트
日本語에서 번역 • 원문 보기

이 글은 오래된 문서임을 참고해 주세요
안녕하세요. 코미야입니다.

이 서비스에서는 회사가 사용하는 MyISAM 테이블을 혼합하여
mysqldump 백업이 실패하고 콜드 백업을 했지만 결과가 일관되지 않았던 사례에 대해 상담한 적이 있습니다.
이 이야기를 기록하고 주의사항을 요약하고자 합니다.
 (예전에 가볍게 말했던 기억이 나서 모두가 알고 있다고 생각했지만, 이해의 편리함과 전달 능력,
 저와 다른 사람들의 mysql에 대한 애정이 약간 다르다는 인식을 못 했던 것 같습니다.
 문제는 일어나고, 실패는 도전의 신호이자 성공의 원천이지만, 같은 일을 반복하지 않도록 해야 합니다. )

중요한 것은 마스터와 슬레이브 간의 데이터의 일관성입니다.
 다시 말해,
 ⇒ 백업 타겟은 절대 업데이트되어서는 안 됩니다.
 ⇒ 백업 획득 시점의 위치와 이진 로그 파일 이름은 명확해야 합니다.
 정말 중요해요.
 혼합형 MyISAM 환경에서는 조심하지 않으면 일관성이 없을 수 있습니다.
 만약 불일치가 있다면, 예를 들어 구매했어야 할 콘텐츠가 구매되지 않는 등 매우 어려울 것입니다.
 InnoDB만 사용한다면 ---single-transaction을 추가하면 불일치 걱정할 필요가 없습니다.

·mysqldump 실패 원인

mysqldump: 오류 1317: 테이블을 덤프할 때 쿼리 실행이 중단됨

이 오류는 다음과 같이 발생합니다
이 코드는 mysqldump에서 데이터를 읽다가 쿼리가 중단될 때 나옵니다. Ctrl + C 또는 킬로 스레드가 종료되었습니다.
(트위터에서 들었어요.) 감사합니다.

그 후 일관성을 위해 마스터에서 데이터를 mysqldump로 가져왔습니다.
당시 슬레이브에서 복제를 중단하고 업데이트 없이 사용하는 방법도 일관성 문제를 일으켰습니다.
(MyISAM이 혼합 환경임에도 불구하고, 읽기 잠금 상태로 테이블을 플러시하라고; 저는 하지 않았습니다)

MyISAM과 혼합된 환경의 경우, 트랜잭션을 사용할 수 없으므로
복제 중지 또는 공유 잠금은 업데이트 중지가 필요합니다.

예:
읽기 잠금 기능이 있는 플러시 테이블; 
잠 모드나 동기화가 끝날 때까지 기다려 주세요 (반드시 업데이트를 중단하세요)
로깅 위치와 파일명
mysqldump
테이블 잠금 해제; 

특히, 쿼리가 인터럽트되지 않는다는 지적이 있는데(인터럽트와의 일관성이 엉망입니다), 저는 그 부분을 잘 이해하지 못합니다.
업데이트를 하지 않으려 하면 중단이 없으니, 이를 해결하는 유일한 방법은 업데이트를 멈추는 것이라고 생각합니다.

·콜드 백업 후 마스터와 슬레이브 간 불일치 원인

다음과 같은 오류가 발생해 복제를 시작할 수 없었습니다

Last_IO_Error: 바이너리 로그에서 데이터를 읽을 때 마스터로부터 치명적인 오류 1236이 발생했습니다: '바이너리 로그 인덱스 파일에서 첫 번째 로그 파일 이름을 찾을 수 없음' 

업데이트는 원래 마스터를 시작한 직후 바로 시작된 시점 사이에 나왔습니다; (다른 생각이 없어서 추측입니다)
REP는 리셋 마스터 후 초기 위치에서 시작합니다.
 주인과 노예 사이에 테이블 수가 달랐던 것으로 보입니다.
마스터를 리셋하면; 그렇게 하면 마스터 바이너리 로그가 데이터 파일에 플러시되어 사라집니다.
이진 로그를 보는 슬레이브는 삭제되어 읽을 수 없으니,
노예가 있는 마스터와 함께 플레이할 때는 조심하세요.

·대응책

MyISAM 테이블이 업데이트되고 mysqldump가 실패하지 않도록 다음 조치를 권장합니다:

  1. 읽기 잠금 상태로 테이블을 플러시 처리하기;) (MyISAM이 혼합 모드일 경우, --opt만으로 잠기는 것은 전체적으로 일관성이 없습니다)
     (슬레이브 머신에서 복제를 중단하고 덤프하면 업데이트될 가능성이 없으므로 공유를 잠글 필요가 없습니다.)
  2. 마스터 상태 표시; 업데이트되지 않았는지 확인하기
     (공유 잠금은 실행 쿼리를 기다리는 등 몇 초만 기다리면 좋지 않을 수 있습니다
     http://d.hatena.ne.jp/jitsu102/20110423/1303553133),
  3. iptables 내 블록 3306 (iptables -A INPUT -p tcp --dport 3306 -j DROP) 및
     (또는 재시작할 수 있다면 my.cnf에 skip-networking을 작성하고 반영하세요)
  4. 마스터 상태 표시; 업데이트되지 않았는지 확인하려고 여러 번 눌렀습니다.
  5. mysqldump와 함께 bkup을 사용하세요. 그렇게 하면 신뢰성 있게 업데이트되지 않아 불일치를 방지할 수 있습니다.

또는 콜드 백업 시스템으로.

・복제 목적으로 데이터를 사용할 때 위치 확인 방법
 복제 용도가 있다면 바이너리 로그 파일과 위치를 반드시 확인해야 합니다.

 mysqldump (마스터에서 가져옴),
  --master-data를 쓰면 CHANGE MASTER TO 구문이 덤프 파일 시작 부분에 쓰이므로, 거기서부터 rep을 시작할 수 있습니다.

 mysqldump (슬레이브에서 가져옴),
  5.5 이후부터는 다음과 같은 유용한 옵션을 사용할 수 있습니다:
  --dump-slave: 슬레이브에서 덤프를 가져온다면, 슬레이브가 CHANGE MASTER로 참조하는 마스터의 정보를 덤프에 포함시킵니다.
  --apply-slave-statements: CHANGE MASTER 앞뒤에 STOP SLALLOW와 START SLAVE 명령을 추가하세요.
  --include-master-host-port: CHANGE MASTER 명령어에 마스터의 호스트명과 포트를 포함하세요.
  이전 버전에서는 복제가 중단된 위치를 기록하는 것이 좋았을 것입니다(오류 로그에도 포함되어야 합니다).

 콜드 백업(마스터에서 제공)의 경우,
  압축 해제된 데이터 디렉터리에서 mysqlbinlog와 tail을 함께 보면 이진 로그 파일명과 위치를 찾을 수 있습니다.
 슬레이브에서 콜드 백업할 때는 위치 정보를 오류 로그에 기록해야 할 것입니다. (확인해 주세요)

  • 마스터 리셋; 마스터를 누르면 슬레이브에서 복제하려는 데이터가 사라지므로
     미리 백업한 이후로 업데이트된 적이 없는지 반드시 확인해야 합니다.

·일관성을 확인하기 위해 추천하고 싶은 것들
 언제 업데이트될지 모르고, 멈추기 어려운지, 완전히 이해하지 못하는지 모르겠다면,
 마스터 상태를 표시; 데이터 일관성을 위해 여러 번 확인하는 것이 좋습니다.
 (마스터에서 mysqldump가 낭비될 때 서비스 다운타임을 의미합니다.) )
 그 후에는 네트워크에서 차단하는 것이 빠른 것 같습니다.
 전역 읽기_only=1로 설정하는 의견이 있을 수 있지만, SUPER 권한이 있는 사용자는 이를 업데이트할 수 있으니 주의하세요.

・InnoDB 전용과 MyISAM 세부 정보를 혼합할 때 사용하는 Mysqldump 옵션
InnoDB:
--모든 데이터베이스 --인용 이름들 --opt --단일 트랜잭션 --master-data=2 --hex-blob --flush-logs -R --순서별 주
마이이삼:
--모든 데이터베이스 --인용 이름별 --모든 테이블 --육각형 블롭 --flush-log -R --master-data=2 --주 순서

InnoDB는 --단일 트랜잭션이고, MyISAM은 --모든 테이블을 잠그기! 기억해 두면 좋겠다.

마스터에서 가져가면: --master-data=2로 마스터 상태를 표시하고; CHANGE MASTER TO 구문 위치는 덤프 파일 맨 앞에 기록됩니다.
슬레이브 중에서 --dump-slave=2 (*MySQL 5.5 이상) 중에서 선택할 경우, 덤프 파일 맨 앞에 마스터의 위치가 기록됩니다.

mysqldump 참고문헌:
 MySQL ::MySQL 5.5 참고 매뉴얼 ::4.5.4 mysqldump —mysqldump --dump-slave - Studio3104::BLOG.newmysqldump --single-transaction --flush-logs - @tmtms 노트

참고로, 제가 처음에 마스터에서 덤프 데이터를 가져와야 했던 이유는
슬레이브가 마스터의 낮은 사양의 절반 정도였고, 많은 삭제 처리가 겹쳐서 상당한 지연이 발생했던 것 같습니다.
마스터에서 즉시 완료된 처리가 슬레이드에서 지연되는 경우가 흔한 것 같습니다.
저축은 이익을 위해 필요하지만, 서비스 기회를 잃지 않는 등 여유 및 균형도 중요합니다.
MySQL에서 삭제는 매우 무거운 범주인 것 같아서, 자주 하거나 테이블을 파티션 나누고 파티션을 삭제하면 가벼운 과정일 거라고 생각합니다.

분할 참조:
 더 빠른 처리! MySQL의 파티셔닝 기능을 사용해 봅시다 | LIG 주식회사. 지금 MySQL의 파티셔닝 기능을 써봤어요 - (゚∀゚)o sasata299의 블로그 소셜 게임을 위한 MySQL 소개 - DeNA Han의 컴퓨터 도로 기술: 파티셔닝 사용 사례 - http 세션 정보

위 내용을 검토해 주셔서 감사합니다.          

Related Articles