Innobackupex 및 mydumper, mysql 백업 도구-헤드라인-php.cn

------------------------------------------------

------물리적 백업 도구 Innobackupex------

------------------ --- -----

공식 매뉴얼: https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

주로 핫 백업에 사용 InnoDB, MyISAM 등의 엔진에 저장된 데이터를 백업할 때 백업할 데이터를 메모리에 로딩한 후 디스크의 백업 데이터 파일에 기록합니다. 백업 중에 변경된 데이터는 Redo 로그 복구와 마찬가지로 백업 파일에 추가됩니다.

============================================== == ===============================================

innobackupex 전체 준비 과정:

1. xtrabackup_logfile을 활성화합니다. InnoDB 스토리지 엔진에서 새로운 DML 작업으로 인해 데이터가 변경될 때 전체 핫 백업 프로세스 중에 이러한 새로운 데이터 변경 사항을 실시간으로 xtrabackup_logfile에 기록하는 데 사용됩니다. 기록 형식은 Redo log

2와 동일합니다. 페이지 단위 데이터 파일: 공유 테이블 공간 ibdataX 및 .ibd 파일. 복사하는 동안 페이지가 작성될 수 있으므로 페이지의 헤드 및 테일 체크섬 값이 달라집니다. 따라서 나중에 백업 파일을 생성할 때 일부 불완전한 페이지를 복구하기 위해 사용하기 전에 로그를 적용해야 합니다.

3. 읽기 잠금으로 테이블을 플러시합니다. 비트랜잭션 엔진 MyISAM

4에 저장된 데이터를 복사하려면 MyISAM 테이블에 읽기 잠금을 추가하세요. .frm, .MYD, .MYI 파일을 복사하세요.

5. 백업이 완료되는 순간 binlog의 최신 위치를 가져옵니다: xtrabackup_binlog_info(InnoDB 데이터 파일이 업데이트될 수 있음).

6. 테이블 잠금 해제

7. (1) 백업이 완료된 후 backup-my.cnf

에 백업을 시작하는 데 필요한 최소 매개변수를 기록합니다. (2) LSN을 xtrabackup_logfile에 기록합니다.

(3) 백업 유형(전체 백업: 전체, 증분: 증분, 로그가 적용된 백업은 전체 준비로 수정됨) 및 기타 정보를 xtrabackup_checkpoints에 기록합니다.

(4) 기타 백업 정보 기록:

(1) backup-my.cnf

(2)xtrabackup_binlog_info: 데이터 백업을 위해 MyISAM과 혼합하면 xtrabackup_binlog_pos_innodb Innobackupex 및 mydumper, mysql 백업 도구

보다 정확합니다. (3)xtrabackup_binlog_pos_innodb: 로그 적용 후 새로 생성된 파일, MyISAM Innobackupex 및 mydumper, mysql 백업 도구

에서 생성된 binlog를 계산하지 않고 innodb의 binlog 위치만 기록합니다. (4) xtrabackup_checkpoints Innobackupex 및 mydumper, mysql 백업 도구

(5) xtrabackup_info Innobackupex 및 mydumper, mysql 백업 도구

( 6) xtrabackup_logfile(코어 파일) Innobackupex 및 mydumper, mysql 백업 도구

(7 ) xtrabackup_slave_info(라이브러리에서 중요한 파일 백업): 백업 시 --slave-info 옵션을 추가해야 하며 "change master to..." 정보는 이 파일에 기록됩니다. 백업 파일을 사용하여 슬레이브 데이터베이스를 복원한 후에는 이 정보를 사용하여 동기화를 위해 마스터 데이터베이스를 다시 가리킵니다.

============================================== == ===============================================

innobackupex 증분 백업 프로세스

innobackupex InnoDB 테이블 데이터를 증분 백업하는 경우 전체 백업 프로세스와 비교하여 백업 복사본이 페이지를 복사할 경우 백업 파일의 LSN이 현재 데이터의 페이지와 비교됩니다. 변경 사항이 있는 경우 데이터 관련 페이지의 경우 LSN이 증가합니다. 따라서 innobackupex는 LSN이 변경된 페이지만 백업하면 됩니다.

MyISAM을 백업할 때에도 전체 백업 작업이 수행됩니다.

============================================== == ===============================================

백업 문 예

백업 계정에 필요한 권한: RELOAD, LOCK TABLES, REPLICATION CLIENT

(1) 전체:

step1:

innobackupex --defaults-file=/usr/local/mysql/my .cnf --user=사용자 이름 --password='user_passwd' --host=[HOST]--port=[PORT] --no-timestamp /tmp/innobackup_all

step2：

