노땅의 IT 세계

백업 . 

mysqldump --compress --max_allowed_packet=500M -h myhost mydb | gzip > /tmp/mydb.sql.gz 

복구

gunzip < /tmp/mydb.sql.gz | mysql --quick --reconnect -u myuser -pmypass -h localhost -D mydb 

출처: <https://m.blog.naver.com/PostView.nhn?blogId=kikikl&logNo=130171785626&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F>

mysqldump를 이용한 데이터 이관시 속도 개선 방법

Written by 김형진  on 오전 5:56  in mysql  with 댓글 없음

1. mysql 에서 아래 옵션을 변경

myisam_sort_buffer_size = 1000M
myisam_max_sort_file_size = 12G

스토레지 엔진을 myisam으로 변경한 다음 insert 완료후 

alter database **** engine=innodb

2. innodb_flush_log_at_trx_commit 설정 값 변경

innodb_flush_log_at_trx_commit 값이 1인경우 insert 할때 로그파일을 기록한다. 이로인해 초당 몇천건 정도 insert할 내용을 몇십건 정도 insert한다.

show variables like 'innodb_flush_log_at_trx_commit';

DB dump파일을 import 할때는 로그가 요 없으므로 0 으로 설정하고 변경 값 확인후 insert한 다음 추후 설정값을 다시 복구한다.

set global innodb_flush_log_at_trx_commit=0;

3. table 별로 백업 sql 만들기

db_root_pw='비밀번호'

db_list=`echo "show databases;" | mysql -N -uroot -p"$db_root_pw"`
 for db in $db_list ;do
  table_list=`echo "show tables" | mysql -N -uroot -p"$db_root_pw" $db`
  for table in $table_list ; do
    mysqldump -uroot -p"$db_root_pw" $db $table > $db.${table}.sql
  done
 done

4. 옵션을 통해 시간 줄이기

--no-autocommit=1 : autocommit을 끄고 개의 테이블 입력 완료후 commit 수행, 오류 발생시 다시 처음부터 시작함

--single-transaction=1 : 작업 후에 변경 된 데이터의 내역을 다시 적용하지 않는다.

--extended-insert=1 :  INSERT 구문이 늘어나는 것을 막아준다.

- export 할때

mysqldump -hHOST_NAME -uMY_ID -pMY_PASSWORD --databases DB_NAME --tables TABLES_OF_DB_NAME --no-autocommit=1 --single-transaction=1 --extended-insert=1 > DUMP.sql

- import 할때

mysql -hHOST_NAME -uMY_ID -pMY_PASSWORD --database DB_NAME < DUMP.sql

5. txt 파일이용하기

- export 할때

mysqldump DATABASE_NAME > DUMP.txt

- import 할때

mysql -u username -p –database=DATABASE_NAME < DUMP.txt

6. large dump

mysql -h localhost -uroot -pPASSWORD
set global net_buffer_length=1000000;
set global max_allowed_packet=1000000000;
SET foreign_key_checks = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
source /media/dbdump.sql

완료후

SET foreign_key_checks = 1;
SET UNIQUE_CHECKS = 1;
SET AUTOCOMMIT = 1;

7. 기타

my.cnf 위치찾기

mysql --verbose --help | grep -A 1 'Default options'

/etc/my.cnf 파일에서

innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 0

설정 후 와 데이터 입력후 2번 실행

service mysql restart

키워드 : mysql big data fast import

출처: <https://lalwr.blogspot.com/2017/12/mysqldump.html>

그럴 때 필요한 것이 바로 mysqldump 다.

mysqldump --help 라고 치면 모든 OPTION들의 설명이 나와있겠지만,

그래도 아래 3가지 옵션은 알아 두는 것이 좋을 것 같다.

일단, 맨 위의 값들은 mysqldump가 사용하는 변수의 목록이다.

즉, 아무런 값도 치지 않고 (아! 물론  데이터 베이스는 선택해야 한다.)

