데이터베이스를 백업하는 두 가지 주요 방법은 mysqldump 프로그램을 사용하거나 데이터베이스 파일을 직접 복사하는 것입니다(예: cp, cpio 또는 tar 등 사용). 이 문서에서는 MySQL 플랫폼 데이터베이스 백업 계획을 자세히 설명합니다. 데이터베이스 테이블이 손실되거나 손상된 경우 데이터베이스를 백업하는 것이 중요합니다. 시스템 충돌이 발생하는 경우 데이터 손실을 최소화하면서 충돌이 발생한 당시의 상태로 테이블을 복원할 수 있기를 원할 것입니다. 때때로 혼란을 일으키는 것은 MySQL 관리자입니다. 관리자는 이미 테이블이 손상되었음을 알고 있으며 vi나 Emacs와 같은 편집기를 사용하여 직접 편집하려는 것은 테이블에 좋지 않습니다.
데이터베이스를 백업하는 두 가지 주요 방법은 mysqldump 프로그램을 사용하거나 데이터베이스 파일을 직접 복사하는 것입니다(예: cp, cpio 또는 tar 등 사용). 각 방법에는 장단점이 있습니다.
mysqldump는 MySQL 서버와 함께 작동합니다. 직접 복사 방법은 서버 외부에서 수행되므로 복사 중인 테이블을 클라이언트가 수정하지 않도록 조치를 취해야 합니다. 파일 시스템 백업을 사용하여 데이터베이스를 백업하려는 경우에도 동일한 문제가 발생합니다. 파일 시스템 백업 프로세스 중에 데이터베이스 테이블이 수정되면 백업된 테이블 파일의 제목이 일치하지 않고 테이블이 일치하지 않게 됩니다. 향후 복구에는 의미가 없습니다. 파일 시스템 백업과 파일 직접 복사의 차이점은 후자를 사용하면 백업 프로세스를 완벽하게 제어할 수 있으므로 서버가 방해받지 않고 테이블을 떠나도록 조치를 취할 수 있다는 것입니다.
mysqldump는 직접 복사보다 느립니다.
mysqldump는 다른 시스템, 심지어 하드웨어 아키텍처가 다른 시스템에도 이식 가능한 텍스트 파일을 생성합니다. 복사하려는 테이블이 MyISAM 저장 형식을 사용하지 않는 한 파일을 직접 복사하는 것은 다른 컴퓨터로 이식될 수 없습니다. ISAM 테이블은 유사한 하드웨어 구조를 가진 컴퓨터에서만 복사할 수 있습니다. MySQL 3.23에 도입된 MyISAM 테이블 저장 형식은 형식이 시스템 독립적이기 때문에 이 문제를 해결합니다. 따라서 파일을 직접 복사하면 다른 하드웨어 구조를 가진 시스템에 이식할 수 있습니다. 두 가지 조건이 충족되는 한, 다른 컴퓨터에서도 MySQL 3.23 이상을 실행해야 하며, 파일은 ISAM 형식이 아닌 MyISAM 형식으로 표시되어야 합니다.
어떤 백업 방법을 사용하든 데이터베이스를 복원해야 하는 경우 최상의 결과를 보장하기 위해 따라야 하는 몇 가지 원칙이 있습니다.
정기적인 백업을 구현합니다. 계획을 세우고 이를 고수하세요.
서버가 업데이트 로깅을 수행하도록 합니다. 변경 로그는 충돌 후 데이터를 복구해야 할 때 도움이 될 것입니다. 백업 파일을 사용하여 데이터를 백업 당시의 상태로 복원한 후 업데이트 로그에서 쿼리를 실행하여 백업 후 변경 사항을 다시 적용할 수 있습니다. 충돌이 발생했을 때의 상태.
파일 시스템 백업 용어에서 데이터베이스 백업 파일은 전체 덤프를 나타내고, 업데이트 로그는 증분 덤프를 나타냅니다.
백업 파일에 일관되고 이해하기 쉬운 명명 체계를 사용하십시오. backup1, Buckup2 등은 특별히 의미가 없습니다. 복구를 수행할 때 파일 내용을 파악하는 데 시간을 낭비하게 됩니다. 데이터베이스 이름과 날짜를 사용하여 백업 파일 이름을 구성하는 것이 유용할 수 있습니다. 예를 들어:
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
%mysqldump 동물원 >/usr/archives/mysql/menagerie.1999-10-02
백업을 생성한 후 백업을 압축할 수 있습니다. 백업은 용량이 큰 경향이 있습니다! 로그 파일을 만료시키는 것처럼 백업 파일이 디스크를 채우지 않도록 만료해야 합니다.
파일 시스템 백업으로 백업 파일을 백업하세요. 데이터 디렉터리뿐만 아니라 데이터베이스 백업이 포함된 디스크 드라이브도 지워지는 완전한 충돌이 발생하면 큰 문제가 발생하게 됩니다.
또한 변경 로그를 백업하십시오.
백업 파일을 데이터베이스에 사용된 것과 다른 파일 시스템에 배치하십시오. 이렇게 하면 백업 생성으로 인해 데이터 디렉터리가 포함된 파일 시스템이 가득 찰 가능성이 줄어듭니다.
백업을 생성하는 데 사용되는 기술은 데이터베이스를 다른 시스템에 복사하는 데에도 유용합니다. 가장 일반적으로 데이터베이스는 다른 호스트에서 실행되는 서버로 이동되지만 동일한 호스트의 다른 서버로 데이터를 이동할 수도 있습니다.
1 mysqldump를 사용하여 데이터베이스 백업 및 복사
mysqldumo 프로그램을 사용하여 데이터베이스 백업 파일을 생성하면 기본적으로 파일 내용에는 덤프되는 테이블을 생성하는 CREATE 문과 테이블의 행 데이터를 포함하는 INSERT 문이 포함됩니다. 즉, mysqldump에 의해 생성된 출력은 나중에 데이터베이스를 재구축하기 위해 mysql에 대한 입력으로 사용될 수 있습니다.
다음과 같이 전체 데이터베이스를 단일 텍스트 파일로 덤프할 수 있습니다.
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
출력 파일의 시작 부분은 다음과 같습니다.
# MySQL Dump 6.0# # 호스트: localhost 데이터베이스: samp_db
#---------------#
서버 버전 3.23.2-alpha-log## 테이블 부재에 대한 테이블 구조
#CREATE TABLE 부재( Student_id int(10) unsigned DEFAULT 0 NOT NULL, 날짜 날짜 DEFAULT 0000-00-00 NOT NUL L,
PRIMARY KEY (학생 ID, 날짜));## 테이블 부재에 대한 데이터 덤프 #INSERT INTO 부재 VALUES (3,1999-09-03);INSERT INTO 부재 VALUE S (5,1999-09-03);INSERT INTO 부재 VALUES (10,1999-09-08);......
파일의 나머지 부분은 추가 INSERT 및 CREATE TABLE 문으로 구성됩니다. 백업을 압축하려면 다음과 유사한 명령을 사용하십시오.
%mysqldump samp_db | gzip >/usr/archives/mysql/samp_db.1999-10-02.gz
데이터베이스가 큰 경우 출력 파일도 크기 때문에 관리하기 어려울 수 있습니다. 원하는 경우 mysqldump 명령줄에서 데이터베이스 이름 뒤에 개별 테이블 이름을 나열하여 내용을 덤프할 수 있습니다. 그러면 덤프 파일이 더 작고 관리하기 쉬운 파일로 분할됩니다. 다음 예에서는 samp_db 데이터베이스의 일부 테이블을 별도의 파일로 덤프하는 방법을 보여줍니다.
%mysqldump samp_db 학생 점수 이벤트 부재 >grapbook.sql
%mysqldump samp_db 회원 회장 >hist-league.sql
다른 데이터베이스의 내용을 주기적으로 새로 고치는 데 사용하기 위한 백업 파일을 생성하는 경우 --add-drop-table 옵션을 사용할 수 있습니다. 이는 서버에 DROP TABLE IF EXISTS 문을 백업 파일에 기록하도록 지시한 다음 백업 파일을 가져와 두 번째 데이터베이스에 로드할 때 테이블이 이미 존재하는 경우 오류가 발생하지 않습니다.
데이터베이스를 다른 서버로 이동하기 위해 데이터베이스를 덤프하는 경우 백업 파일을 만들 필요조차 없습니다. 데이터베이스가 다른 호스트에 있는지 확인한 다음 mysql이 mysqldump의 출력을 직접 읽을 수 있도록 파이프를 사용하여 데이터베이스를 덤프합니다. 예를 들어, 데이터베이스 samp_db를 호스트 pit-viper.snake.net에서 boa.snake.net으로 복사하려고 하면 다음과 같이 쉽게 수행할 수 있습니다.
%mysqladmin -h boa.snake.net samp_db 생성
%mysqldump samp_db | mysql -h boa.snake.net samp_db
나중에 boa.snake.net에서 데이터베이스를 다시 새로 고치려면 mysqladmin 명령을 건너뛰고 테이블이 이미 존재한다는 오류가 발생하지 않도록 mysqldump에 --add-drop-table을 추가하세요. %mysqldump --add- 드롭 테이블 samp_db | mysql -h boa.snake.net samp_db
다른 유용한 mysqldump 옵션은 다음과 같습니다: --flush-logs 및 --lock-tables 조합은 데이터베이스를 검사하는 데 도움이 됩니다. --lock-tables는 덤프하는 모든 테이블을 잠그고, --flush-logs는 업데이트 로그 파일을 닫았다가 다시 엽니다. 새 업데이트 로그에는 백업 지점에서 데이터베이스를 수정한 쿼리만 포함됩니다. 업데이트 로그 체크포인트 백업 시간이 설정됩니다. (단, 업데이트를 수행해야 하는 클라이언트가 있는 경우 백업 중 클라이언트 액세스에 대해 모든 테이블을 잠그는 것은 좋은 방법이 아닙니다.)
--flush-logs를 사용하여 백업에 대한 체크포인트를 지정하는 경우 전체 데이터베이스를 덤프하는 것이 가장 좋습니다.
별도의 파일을 덤프하면 업데이트 로그 검사점을 백업 파일과 동기화하기가 더 어렵습니다. 복구 중에는 일반적으로 데이터베이스별로 업데이트 로그 내용을 추출합니다. 개별 테이블에 대한 업데이트를 추출하는 옵션이 없으므로 직접 추출해야 합니다.
기본적으로 mysqldump는 쓰기 전에 테이블의 전체 내용을 메모리로 읽어옵니다. 이것은 일반적으로 실제로 불필요하며 실제로 큰 테이블이 있는 경우 거의 실패합니다. --quick 옵션을 사용하면 mysqldump가 행을 검색할 때마다 각 행을 기록하도록 지시할 수 있습니다. 붓기 프로세스를 더욱 최적화하려면 --quick 대신 --opt를 사용하십시오. --opt 옵션은 데이터 덤프 및 다시 읽기 속도를 높이는 추가 옵션을 활성화합니다.
--opt를 사용하여 백업을 구현하는 것은 백업의 속도 이점 때문에 아마도 가장 일반적인 방법일 것입니다. 그러나 --opt 옵션에는 비용이 발생합니다. --opt는 데이터베이스에 대한 다른 클라이언트의 액세스가 아니라 백업 프로세스를 최적화합니다. --opt 옵션은 모든 테이블을 한 번에 잠가서 덤프 중인 테이블을 다른 사람이 업데이트하는 것을 방지합니다. 일반 데이터베이스 액세스에 미치는 영향을 쉽게 확인할 수 있습니다. 데이터베이스가 일반적으로 매우 자주 사용되는 경우 하루에 한 번만 백업을 조정하십시오.
--opt와 반대 효과를 갖는 옵션은 --dedayed입니다. 이 옵션을 사용하면 mysqldump가 INSERT 문 대신 INSERT DELAYED 문을 작성하게 됩니다. --delayed는 데이터 파일을 다른 데이터베이스에 로드하고 이 작업이 해당 데이터베이스에 나타날 수 있는 쿼리에 최소한의 영향을 주기를 원하는 경우에 유용합니다.
--compress 옵션은 네트워크를 통해 전송되는 바이트 수를 줄이기 때문에 데이터베이스를 다른 시스템에 복사할 때 유용합니다. 다음은 로컬 호스트에 연결하는 프로그램이 아니라 원격 호스트의 서버와 통신하는 프로그램에 대해 --compress가 제공된다는 점에 유의하세요.
%mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db
mysqldump에는 많은 옵션이 있습니다. 자세한 내용은 "MySQL 참조 매뉴얼"을 참조하세요.
2 데이터베이스 직접 복사를 이용한 백업 및 복사 방법
mysqldump가 포함되지 않은 데이터베이스와 테이블을 백업하는 또 다른 방법은 데이터베이스 테이블 파일을 직접 복사하는 것입니다. 일반적으로 이는 cp, tar 또는 cpio와 같은 유틸리티를 사용하여 수행됩니다. 이 문서의 예제에서는 cp를 사용합니다.
직접 백업 방법을 사용하는 경우 테이블이 더 이상 사용되지 않는지 확인해야 합니다. 복사하는 동안 서버가 테이블을 변경하면 복사는 의미가 없습니다.
복사본의 무결성을 보장하는 가장 좋은 방법은 서버를 종료하고 파일을 복사한 다음 서버를 다시 시작하는 것입니다. 서버를 종료하고 싶지 않다면 테이블 체크를 하는 동안 서버를 잠그세요. 서버가 실행 중인 경우 파일 복사에 동일한 제한 사항이 적용되며 동일한 잠금 프로토콜을 사용하여 서버를 "조용"해야 합니다.
서버가 다운되었거나 복사하려는 테이블을 잠갔다고 가정하고, 다음은 전체 samp_db 데이터베이스를 백업 디렉터리(DATADIR은 서버의 데이터 디렉터리를 나타냄)에 백업하는 방법을 보여줍니다. %cd DATADIR%cp -r samp_db /usr /아카이브/mysql
단일 테이블은 다음과 같이 백업할 수 있습니다.
%cd DATADIR/samp_db%cp 멤버.* /usr/archive/mysql/samp_db%cp 점수.* /usr/archive/mysql/samp_db ....
백업이 완료되면 서버를 다시 시작하거나(종료한 경우) 테이블에 설정된 잠금을 해제할 수 있습니다(서버를 계속 실행 중인 경우).
직접 복사 파일을 사용하여 한 컴퓨터에서 다른 컴퓨터로 데이터베이스를 복사하려면 파일을 다른 서버 호스트의 적절한 데이터 디렉터리에 복사하기만 하면 됩니다. 파일이 MyIASM 형식인지 또는 두 시스템 모두 동일한 하드웨어 구조를 가지고 있는지 확인하십시오. 그렇지 않으면 데이터베이스가 다른 시스템에 이상한 내용을 갖게 됩니다. 또한 데이터베이스 테이블을 설치하는 동안 다른 컴퓨터의 서버가 데이터베이스 테이블에 액세스하지 못하도록 해야 합니다.
3 데이터베이스 복제
복제는 데이터베이스를 다른 서버로 복사하는 것과 비슷하지만 정확한 의미는 두 데이터베이스가 실시간으로 완전히 동기화되도록 하는 것입니다. 이 기능은 3.23 버전에 등장할 예정이며 아직 완성도가 높지 않기 때문에 이 글에서는 자세히 소개하지 않겠습니다.
4 백업에서 데이터 복원
데이터베이스 손상은 여러 가지 이유로 다양한 정도로 발생할 수 있습니다. 운이 좋으면 하나 또는 두 개의 테이블만 손상될 수 있습니다(예: 정전). 운이 좋지 않으면 전체 데이터 디렉터리를 교체해야 할 수도 있습니다(예: 디스크 손상). 사용자가 실수로 데이터베이스나 테이블을 삭제한 경우와 같은 특정 상황에서도 복구가 필요합니다. 이러한 불행한 사건의 원인에 관계없이 일종의 복구를 구현해야 합니다.
테이블이 손상되었지만 손실되지 않은 경우 myisamchk 또는 isamchk를 사용하여 복구를 시도하십시오. 복구 프로그램으로 이러한 손상을 복구할 수 있으면 백업 파일을 전혀 사용할 필요가 없습니다. 테이블 복구 과정은 "데이터베이스 유지 관리 및 복구"를 참조하세요.
복구 프로세스에는 백업 파일과 변경 로그라는 두 가지 정보 소스가 포함됩니다. 백업 파일은 백업이 수행된 당시의 상태로 테이블을 복원합니다. 그러나 일반적으로 테이블은 백업과 문제 사이에 수정되었으며 업데이트 로그에는 이러한 수정을 수행하는 데 사용된 쿼리가 포함됩니다. 쿼리를 반복하기 위해 로그 파일을 mysql에 대한 입력으로 사용할 수 있습니다. 이것이 변경 로그를 활성화해야 하는 이유입니다.
복구 프로세스는 복구해야 하는 정보의 양에 따라 다릅니다. 실제로 단일 테이블보다 데이터베이스에 업데이트 로그를 적용하는 것이 더 쉽기 때문에 단일 테이블보다 전체 데이터베이스를 복원하는 것이 더 쉽습니다.
4.1 전체 데이터베이스 복원
먼저 복원하려는 데이터베이스가 그랜트 테이블이 포함된 mysql 데이터베이스인 경우 --skip-grant-table 옵션을 사용하여 서버를 실행해야 합니다. 그렇지 않으면 인증 테이블을 찾을 수 없다고 불평할 것입니다. 테이블을 복원한 후 mysqladmin 플러시-권한을 실행하여 서버에 인증 토큰을 로드하고 사용하도록 지시합니다.
나중에 필요할 경우 데이터베이스 디렉터리 내용을 다른 위치에 복사하세요.
최신 백업 파일로 데이터베이스를 다시 설치하십시오. mysqldump에 의해 생성된 파일을 사용하는 경우 이를 mysql에 대한 입력으로 사용하십시오. 데이터베이스에서 직접 복사된 파일을 사용하는 경우 해당 파일을 데이터베이스 디렉터리에 직접 복사하세요. 그러나 이 경우 파일을 복사하기 전에 데이터베이스를 닫은 다음 다시 시작해야 합니다.
업데이트 로그를 사용하여 백업 후 데이터베이스 테이블을 수정하는 쿼리를 반복합니다. 적용 가능한 변경 로그의 경우 mysql에 입력으로 전달합니다. --one-database 옵션을 지정하면 mysql이 복원하려는 데이터베이스에 대해서만 쿼리를 실행합니다. 모든 업데이트 로그 파일을 적용해야 한다는 것을 알고 있는 경우 로그가 포함된 디렉터리에서 다음 명령을 사용할 수 있습니다.
% ls -t -r -1 업데이트.[0-9]* xargs cat | mysql --one-database db_name
ls 명령은 서버가 생성한 순서에 따라 정렬된 업데이트 로그 파일의 단일 열 목록을 생성합니다(아이디어: 파일을 수정하면 정렬 순서가 변경되어 업데이트 로그가 잘못된 순서로 사용되었습니다.)
대부분 특정 변경 로그를 사용하게 될 것입니다. 예를 들어 백업 이후 생성된 업데이트 로그의 이름이 update.392, update.393 등인 경우 다음과 같이 다시 실행할 수 있습니다.
%mysql --one-database db_name < 업데이트.392
%mysql --one-database db_name < 업데이트.393
.....
복구를 수행 중이고 업데이트 로그를 사용하여 잘못 권장되는 DROP DATABASE, DROP TABLE 또는 DELETE 문으로 인해 손실된 정보를 복구하는 경우 사용하기 전에 업데이트 로그에서 해당 문을 삭제해야 합니다.
4.2 단일 테이블 복원
단일 테이블을 복원하는 것은 더 복잡합니다. mysqldump에 의해 생성된 백업 파일을 사용하는데 관심 있는 테이블에 대한 데이터가 포함되어 있지 않은 경우 관련 행에서 해당 파일을 추출하여 mysql에 대한 입력으로 사용해야 합니다. 이것은 쉬운 부분입니다. 어려운 부분은 해당 테이블에만 적용되는 업데이트 로그에서 조각을 가져오는 것입니다. 변경 로그에서 다중 행 쿼리를 추출하는 mysql_find_rows 유틸리티가 도움이 될 수 있습니다.
또 다른 가능성은 다른 서버를 사용하여 전체 데이터베이스를 복원한 다음 원하는 테이블 파일을 원본 데이터베이스에 복사하는 것입니다. 이는 정말 쉬울 수 있습니다. 파일을 데이터베이스 디렉터리에 다시 복사할 때 원래 데이터베이스 서버가 종료되었는지 확인하세요.