innobackupex --apply-log - - defaults-file=/tmp/innobackup_all/backup-my.cnf --user=사용자 이름 --password='user_passwd' --host=[HOST] --port=[PORT] --/tmp/innobackup_all

（ 2 ) 부분 백업: 백업 형식은 다음과 같습니다: mydatabase.mytable

step1:

정규 표현식과 함께 --include 사용

innobackupex --include='^mydatabase[.]mytable' /path/to/backup --no-timestamp

전체 테이블 이름을 기록하는 텍스트 파일과 함께 --tables-file을 사용하세요(한 줄에 하나의 테이블 이름)

echo "mydatabase.mytable" > /tmp/tables.txt

innobackupex - -테이블 파일=/tmp/tables.txt /path/to/backup --no-timestamp

--databases를 사용하여 라이브러리와 테이블을 지정합니다(예: 백업 테이블: mydatabase.mytable 및 라이브러리: mysql)

innobackupex --databases="mydatabase.mytable mysql" /path/to/backup --no-timestamp - -user= 백업 --password=backup

2단계:

부분 백업 준비: innobackupex --apply-log --export /path/to/backup/

(--databases unspecified library table, 프롬프트가 표시됩니다. 준비 단계에서 "노트가 존재합니까?", 이 메시지를 무시해도 됩니다.

(3) 증분 백업(전체 백업 가정, 경로: $FULLBACKUP)

step1:

첫 번째 증분 백업(전체 백업 기준): innobackupex - -incremental $INCREMENTALBACKUP_1 --incremental-basedir=$FULLBACKUP --user=USER --password=PASSWORD

두 번째 증분 백업(첫 번째 증분 백업 기준): innobackupex --incremental $INCREMENTALBACKUP_2 -- Incremental-basedir= NCREMENTALBACKUP_1 --user=USER --password=PASSWORD

(...)

N번째 시간

2단계: prepare

innobackupex --apply-log --redo-only $FULLBACKUP --use-memory= 1G --user=USER --password=PASSWORD

innobackupex --apply-log --redo-only $FULLBACKUP--incremental-dir=$INCREMENTALBACKUP_1 --use-memory=1G - -user=DVADER --password= D4RKS1D3

innobackupex --apply-log --redo-only $FULLBACKUP --incremental-dir=$INCREMENTALBACKUP_2 --use-memory=1G --user=DVADER --password=D4RKS1D3

(...)

innobackupex --apply-log--redo-only $FULLBACKUP --incremental-dir=$INCREMENTALBACKUP_N --use-memory=1G --user=DVADER --password= D4RKS1D3

innobackupex --apply-log $ FULLBACKUP --use-memory=1G --user=$USERNAME --password=$PASSWORD

--use-memory: 준비가 사용할 수 있는 메모리를 지정합니다. -- Apply-log를 함께 사용하여 준비 속도를 높입니다. 준비 단계에서는 첫 번째 전체 백업 및 증분 백업 통합 과정에서 --redo-only를 추가해야 합니다. 마지막으로 증분 백업을 모두 통합한 후에는 증분 백업에 통합된 전체 백업 파일을 다시 준비해야 합니다.

============================================== == ===============================================

기타 일반적으로 사용되는 매개변수:

함께 사용: --stream=xbstream --compress --compress-threads=8 --parallel=4 > backupfile.xbstream(xbstream 옵션은 ibd 파일을 압축하고 스트리밍합니다. 따라서 innodb-file-per-table 매개 변수를 켜야 합니다)

--parallel: 백업 동시성 번호(ibd 파일을 복사하는 것을 의미하며, 압축 스레드와는 다른 번호입니다. 압축을 수행할 스레드 수)

--stream: tar, xbstream . 종종 다음과 함께 사용됩니다: innobackupex [...] --stream=tar /backupdir/ | gzip - > backupfile.tar.gz

--tmpdir: 원격 시스템으로 스트리밍하기 전의 임시 디렉터리 위치

- -encryption : 백업 암호화. 실제 상황에서 더 일반적으로 사용되는 것은

(1) 위의 tar+gz 방법에 암호화 옵션을 추가하는 것입니다: innobackupex [...] --stream=tar /backupdir/ gzip - | -cbc -k "abc" > backupfile.tar.gz.aes-256-cbc

(2)des3,innobackupex [...] --stream=tar /backupdir/ | gzip - | k " abc" > backupfile.tar.gz.des3

=============================== ==== ============================================= ==== ==========

innobackupex 복구 프로세스

1.innobackupex --apply-log, 목적은 xtrabackup_log에서 다시 실행 로그를 얻고, 일부 불완전한 페이지를 업데이트하고, 헤드 및 테일 체크섬 값, LSN은 백업 프로세스 중에 최신 LSN 번호로 업데이트됩니다. (실제로는 백업 프로세스로 나누어야 합니다.)

2. 백업 데이터를 데이터베이스 데이터 디렉터리에 복사합니다. 데이터 디렉터리 권한을 수정하고 시작합니다.

============================================== == ===============================================

복구문의 예:

1. 복구 전 인스턴스를 닫습니다.

2. 원본 데이터 디렉터리를 백업합니다(redo 로그와 undo 로그가 분리된 경우에도 백업해야 함)

3. copy-back --user=사용자 이름 - -password='user_passwd' --socket=/usr/local/mysql/run/mysqld.sock --defaults-file=/usr/local/mysql/my.cnf /tmp/ innobackup_all (또는 준비된 백업 파일을 직접 복사)

4. 디렉터리 권한을 수정하고 mysql을 시작합니다

========================= =========== ====================================== =========== ===========

모든 InnoDB 데이터베이스에서 개별 테이블 데이터 내보내기(innodb_file_per_table 옵션이 켜져 있는 경우)

Percona XtraBackup을 사용하면 다음을 수행할 수 있습니다. InnoDB 데이터베이스에서 개별 테이블을 내보내고 XtraDB 또는 MySQL 5.6을 사용하여 Percona Server로 가져옵니다(소스는 XtraDB 또는 MySQL 5.6일 필요는 없지만 대상은 개별 .ibd 파일에서만 작동합니다). 자체 ibd 파일에 포함되지 않은 테이블은 내보낼 수 없습니다.

준비 단계에서 --export 옵션을 통해 단일 테이블을 내보내야 합니다.

전체 백업이 생성되면 -를 사용하여 준비합니다. -내보내기 옵션:

$ innobackupex --apply-log --export /path/to/backup

이것은 자체 테이블스페이스가 있는 각 InnoDB에 대해 .exp 확장자를 가진 파일을 생성합니다.

각 innodb 테이블의 테이블스페이스에 대해 .exp로 끝나는 파일이 생성됩니다.

출력 파일 형식은 다음과 같습니다:

/data/backups/mysql/test/export_test.exp
/data/backups/mysql/ test/export_test.ibd
/data/backups/mysql/test/export_test.cfg

다른 서버에서 테이블을 가져올 때 먼저 테이블을 생성해야 합니다(독립 테이블 파일에는 테이블 구조 정보가 없기 때문입니다):

mysqlfrm -- 진단 /data/2017-03-22_16-13-00/yayun/t1.frm (mysql-utilities 도구에서 mysqlfrm을 사용하여 백업 파일에서 테이블 구조를 읽음)

mysql> ...) ENGINE =InnoDB; (이전에 읽은 테이블 구조를 기반으로 테이블 생성으로 이동)