명령어를 입력하면, 위의 값들을 바탕으로 결과가 만들어진다는 것이지.

그렇지만, 역시나 속도가 생명인 IT의 건아들은 

뭔가 오밀조밀하게 만져서 조금더 빠르게 덤프를 뜨고 싶을 것이다.

**** 속도가 관건인 분에게 아래의 OPTION들을 권하오~~

--no-autocommit=1 : 일단 autocommit을 끄고, 

                           1개의 테이블 입력이 완료될 때 까지

                           기다렸다가 commit을 수행 한다. 요거이 좋다!!!

                           대신 뻑나면, 다시 첨부터~~~ 우어!!!

--single-transaction=1 : 작업 후에 변경 된 데이터의 내역을 다시 적용하지 않는다.

                                 즉, 중간에 값이 바뀌질 않는다면 가능하다는 말씀.

--extended-insert=1 : 요거이 관건인데, 쓸데 없이 INSERT 구문이 늘어나는 것을 

                             막아준다. 가령 

                            ->  INSERT INTO `A` VALUES (1,10),(2,20);

                             이러면 될 것을 , 

                            -> INSERT INTO `A` VALUES (1,10); 

                            -> INSERT INTO `A` VALUES (2,20);

                             으로 늘려준다. 이러면 하루 온 종일 도는 거다 --;;

그럼 덤프 방법을 보자.

리눅스건 윈도우 커맨드건 간에 어차피 양식은 같다.

(아래의 대문자는 당신이 넣어야 할 내용들이다.)

@@@@ 덤프 할 때 @@@@

c:\>mysqldump -hHOST_NAME -uMY_ID -pMY_PASSWORD --databases DB_NAME --tables TABLES_OF_DB_NAME --no-autocommit=1 --single-transaction=1 --extended-insert=1 > c:\DUMP_FILE.sql

요러면, 아무것도 모르고 그냥 뽑아내는 방식보다,

(지가 무슨 고급 승용차인줄 아는지 거의가 풀 옵션이다 --;;)

사이즈가 1/4 정도로 확 줄고,

속도는 광속을 뽐내게 된다.

즉, 관건은, 

덤프의 시간이 아니라 RESTORE의 시간인데,

개인적인 체감 속도로 판단하자면, 

진짜 시간이 1/10 정도는 감소하는 것 같다눙... -0-/

@@@@ 복원 할 때 @@@@

c:\>mysql -hHOST_NAME -uMY_ID -pMY_PASSWORD --database DB_NAME < c:\DUMP_FILE.sql 

mysqldump 옵션

--no-autocommit=1
일단 autocommit을 끄고,
1개의 테이블 입력이 완료될 때 까지
기다렸다가 commit을 수행 한다. 요거이 좋다!!!
대신 뻑나면, 다시 첨부터~~~ 우어!!!

--single-transaction=1
작업 후에 변경 된 데이터의 내역을 다시 적용하지 않는다.
즉, 중간에 값이 바뀌질 않는다면 가능하다는 말씀.

--extended-insert=1
요거이 관건인데, 쓸데 없이 INSERT 구문이 늘어나는 것을
 막아준다. 가령
->  INSERT INTO `A` VALUES (1,10),(2,20);
 이러면 될 것을 ,
-> INSERT INTO `A` VALUES (1,10);
-> INSERT INTO `A` VALUES (2,20);
 으로 늘려준다. 이러면 하루 온 종일 도는 거다 --;;

이 3가지 옵션으로 백업을 한결과.... 놀라움을 극치 못했습니다 연습용 10기가 용량이 육박하는

데이터베이스를 보통 백업을 뜰때 30~40분 정도가 소요됬습니다(서버가 켄츠할배와 같은시기에 나온 제온..)

근데............. 그런데!!!!!!!!!! 저 3가지 옵션을 준후에는 10분 안짝으로 백업이 되는것 입니다..

