MariaDB Administration - 백업과 복구 개요
|
Contents 1. Logical vs Physical Backups 2. Backup Tools | +- 2-1. MariaBackup | +- 2-2. mysqldump | +- ----2-2-1. InnoDB Logical Backups | +- ----2-2-2. Examples | +- 2-3. mysqlhotcopy | +- ----2-3-1. Examples | +- 2-4. Percona XtraBackup | +- 2-5. Filesystem Snapshots | +- 2-6. LVM |
백업 및 복원 개요
이번 포스팅에서는 MariaDB를 백업하는 주요 방법에 대해 간단히 알아보도록 합니다.
1. 논리적 vs 물리적 Backup
논리적 백업은 CREATE DATABASE, CREATE TABLE 및 INSERT와 같이 데이터를 복원하는 데 필요한 SQL문으로 구성됩니다.
물리적 백업은 개별 데이터 파일 또는 디렉토리를 복사하여 수행됩니다.
주요 차이점은 다음과 같습니다.
|
- 논리적 백업은 다른 하드웨어 구성, MariaDB 버전 또는 다른 DBMS에서 데이터를 복원할 수 있는 반면 물리적 백업은 크게 다른 하드웨어, 다른 DBMS 또는 다른 MariaDB 버전으로 가져올 수 없습니다.
- 물리적 백업이 디렉토리, 파일 레벨로 백업수행을 할 수 있는 반면 논리적 백업은 데이터베이스 그리고 테이블 레벨로 수행할 수 있습니다. MyISAM, InnoDB 스토리지 엔진에서 각각의 테이블은 이에 대응하는 파일 세트들을 가지고 있습니다. (MariaDB 5.5 버전 전에는, default로 여러 InnoDB 테이블이 동일한 파일에 저장되며, 이 경우 테이블별로 백업할 수 없습니다.) - 논리적 백업은 물리적 백업보다 크기가 큽니다. - 논리적 백업은 물리적 백업보다 백업 및 복원 소요시간이 더 걸립니다. - 로그 파일 및 환경설정 파일은 논리 백업의 일부가 아닙니다. |
2. 백업 도구
2-1. MariaBackup
Mariabackup는 Percona XtraBackup의 fork본이고, MariaDB 10.1 압축 및 미사용 데이터 암호화를 지원하는 Percona XtraBackup의 fork본입니다.
MariaDB 10.1.23 이상 버전에 포함되어 있습니다.
2-2. mysqldump
mysqldump는 논리적 백업을 수행합니다. 백업 및 복원을 수행하는 가장 flexible한 방법이며 데이터 크기가 상대적으로 작은 경우에 적합합니다.
데이터가 세트가 클 경우, 백업 파일이 클 수 있고 복원 시간이 길어질 수 있습니다.
mysqldump는 데이터를 SQL형식으로 덤프한 다음(CSV 또는 XML과 같은 다른 형식으로 덤프할 수 있음) 다른 데이터베이스로 쉽게 가져올 수 있습니다.
mysqldump는 테이블 정의의 일부이므로 테이블과 함께 트리거를 덤프합니다. 그러나 stored procedure, view 및 event는 아니므로 만들려면 추가매개변수를 통해 만들어야 합니다.( 예: --routines 및 --events).
물론, procedure 및 function은 시스템 테이블의 일부입니다. (예: mysql.proc )
2-2-1. InnoDB Logical Backup
InnoDB는 테이블의 데이터/인덱스를 메모리에 저장하는 buffer pool을 사용합니다. 여기서 buffer는 성능상 아주 중요합니다.
만약 InnoDB 데이터가 메모리 크기에 적절하지 않으면 버퍼에 자주 자주 액세스하는 데이터는 포함되어 있어야 합니다.
그러나 마지막으로 액세스한 데이터는 버퍼 풀에 삽입할 수 있습니다. buffer가 제대로 구성되지 않은 경우, 테이블 스캔이 발생하면 InnoDB는
테이블 전체내용을 버퍼 풀에 복사하게 될 것입니다. 논리적 백업의 문제점은 항상 암묵적 full table scan을 한다는 것입니다.
이를 피하는 쉬운 방법은 innodb_old_blocks_time 시스템 변수 값을 늘리는 것입니다. 최근에 액세스한 페이지를 버퍼 풀의 "새" 서브리스트에 넣기 전에 경과시간(milliseconds)을 나타냅니다.
한 번만 액세스되는 데이터는 "이전" 하위 list에 남아 있어야 합니다. 이는 곧 buffer pool에서 제거될 것임을 의미합니다. 백업 프로세스 중에 "이전" 서브리스트는 유용하지 않은 데이터를 저장할
가능성이 있으므로 innodb_old_blocks_pct 시스템 변수 값을 변경하여 크기조정이 가능합니다.
MariaDB 10.0 이후, 명시적으로는 논리적 백업을 시작하기 전에 디스크에 buffer pool을 덤프하고, 처리한 후 복원 할 수 있습니다.
백업 중에 발생하는 buffer pool에 대한 부정적인 변경을 취소합니다. buffer pool을 덤프하기 위해 innodb_buffer_pool_dump_now 시스템 변수를 ON으로 설정할 수 있습니다.
이를 복원하기 위해 innodb_buffer_pool_load_now 시스템 변수를 ON으로 설정할 수 있습니다.
2-2-2. Examples
single DB에서 backup하는 경우
shell> mysqldump db_name > backup-file.sql
데이터베이스에 로딩하거나 복구하는 경우
shell> mysql db_name < backup-file.sql2-3. mysqlhotcopy
| mysqlhotcopy는 현재 deprecated되었다. |
mysqlhotcopy는 물리적 백업을 수행한다. 그리고 MyISAM과 ARCHIVE 테이블들을 백업하는데만 사용된다.
뿐만 아니라, 동일한 machine의 데이터베이스 디렉토리 위치만 사용할 수 있는 제한이 있다.
2-3-1. Examples
shell> mysqlhotcopy db_name [/path/to/new_directory]
shell> mysqlhotcopy db_name_1 ... db_name_n /path/to/new_directory
2-4. Percona XtraBackup
MariaDB 10.1 버전 또는 그 이후부터는, Percona XtraBackup 대신에 Mariabackup 백업 메서드를 사용할 것을 추천드립니다.
| MariaDB 10.3에서는 Percona XtraBackup은 지원하지 않는다. |
| MariaDB 10.2와 MariaDB 10.1에서는, Percona XtraBackup은 부분지원만 된다. |
Percona XtraBackup은 빠르게 hot backup을 수행할 수 있는 툴이다.
특히 XtraDB/InnoDB 데이터베이스들용으로 설계되었습니다. (MariaDB 10.1에서는 암호화와 압축은 지원하지 않지만)
Percona XtraBackup은 MariaDB에 default로 포함되어 있지 않다.
2-5. Filesystem snapshot
베리타스와 같은 일부 파일시스템은 snapshot을 지원합니다. snapshot 중에 테이블을 lock해야 합니다.
snapshot 단계는 다음과 같습니다.
|
- mysql client에서 FLUSH TABLES WITH READ LOCK을 실행하십시오. client는 열려 있어야 합니다. - Shell에서 mount vxfs snapshot 을 실행합니다. - client는 UNLOCK TABLES를 실행할 수 있습니다. - snapshot file을 복사합니다. - Shell에서 snapshot을 마운트 해제합니다. - umount snaphost |
2-6. LVM
Perl 스크립트를 랩퍼로 사용하여 널리 사용되는 실제 백업방법.
'MySQL, MariaDB' 카테고리의 다른 글
| MariaDB - 데이터베이스 및 사용자 생성 (0) | 2020.03.27 |
|---|---|
| MariaDB 기동 및 서버 로그인 (0) | 2020.03.25 |
| MariaDB Enterprise Server 버전별 feature summary (2) | 2020.03.25 |
| MariaDB - Architecture 이해 (0) | 2020.03.23 |
| MariaDB Storage Engine - Connect (0) | 2020.03.22 |