테이블 공간 파일 삭제:

mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

내보낸 .ibd 및 . exp 파일을 데이터 디렉터리에 복사합니다. 다음:

이후 mytable.ibd 및 mytable.exp(또는 MySQL 5.6으로 가져오는 경우 mytable.cfg) 파일을 데이터베이스의 홈으로 복사합니다.

그런 다음 테이블스페이스를 가져옵니다.

mysql> .mytable IMPORT TABLESPACE;

------------------------------- ------

--- ---논리 백업 도구 mydumper------

------------ ---------- ---------

영문 문헌의 일부는 GitHub의 README에서 발췌되었습니다: https://github.com/maxbube/mydumper

5.5 /5.6 버전의 MySQL 데이터베이스는 공식 버전인 Mysqldump와 비교하여 단일 스레드 백업을 수행하며 다중 스레드 백업 도구인 mydumper는 독특한 장점을 가지고 있습니다. (MySQL 5.7.11 이후 버전의 경우 공식적으로 병렬 논리 백업 도구인 mysqlpump의 일관된 백업 문제를 마침내 수정했습니다. mysqlpump에 대해서는 Daniel Jiang Chengyao의 소개: http://www.tuicool.com/articles/를 참조하십시오. E77bYz7)

단점: 동시 스트리밍을 통해 원격 백업 센터에 백업하기 어렵고 로컬에서 직접 다운로드할 가능성이 높습니다.

== 일관된 스냅샷은 어떻게 작동하나요? ==
이 작업은 모두 최고의 MySQL 관행과 전통에 따라 수행됩니다.

* 예방 조치로 서버에서 느리게 실행되는 쿼리는 덤프를 중단하거나 종료됩니다.
* 전역 쓰기 잠금 획득됨("FLUSH TABLES WITH READ LOCK")
* 다양한 메타데이터가 읽혀짐("SHOW SLAVE STATUS", "SHOW MASTER STATUS")
* 다른 스레드가 연결되어 스냅샷을 설정함("START TRANSACTION WITH CONSISTENT SNAPSHOT")
** 4.1.8 이전 버전에서는 더미 InnoDB 테이블을 생성하고 그 테이블에서 읽습니다.
* 모든 작업자 스레드가 스냅샷 설정을 알리면 마스터는 "UNLOCK TABLES"를 실행하고 대기열 작업을 시작합니다.

mydumper의 일관성 구현 메커니즘:

* 언제 느린 쿼리가 발생하면 덤프 실행이 중지되거나 mydumper가 느린 쿼리를 종료합니다. (--long-query-guard 매개변수는 느린 쿼리의 시간을 합의하는 데 사용됩니다. 기본값은 60초입니다. 이 매개변수에 --kill-long-queries를 추가하면 느린 쿼리가 적극적으로 종료됩니다. 추가되지 않으면 mydumper는 느린 쿼리를 발견할 때 자동으로 느린 쿼리를 종료합니다.
* "FLUSH TABLES WITH READ LOCK"을 사용하여 DML 문을 방지하는 전역 읽기 잠금을 적용합니다.
* 메타데이터 보기 : "SHOW SLAVE STATUS", "SHOW MASTER STATUS"

* ""일관된 스냅샷"으로 트랜잭션 시작: 트랜잭션 시작은 트랜잭션을 시작하고 현재 트랜잭션의 일관된 읽기 스냅샷을 즉시 생성합니다. with 옵션이 없으면 트랜잭션의 첫 번째 문이 실행될 때까지 트랜잭션이 실제로 시작되지 않으며 일관된 읽기의 스냅샷이 설정됩니다

* 버전 4.1.8부터 mydumper는 InnoDB 유형의 가상 테이블을 생성하고 데이터를 읽습니다. from it

* 모든 스레드가 일관성 스냅샷이 설정되었음을 보고하면 "UNLOCK TABLES"를 실행하고 대기열 작업을 시작합니다.

백업 문의 예:

mydumper --user=username --password=user_passwd --socket=/... --regex '^(?!(mysql))' --output=/backupdir - -compress --verbose=3 --logfile=/backupdir/mydumper_backup.log

공통 매개변수 설명:

--database는 백업해야 하는 라이브러리를 지정합니다.
--tables-list는 백업해야 하는 테이블을 지정합니다. 다음으로 구분하여 백업합니다(정규식 옵션이 충돌하는 경우 정규식이 우선함)

--regex '^(?!(mysql|test))': 데이터베이스 필터링 옵션

--output=/backupdir: 백업 파일 출력 경로

--compress : 압축된 출력 파일(.gz 접미사)

--verbose=3: 백업 상태를 쉽게 관찰할 수 있는 출력 로그 수준 정보(0 = 자동, 1 = 오류, 2 = 경고, 3 = 정보) , 기본값 2)

- -logfile=/backupdir/mydumper_backup.log: mydumper 실행 로그 파일의 위치를 지정합니다.

--threads 백업 중에 사용되는 스레드 수를 지정합니다. 기본값은 4

-- 문 크기: SQL 문의 최대 길이를 제한합니다(mydumper는 백업 시 SQL을 병합합니다)
--rows: 테이블을 행 수로 분할합니다. myloader
--chunk-filesize: 출력 파일의 크기에 따라 테이블 데이터를 분할할 때 동시성 성능을 향상시킵니다. myloader의 동시성 성능 향상
--no-locks: 테이블을 잠그지 않음(데이터가 일치하지 않을 수 있음)
--binlogs: binlog를 백업합니다. 백업 실패 시 백업 binlog를 확인하여 백업 지점 부근에서 오류 원인을 찾아볼 수 있습니다. 출력 백업 파일 디렉터리:

* 라이브러리 구조: dbname-schema-create.sql.gz

* 테이블 구조: dbname.tblname1-schema.sql.gz

* 테이블 데이터: dbname.tblname1.sql.gz

(라이브러리와 테이블마다 독립적인 백업 파일이 있습니다. 단일 테이블만 복원해야 하는 경우 mydumper를 사용하여 단일 테이블 + binlog의 전체 데이터를 복원하세요. 복구 증분 )

* 메타데이터: 백업 중 binlog의 현재 위치를 포함합니다

------------------------------- --- ---------------------

덤프 시작 날짜: 2017-07-04 09: 45:57
SHOW MASTER STATUS :
Log: mysql-bin.000048
Pos: 107
GTID:(null)
완료된 덤프 시간: 2017-07-04 09:45:57

------ ------- ----------------- ------- -

* mydumper_backup.log: 백업 프로그램의 실행 상태를 기록합니다.

Recovery 명령 myloader 관련 매개변수 설명
--디렉터리 백업 파일 위치
--queries-per-transaction 각 트랜잭션에 대해 실행된 SQL 수, 기본값은 1000
--overwrite-tables 기존 테이블을 먼저 삭제한 후 복원(백업 시 테이블 구조를 백업해야 함)
--데이터베이스는 복원해야 하는 데이터베이스를 지정합니다.
--enable-binlog는 데이터 복원 작업에 대한 binlog를 기록합니다.
-- 스레드는 복원 중에 사용되는 스레드 수를 지정하며 기본값은 4

--활성화입니다. -binlog: 백업된 binlog를 복원합니다

참고: myloader는 라이브러리 수준에서만 복원할 수 있습니다. 단일 테이블 복원은 백업 파일에서 해당 기능을 직접 호출할 수 있습니다. sql 문이 포함된 파일

또한 innobackupex는 백업합니다. mydumper가 백업한 데이터(mysqldump, mysqlpump 등 포함)의 시점은 백업이 시작되는 시점이며, 백업이 완료되는 시점 이전의 데이터입니다.

복구의 주요 아이디어를 언급하겠습니다. 물리적 백업이든 논리적 백업이든 가장 안정적인 복구 전제는 데이터베이스가 일시적으로 데이터 쓰기를 금지해야 한다는 것입니다. 그런 다음 전체 백업을 먼저 복원하고 가장 가까운 오류 지점에 증분 백업을 적용한 다음 binlog 로그를 적용하고 오류 지점을 건너뜁니다.

단일 테이블의 몇 가지 오작동 문에 대해 온라인 서버에서 쓰기 작업을 중지하고 전체 + 증분 복구 방법을 사용하는 것은 약간의 노력 낭비이며 이득이 손실보다 크다는 점을 항상 고려하십시오. 복제 지연 전략을 적용한 대기 데이터베이스가 없는 경우 mydumper로 백업한 파일을 이용하여 단일 테이블을 복원하거나, 한발 물러나 플래시백을 활용하는 것이 빠르고 좋은 해결책이다.

Tips:

Innobackupex 또는 mydumper를 사용하여 대부분의 데이터를 복원한 후 mysqlbing을 사용하여 위 백업 프로그램에서 처리할 수 없는 데이터 부분을 채웁니다.

Mysqlbinlog 매개변수 설명:

–start-position=N(읽을 때 포함)
바이너리 로그의 첫 번째 위치가 N 매개변수와 같을 때 이벤트에서 읽기를 시작합니다.
–stop-position=N (읽을 때 포함되지 않음)
바이너리 로그의 첫 번째 위치가 N 매개변수와 같거나 크면 이벤트 읽기를 중지합니다.

mysqlbinlog를 사용하여 binlog 로그를 적용할 때 여러 파일을 확장해야 하는 경우 동시에 여러 파일을 읽어야 합니다. 시작 위치는 첫 번째 binlog 파일의 시작 지점이고 중지 위치는 파일의 끝 지점입니다. 마지막 파일.

예: mysql-bin.000048(pos856), mysql-bin.000051(pos1042)

/usr/local/mysql/bin/mysqlbinlog mysql-bin.000048 mysql-bin.000049 mysql-bin.000050 mysql- bin.000051 --start-position=856 --stop-position=1042 > /tmp/backup1/backup_new.sql

팁:

항상 백업 모니터링을 하세요.

위의 두 가지 백업 도구 개체는 주로 데이터 디렉터리에 포함됩니다. binlog에도 일부 데이터가 포함되어 있으며 binlog도 백업해야 합니다.

백업 전략에 대해 간략하게 설명합니다. 우리가 개발하는 백업 전략은 비즈니스 유형에 따라 결정됩니다.

데이터 성장 사업의 경우 전체 + 증분 전략을 채택하고, 데이터 업데이트 유형의 경우 전체 백업을 채택합니다.

MySQL 버전 업그레이드나 단일 테이블 복구 등의 작업에는 논리적 백업이 자주 사용됩니다.

결론적으로 온라인 데이터베이스는 일반적으로 물리적 백업을 주요 방식으로, 논리적 백업을 보완적으로, binlog 백업을 채택합니다.

참조 문서:

innobackupex 백업 생성 파일 지침:

http://fordba.com/xtrabackup-produce-file-intruduction.html

innobackupex 레시피:

https://www.percona.com/ doc/percona-xtrabackup/LATEST/how-tos.html#recipes-ibk