놀라움을 극치 못하고 그러면 원본 포스팅에서 복원 속도도 체감상 1/10로 줄어들었다는데.......

정말이지 진짜 체감상 1/10로 줄어든 기분입니다.....하~ 이렇게 좋은 옵션이 있을줄은 생각지도 못했네요

일단 대용량 백업을 자주 뜨시는 분들이 계시면 저 옵션도 추천해드리고 실시간 백업을 요하는 분들은

Xtrabackup 솔루션을 추천드립니다 ( 증분 백업이 가능합니다! )

출처: http://dongwonme.tistory.com/entry/MySQL-대용량-백업-복원-빨리하기 [Dongwon.me]

출처: <http://dongwonme.tistory.com/entry/MySQL-%EB%8C%80%EC%9A%A9%EB%9F%89-%EB%B0%B1%EC%97%85-%EB%B3%B5%EC%9B%90-%EB%B9%A8%EB%A6%AC%ED%95%98%EA%B8%B0>

출처: http://blackbull.tistory.com/8 [음머어's 까망별]

출처: <http://blackbull.tistory.com/8>

MySQL 5.6.x Replication(MySQL 5.6 이중화)

참조

MySQL 공식문서

http://dev.mysql.com/doc/refman/5.6/en/replication.html

참고 블로그들

원리부터 설명까지 : http://blog.hibrainapps.net/130

여기도 설명 굿 : http://gywn.net/2012/02/mysql-replication-2/

여기서 설명은 대부분 MySQL 공식문서에서 Setting하는 순서와 여러 블로그 내용을 참조

Step1. Create a Data Snapshot

Replication을 시작하기전에 dump를 이용해 임포트하자.

case1) Using mysqldump

mysqldump -u root -p 'password' --all-databases --master-data=2 > dbdump.sql

mysqldump의 실행결과는 그냥 출력되기에 리다이렉트를 사용해야 한다.

--all-databases

모든 database   

--master-data

Slave가 Replication 프로세스를 시작하기전에 필요로하는 상태인 CHANGE MASTER TO를 자동적으로 추가

--master-data=1

이건 잘 모르겠다. 구글링해봥

--master-data=2

이건 sql문으로 작성된다는데 구글링해봥

그냥 --master-data 설정해놓고 찜찜해서 CHANGE MASTER TO를 그냥 해버렸다

Slave로는 다양한 방법이 있겟지만 scp를 사용해서 전송했다.

또 Slave에서는 다음과 같이 적용시켰다.

case2) Using Raw Data Files

DB가 크다면 Raw Data File들을 복사하는 것이 mysqldump를 사용하는 것 보다 효율적이다.

Step2. Master Configuration

- Enable binary logging

바뀐 데이터를 Master에서 Slaves로 보낸데 있어서 기본이기에 반드시 해야만한다.

- Establish a unique server ID

Replication group의 각각의 Server들은 고유의 Server ID를 가지고 있어야한다.

Server ID값은 1부터 65535까지의 양수가 될 수 있다. 어떻게 부여할지는 전적으로 당신의 몫

- MySQL Server를 설치하고 my.cnf나 my.ini 파일을 수정해야한다.

mysqld 섹션에 다음과 같이 추가한다.(yum으로 깔았더니 /etc/my.cnf 라는 경로를 가졌다.)

[mysqld]

log-bin=mysql-bin

server-id=1

- Debian/Ubuntu 같은 OS는 ski-networking이 "bind-address to 127.0.0.1"로 표기

-- 이 주소에 Slave의 주소나 HostName을 넣어야한다.

아래와 같이 설정했다

참고사항

※ Server-id는 설정하지 않으면 기본값은 0이다.

※ 트랜잭션들과함께 InnoDB를 이용해 Replication을 설정하는데 있어서 가능한한 최대한의 지속성과 일관성을 위해

