mysqldump 및 바이너리 로그 log-bin을 기반으로 하는 MySQL의 논리적 백업 및 특정 시점 복원

이 기사의 출처:

이 기사는 간단한 테스트를 위해 mysqldump 및 log-bin 바이너리 로그의 사용을 시뮬레이션한 것입니다. 아직은 개인 학습 노트로만 사용되므로 실제 적용과는 거리가 멀습니다. 참고용입니다.

MySQL의 bin-log 바이너리 로그 활성화

　 시뮬레이션 복원에는 mysqldump의 파일 및 로그 bin이 필요하므로 log-bin 바이너리 로그를 시작해야 합니다.
　mysql5.7.18에서 바이너리 로그를 열 때, log-bin의 위치 설정과 함께 server-id도 설정해야 합니다. 이전 버전의 MySQL에서는 이 설정이 필요하지 않습니다.

　 오픈 소스 소프트웨어에 대해 불평해 보겠습니다. 기본적으로 각 버전은 이전 버전과 약간의 차이가 있습니다. 온라인에서 정보를 검색하기 어려운 경우가 많습니다.

　

다시 시작한 후 log_bin 관련 변수를 쿼리합니다

　

mysqldump 백업(내보내기) 데이터의 기본 사용법

mysqldump 명령에는 꽤 많은 매개 변수가 있습니다. 명령을 실행하고 mysqldump 백업(엄밀히 말하면 데이터를 내보내는 것)과 데이터베이스 복원 작업을 위한 바이너리 로그 log-bin을 사용합니다.

-- 전체 testdb 데이터베이스를 백업합니다. -l은 모든 테이블에 읽기 잠금을 추가하는 것을 의미합니다. -F(F는 대문자여야 하며 소문자는 오류를 보고하지 않으며 단일 페이지는 유효하지 않음)는 새 로그를 생성하기 위한 롤링을 의미합니다. file
mysqldump -u root - p -l -F -h localhost testdb > usr/local/mysqlbak/test20170607_data.sql

백업된 파일은 테이블 생성 및 테이블 삽입을 위한 스크립트입니다

-- testdb 데이터베이스 백업 test_table1과 test_table2 테이블이 두 개 있습니다. --no-create-info를 추가하면 백업된 파일에는 테이블 생성 스크립트가 포함되지 않고 테이블에 삽입되는 정보만 포함됩니다
mysqldump -uroot -p -h localhost testdb test_table1 test_table2 --no-create-info> usr/local/mysqlbak/test20170606_1.sql

-- testdb 데이터베이스의 test2 테이블에 있는 데이터의 일부를 백업합니다. id<1000
mysqldump -uroot - p -h localhost testdb test_table1 --where "id<1000" > usr/local/mysqlbak/test20170606_2.sql

과 일치하는 test_table1 테이블의 데이터를 올립니다. mysqldump 매개변수는 다음을 참조하세요.

추가로, mysql 로그빈 교체 전략:

인덱스를 사용하여 파일을 루프하고, 다음 조건에서 다음 인덱스
1로 루프합니다. 서버 재시작
2. 서버가 업데이트되었습니다
3. 로그가 최대 로그 길이 max_binlog_size
4에 도달했습니다. 로그가 플러시됩니다. mysql> 로그 플러시;

mysqldump에 백업된 파일과 로그빈 바이너리 로그를 사용하여 복원

먼저 테이블에 데이터가 있으면 백업

mysqldump를 실행합니다. -u root -p -l -F -h localhost testdb --master-data=2 > usr/local/mysqlbak/test20170607_data.sql

　　

　여기에 --master-data=2 옵션이 추가되었습니다. 이 명령이 추가된 이유에 대해 많은 블로그에서는 mysqldump를 사용하여 파일을 백업한 후 데이터를 수정한 다음 실수로 삭제하거나 다운타임을 시뮬레이션한다고 기록합니다. 그런 다음 mysqldump 파일을 사용하여 복원하고 log-bin을 사용하여 복원합니다.
모두 테스트 시뮬레이션이지만 mysqldump 이후에 로그가 스크롤되었는지 여부와 스크롤 횟수를 어떻게 알 수 있는지 알 수 있습니다. 스크롤한 횟수는?
로그가 스크롤되지 않으면 시점이나 위치에 따라 로그빈 파일을 복원합니다. 스크롤되면 로그 파일이 몇 개나 스크롤되었는지 어떻게 알 수 있나요?
새로 생성된 로그 파일을 새로고침한 후 기록해야 하나요? mysqldump가 실행될 때 로그를 기록하고, 로그 복원을 사용할 때 복원에 사용할 로그를 결정할 수 있습니다.

--master-data=2 옵션을 사용하면 mysqldump 백업 중에 log_file 위치를 알 수 있습니다.

그런 다음 계속해서 10개의 데이터를 테이블에 삽입합니다.

그런 다음 실수로 인한 데이터 삭제를 시뮬레이션합니다. 이 경우 테스트 테이블은 비어 있습니다.

　

먼저 mysqldump의 파일을 사용하여 데이터베이스를 복원합니다. 백업 파일의 데이터는 100행이므로 백업시에는 100행이 있으니 문제 없습니다.

　　

　 그런 다음 log-bin을 사용하여 시점에 따라 복원합니다. 위에서 언급한 것처럼 mysqldump에서 생성된 파일은 로그가 새로 고쳐진 후 log-bin이라는 파일 이름을 기록합니다. 그렇지 않은 경우 아래 그림의 최신 로그빈을 기준으로 시점에 따라 스크롤하여 복원합니다. mysqldump 백업 및 복원

mysql -u root -p testdb & lt; --stop- datetime="2017-6-7 21:45:00"
/var/lib/mysql/

mysql-bin.000022

| mysql -u root -p testdb　 그러면 데이터가 돌아옵니다.

　


물론 이는 시뮬레이션에 불과합니다. 물론 아직 확정되지 않은 사항도 많지만, 로그 롤링이 발생하면 시점을 기준으로 복원해야 합니다. 해당 시점을 기준으로 어떤 로그 파일이 있는지 알아내는 것이 필요합니다.

요약:

이 기사에서는 데이터베이스 복원 작업을 모델링하기 위해 간단한 예만 사용합니다.

mysqldump 백업 모드는 비교적 간단하고 대략적인 데이터를 삽입 스크립트로 내보낼 뿐이므로 다음과 같은 경우 성능이 향상됩니다. 더 큰 데이터 복원 문제, mysqldump가 적합하지 않을 수 있으며 백업 및 복원을 위해 더 효율적인 xtrabackup이 필요합니다.

　

　

　

위 내용은 mysqldump 및 바이너리 로그 log-bin을 기반으로 하는 MySQL의 논리적 백업 및 특정 시점 복원의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!