당신은 innodb_flush_log_at_trx_commit=1 과 sync_binlog=1을 my.cnf파일에 추가해야한다.

※ skip-networking 옵션은 당신의 Replication Master에서 사용할 수 없음을 보장한다.

만일 네트워킹이 중지된다면, 당신의 Slave는 Master와 통신할 수가 없고 Replication은 실패하게 된다.   

※ Master 또한 Slave라면 my.cnf나 my.ini에 "log-slave-updates"라는 구문을 추가해야한다.

※ Binary Log를 남기게 되는 순간부터 datadir에 가보면(/var/lib/mysql)에 보면 다음과 같이 Log들이 남는다.

Step3. Slave Configuration

- Establish a unique server ID.

server-id 값은 IP주소 같은거로 생각하면된다.

이 ID들은 Replication 파트너와의 통신에서 유일하게 각각의 server instance를 구분한다.

server-id 값을 생략하면 기본값은 0이되며, Master로의 연결을 거부하게 된다.

(Step1과 똑같은 파일입니다)

※ Slave들은 binary logging을 할필요가없지만 데이터 백업이나 충돌 회복 용으로도 사용이 가능하다.

물론 또다른 Slave들을 사용하는데에도 사용이 가능하다.

※ my.cnf에 "report-host=hostname"을 넣어주면 Master에서 "show slave hosts" 명령어가 작동한다.

Step4. Create a User for Replication

Slave들이 Master에 접근하기위해서 Master의 User계정이 필요하다. 

어떤 계정이든 상관없고 REPLICATION SLAVE 권한이 필요하다.

Slave마다 다른 계정을 줄 수도 있고 같은 계정을 줄 수도 있다.

어떤 계정을 따로 만들 필요없지만

master.info에 평문으로 User name과 password가 저장된다는 것을 알고 있어야 한다.

그러므로 Replication 작업만을 위한 계정을 따로 생성할 필요가 있다.

mysql> CREATE USER 'repl'@'IP주소 or 호스트이름' IDENTIFIED BY 'slavepass';

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

Step5. Obtaining the Replication Master Binary Log Coordinates

Replication하기전에 Master의 Binary Log File의 이름과 Position(아마 Coordinates가 이건듯)을 알아야한다.

이 정보들은 나중에 Slave들이 Replication하기 전에 CHANGE MASTER TO작업에서 필요하다.

Master가 남긴 수 많은 Binary Log File들 중에 어떤 File을 어디서 부터 읽을 것이냐? 이런걸 표현하는 것 같다.

MySQL 문서를 보면 이 작업하기전에 반드시 Master에서 하고있는 모든 실행 상태를 정지하라고 한다. 내 생각이지만 계속 작업을 진행중이라면 Binary Log File이 계속 수정될 것이고 Position(Coordinates) 또한 그럴 것이기 때문이다.

mysql> SHOW MASTER STATUS;

File명과 Position을 기록하라!

아래 부터는 MySQL 문서를 대강 번역했다.

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

Replication 작업을 시작하기전에 Slave들과 동기화하길 원하는 Master의 Data들이 있다면, 반드시 Master에서의 모든 실행 상태를 정지하고

다시 실행하기 전까지 Master의 현재 Binary Log 좌표(Position)를 얻어라.

만일 실행상태를 멈출수 없다면, 데이터 dump와 당신이 사용할 마스터의 상황 정보는 match되지 않을 것이고(아다리가 안맞는다는말인듯)

Slave에서 불일치하고 퇴폐된 데이터베이스를 가지게될 것이다.

1st) Master에서 Command-line client로 접속함으로써 세션을 시작하고,

모든 테이블들을 flush하고 "FLUSH TABLES WITH READ LOCK"의 실행으로써 Write Statements들을 Block한다.

※ 만약 client로 세션을 끊으면 Lock을 풀리게 된다.

2nd) Master의 또 다른 세션으로 "SHOW MASTER STATUS"을 통해 현재 binary log파일의 이름과 위치를 확인한다.

나중에 Slave를 세팅할때 필요한다음 기록해두어야한다.

그 정보들은 Slave가 Master로부터 새로운 update의 처리를 시작하기 위해 Replication 좌표를 표현한다.

만일 Master가 binary logging enabled없이(Step2.없이) 이때까지 실행되어왔다면,

로그 파일 이름과 포지션 값들은

SHOW MASTER STATUS"과

mysqldump --master-data에서 empty값일 것이다.

(아까 --master-data가 CHANGE TO MASTER 구문을 자동으로 추가한다고 했는데

CHANGE TO MASTER 구문에서는 Binary Log File이름과 Position을 필요로한다.

자동으로 추가된 File 이름과 Position이 빈 값이라는 표현같다.)

이런 경우에는, Slave의 로그파일과 포지션들을 지정할때 당신이 필요로 할 값들은 empty string('') 값이다.

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

Step6. Start Replication!

모든 준비가 끝났다. Replication을 시작하기전에 마지막 세팅을 하면 된다.

※ 위 에서 mysqldump할때 --master-data 자동으로 추가한다는게 CHANGE MASTER TO 였다.

1) 설정을 해보자

※ 빡 침 주 의 ! ! P u t t y 로 작업 요 망 (숫 자 에 는 작 은 따 옴 표 안 붙 음 ! )

mysql> CHANGE MASTER TO

MASTER_HOST = ' IP주소 ',

MASTER_USER = ' MASTER에 접속할 DB 계정 ',

MASTER_PASSWORD = ' MASTER에 접속할 DB계정의 패스워드',

MASTER_PORT = ' MASTER가 있는 DB의 리스터 포트(MySQL은 디폴트 포드가 3306이다) ',

MASTER_LOG_FILE = ' 아까 기록해두었던 Binary Log File의 이름이다. ',

MASTER_LOG_POS = 아까 기록해두었던 Position값이다. ,

MASTER_CONNECT_RETRY = MASTER로의 접속을 하는 주기이다. 양의 정수로 단위는 초(Second)이다.

;

2) SLAVE 시작

mysql > START SLAVE;

3) 상태확인해보자

mysql > SHOW SLAVE STATUS;

※ 캡쳐가 상당히 더럽지만 핵심은 Waiting for master to send event이다.

Slave의 I/O Thread가 Master의 변경 Event를 감지하고 있는 것이다.

※ SHOW SLAVE STATUS \G; 이렇게하면 깔끔하게 나온다!! Shift + Page Down(OR UP) 으로 스크롤 업 다운

4) Master 쪽에서도 확인을 해보자.

mysql > show slaves host;

※) 만일 Slave에서 계속 접속을 시도하고 있다면?

Solution1) 방화벽을 확인(firewall-cmd로 3306포트를 풀어준다.)

중요한 점은 위에서 진행한 것처럼 해도 결국은 에러가 난다.. UUID가 겹친다. Dump로

했으면 에러가 안나는데 전체 복사를 해서 그런 것이다. Auto.cnf 파일 지우면 됩니다.

 Cloning MySQL 5.6 instances

August 23, 2013 by ronald

A tip for all those cloud users that like cloning database servers (as reported in my book Effective MySQL – Replication Techniques in Depth).

Starting with MySQL 5.6, MySQL instances have a UUID. Cloning servers to quickly create slaves will result in the following error message.

mysql> SHOW SLAVE STATUSG
...
  Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
...

The solution is simple. Clear our the file based configuration file (located in the MySQL datadir) and restart the MySQL instance.

$ rm -f /mysql/data/auto.cnf
$ service mysql restart

출처: <http://ronaldbradford.com/blog/cloning-mysql-5-6-instances-2013-08-23/>

MySQL Replication (마스터-슬레이브 동기화) 설정

MySQL 2014/04/08 17:08

선행 작업

Master에서 Slave로 동기화하기를 원하는 DB(및 Table)은 미리 Dump를 떠서 최초 1번은 Slave에 생성해 놓아야 한다.

Master 서버 설정

우선 server-id가 1로 설정되어 있는지 확인한다.

Master는 보통 1로 설정한다. 그래야 Slave에서 부가적인 설정을 할 필요가 없다.

이번엔 mysql에 접속해서 상태를 확인한다.

File, Position 값을 각각 메모해 둔다(mysql-bin.189, 91120973).

마지막으로 본 서버에 접속해서 동기화 받아갈 Slave 서버들에 권한을 주자.

*.*은 DB.Table 이고 %는 ip 모두 허용... 인데 GRANT는 익숙한 구문이므로 자세한 설명은 생략한다.

Slave 서버 설정

Master와 같이 server-id 값을 확인한다.

는 Master와 다른 값을 가져야 하므로 2로 수정하는게 좋겠다.

Slave의 mysql에 접속해서 동기화 받을 DB가 존재하는 Master 서버의 정보를 입력할 차례다.

Master에서 메모한 2개의 값을 MASTER_LOG_FILE 부분과 MASTER_LOG_POS 부분에 대입한다.

Slave가 Master에게서 제대로 동기화 받아오는지 확인해 보자.

Waiting for master to send event 문구가 표시되면 정상이다.

여기서 일단 끝인데... 조금 더 세부적으로...

모든 DB를 동기화하는 것이 아니라, 특정 DB 특정 Table만 동기화 하고 싶다면 아래와 같이 my.cnf 파일에 설정한다.

• Slave에 설정할 수도 있고 Master에 설정할 수도 있다.
• 한 라인에 여러 값을 기입할 수는 없었다. 여러 라인에 각각 지정해야 한다.
• replication-ignore-table은 동기화 받지 않을 테이블만 기록하는 설정이다.
  이 외에도 여러 설정이 존재한다(더 자세한건 구글링을).

 DB: MySQL / DB人

2007/08/14 02:09

http://seuis398.blog.me/70020889375

전용뷰어 보기

LVM은 Linux 시스템에서 디스크 Volume을 논리적으로 관리할 수 있도록 해준다.

대략적인 구조는 아래와 같다.

LVM의 기능중에 Logical Volume 스냅샷 생성 기능을 활용하면,

InnoDB 스토리지 엔진의 경우 온라인 백업(Hot Backup)을 수행할 수 있고,

MyISAM의 경우에는 몇 초 정도의 TABLE LOCK으로 온라인 백업을 수행할 수 있다. (Warm Backup)

Logical Volume의 스냅샷을 생성하면, 즉시 Logical Volume 간 물리적인 복사가 이루어 지는 것은 아니고,

스냅샷 Volume 상에 Exception Table이라는 것이 생성되어 변경된 디스크 블럭의 정보를 보관하여,

그 정보를 바탕으로 스냅샷 생성 시점의 데이터를 읽을 수 있도록 해준다.

LVM을 이용한 MySQL 스냅샷 백업을 위해서는 아래와 같은 환경이 구성되어 있어야 한다.

- Linux 시스템에 LVM이 설치되어 있어야 한다. (LVM 1, 2 모두 가능)

- MySQL의 data 디렉토리는 LVM의 Logical Volume 상에 존재해야 한다.

data 디렉토리로 사용할 Logical Volume의 크기는,

DB의 사이즈 뿐만 아니라, 스냅샷을 생성을 위한 Volume의 크기까지 고려해서 결정해야 한다.

스냅샷 Volume의 크기는 원본 Volume의 50% 정도면 충분하다.

<snapshot 백업 순서>

1. MyISAM 스토리지 엔진 사용시 테이블 락을 설정한다.

mysql> FLUSH TABLES WITH READ LOCK;

Query OK, 0 rows affected (0.01 sec)

2. 스냅샷 Volume을 생성한다.

# lvcreate --snapshot  -L 10G -n backup /dev/vg/mysqldata

lvcreate -- WARNING: the snapshot will be automatically disabled once it gets full

lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/vg/backup"

lvcreate -- doing automatic backup of "vg"

lvcreate -- logical volume "/dev/vg/backup" successfully created

현재 MySQL Data 디렉토리가 있는 Logical Volume(mysqldata)의 스냅샷을 생성하였다.

스냅샷 Volume의 이름은 backup으로 지정하였고, /dev/vg/backup 생성하였다.

(스냅샷 생성 시간은 1~2초 정도 걸렸다.)

스냅샷 생성 결과는 lvscan 명령으로 확인해 보면 된다.

#  lvscan

lvscan -- ACTIVE   Original "/dev/vg/mysqldata" [20 GB]

lvscan -- ACTIVE   Snapshot "/dev/vg/backup" [9.96 GB] of /dev/vg/mysqldata

lvscan -- 2 logical volumes with 29.96 GB total in 1 volume group

lvscan -- 2 active logical volumes

3. 1번 과정에서 테이블 락을 설정하였다면, 락을 해제한다.

mysql> UNLOCK TABLES;

Query OK, 0 rows affected (0.00 sec)

4. Snapshot Volume을 백업을 위한 새로운 MySQL 데몬의 data 디렉토리로 Mount 하고,

   mysqldump 툴을 사용하여 백업을 받는다.

# mount -t ext3 /dev/vg/backup /usr/local/mysql_backup/data/ 

# /usr/local/mysql_backup/safe_mysqld &

# /usr/local/mysql_backup/bin/mysqldump --all-databases > backup.sql

MySQL DB의 스냅샷 백업이 진행되는 동안에도, 기존 MySQL 서버는 정상적으로 서비스 되므로

백업에 영향을 받지 않고, 정상적으로 서비스를 유지할 수 있다.

하지만 스냅샷 생성을 하면 해당 시점부터 원본 Volume과 스냅샷 Volume에 대해 중복으로 I/O가 발생하며,

변경 작업이 과도하게 많이 일어나거나, 외부 스토리지가 아닌 일반적인 SCSI, SATA 디스크를 쓰는 경우,

스냅샷 유지를 위해 증가한 I/O로 인하여 퍼포먼스 저하를 일으킬 수 있으니 유의하자.

6. 백업을 위한 임시 MySQL 데몬을 종료하고, 스냅샷 Volume을 삭제한다.

# /usr/local/mysql_backup/bin/mysqladmin shutdown

# umount /dev/vg/backup

# lvremove -f /var/vg/backup

lvremove -- doing automatic backup of volume group "vg"

lvremove -- logical volume "/dev/vg/backup" successfully removed

백업이 완료된 후에는 스냅샷 Volume을 반드시 삭제해야 한다.

<장점>

- 테이블 락으로 인한 서비스 중단없이 시점 백업을 받을 수 있다. (온라인 백업)

- 리플리케이션 Slave 구성을 간편하게 할 수 있다.

<단점>

- 스냅샷 생성 후 유지하는 동안 I/O가 늘어난다.

- LVM 자체에 대한 안정성 검증(LVM 버그 등)이 필요하다. (Volume이 날라가 버린다면 낭패..)

[출처] LVM을 이용한 MySQL 스냅샷 백업|작성자 돌고래사육사

원본 위치 <http://blog.naver.com/PostView.nhn?blogId=seuis398&logNo=70020889375&beginTime=0&jumpingVid=&from=search&redirect=Log&widgetTypeCall=true&topReferer=http%3A%2F%2Fsearch.naver.com%2Fsearch.naver%3Fsm%3Dtab_hty.top%26where%3Dnexearch%26ie%3Dutf8%26query%3DLVM%2Bsnapshot>