'분류 전체보기' 카테고리의 글 목록 (8 Page)

Redis 란?? slide

[펌]

http://www.slideshare.net/krisjeong/this-is-redis-kor-slideshare?next_slideshow=1

[출처] http://blog.daum.net/smufu/4

업무때문에 스터디 하다가 스터디 하다가 세미나도 하고

너무 괜찮아 보여서 현재 서비스중인 Product에 적용을 위해서

작업중인 NoSQL되시겠다...

각설하고, 그럼 먼저 NoSQL이란 무었인가?

Not only SQL의 약자 되시겠다..

혹자는 No SQL이라고 생각할지도 모르나.. 그런 기우일랑 접어두고..

SQL만이 아닌 다른 저장소 쯤으로 이해 하면 되겠다..

여기에(http://www.slideshare.net/krisjeong/redis-intro) 내가 작성한 세미나 자료 있으니 한번 훑어 보시면 이해 하는데 큰 도움이 되리라 생각된다.

Redis는 자주 Memcached와 비교되는 in memory 저장소 이다.

Memcached의 기본적인 특징.

1. 처리 속도가 빠르다.

- 당연히 데이터가 메모리에만 저장되므로 빠르다. 즉, 속도가 느린 Disk를 거치지 않는다.

2. 데이터가 메모리에만 저장된다.

- 당연히 프로세스가 죽거나 장비가 Shutdown되면 데이터가 사라진다.

3. 만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.

- 이름에서도 느껴지듯이 Cache이다

4. 저장소 메모리 재사용

- 만료가 되지 않았더라도 더이상 데이터를 넣을 메모리가 없으면 LRU(Least recently used) 알고리즘에 의해 데이터가 사라진다.

그래서, 보통 대형 포털들에서 Static page, 또는 검색 결과 등을 캐쉬하는데 많이 사용한다.

그런데!!!!

왜!!!!! REDIS가 자꾸 Memchche와 비교되는가?

눈치들 채셨겠지만 거의 98%이상 Memchche와 동일한 기능을 제공한다.(비슷 하니까 비교 하겠지~~~)

그럼 다른 2%는 뭐냐?

이제부터 설명 들어간다..

Memcached	REDIS
처리 속도가 빠르다. - 당연히 데이터가 메모리에만 저장되므로 빠르다. 즉, 속도가 느린 Disk를 거치지 않는다.	처리 속도가 빠르다. - 당연히 데이터가 메모리+Disk에 저장된다. 그러나, 속도는 Memcached와 큰 차이가 없다.
데이터가 메모리에만 저장된다. - 당연히 프로세스가 죽거나 장비가 Shutdown되면 데이터가 사라진다.	데이터가 메모리+Disk에 저장된다. - 프로세스가 죽거나 장비가 Shutdown되더라도 Data의 복구가 가능하다.
만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다. - 이름에서도 느껴지듯이 Cache이다	만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다. - 동일한 기능을 지원한다.
저장소 메모리 재사용 - 만료가 되지 않았더라도 더이상 데이터를 넣을 메모리가 없으면LRU(Least recently used) 알고리즘에 의해 데이터가 사라진다.	저장소 메모리 재사용 하지 않는다. - 명시적으로만 데이터를 제거할 수 있다.
문자열만 지원	문자열, Set, Sorted Set, Hash, List등의 다양한 Data Type을 지원.

.. 오늘은 여기까지 하고..

사내 세미나용으로 작성한 자료 첨부 하니 참고 하세요..

REDIS intro and how to use redis from Kris Jeong

저작자표시 비영리

'Redis' 카테고리의 다른 글

[redis] dump 파일 이용하여 json 파일 convert (2)	2018.03.29
[redis] 콘솔에서 redis 데이터 확인 (0)	2018.03.23
[Redis] Replication / Check 방법 (0)	2018.02.19
[Redis] 로그인 시 127.0.0.1:6379: Connection refused (2)	2018.02.19
[펌] [Redis] Redis란 ? 2번째 (1)	2016.10.11

Git 이란 것을 몇달전에 알게 되었다.

한참 포켓몬고에 빠져 있을 때, 매크로 관련한 글을 우연히 보고

해당 글을 토대로 구글링한 결과!!!

사람들이 Git 이란 곳에 올려놓고 source 공유 하는 것을 보게 되었다.

코딩이란 것을 처음부터 했었던 것이고...그래서 어떤 언어든 어려움이나 거부감은 없었다.

그래서 어떤 언어로 개발되어도 이해하고 건들려고 노력을 한다. 필요하다면!!!;;;;

Anyway ~ Git을 알게 되었지만 사용법을 몰라 고생하다가 쉽게 누군가가 올려 놓은 파일만 가져다가,

xml 수정하여서 사용하다 보니 Git이 또 자연스럽게 멀어졌다.

최근에 회사 동료가 Git을 잠시 언급하길레 이때다 싶어서 물어봤더니 Source Tree 라는 툴을 이용하면 쉽게

접근 가능하다는 말에 바로 Source Tree 설치하였더니..

정말 쉽게 GUI로 접근 가능했다..물론 예전에 Git을 접할 때도 프로그램을 설치를 시도 했는데 알지 못하는 오류가

지속적으로 발생해서 포기했었다.

아래는 동영상 강의 블로그인데 강의 1개 정도만 봐도 쉽게 사용할 수 있다.

https://opentutorials.org/course/1492/8039

나도 따로 언급 안하는 이유는 Source Tree 라는 툴을 설치 후에 (그전에 Git 에 가입하는 것도 필수) 강의 한편만 봐도

쉽게 따라 할 수 있기 때문이다.

아래 이미지는 GIt에 오픈되어 있는 소스에 대한 것에 내가 Import 한 부분이고,

두번째는 내가 개발한 파이썬 스크립트를 올려 놓은 부분이다.

아무래도 Tracking 이 쉬운 게 장점이고...Private 을 위해서는 금액을 지불해야 하는 점이 단점이 아닌가 싶다..

나도 초보라 이정도만 알고 있다...;;

저작자표시 비영리

오랜만에 DB Guide net 에 접속했다.

그 중 Index 사용 여부에 대한 가이드 글을 읽고 느낀점에 대해서 정리해 보았다.

먼저 읽은 글의 본문은 아래와 같다.

이병국의 개발자를 위한 DB 이야기: 튜닝(31회)

개발자를 위한 DB 튜닝 실전(1편)

http://www.dbguide.net/knowledge.db?cmd=view&boardUid=192095&boardConfigUid=19&boardStep=&categoryUid=196

고작 1편보고 왜 작성하느냐...가 아니라 그동안 잠시 잊고 있었던 부분을 다시 짚는 부분과 함께,

예시 쿼리들을 직접 손으로 작성하면서 이렇게 변경해도 되는 구나 ....하기 위해서 작성하는 부분이다.

* 인덱스를 사용하는 것은 언제나 옳다???

- 답은 No 이다. 누구나 알겠지만 Full scan이 성능상 더 효과적인 경우가 있기 때문이다.

아래의 쿼리에 대해서 보자

SELECT SUM(CASE WHEN 활동구분 = ‘방문’ THEN 1 ELSE 0 END) AS 방문횟수

SUM(CASE WHEN 활동구분 = ‘우편’ THEN 1 ELSE 0 END) AS 우편횟수

SUM(CASE WHEN 활동구분 = ‘전화’ THEN 1 ELSE 0 END) AS 전화횟수

SUM(CASE WHEN 활동구분 = ‘SMS’ THEN 1 ELSE 0 END) AS SMS건수

FROM 영업활동 -- 3000만 건 이상의 대용량 테이블(10년 활동 보관)

WHERE 활동일자 BETWEEN ? AND ? -- 조회 구간 최대 1년(인덱스 있음)

AND 활동구분 IN (‘방문’, ’우편’, ’전화’, ‘SMS’)

- 테이블 전체 건수의 1/10에 해당하는 300만 건을 추출

위의 쿼리를 인덱스를 사용하면 엄청난 시간이 소요될 수 있다. 하지만 /*+ FULL(영업활동) */ 힌트를 사용하여 Full Scan을 하면 더 적게 소요될 수 있다.

이 말은 즉 데이터를 scan 시 Block 단위로 읽게(I/O) 된다. Index 를 이용하게 되면 Random access 를 하게 된다. 하지만 full scan을 하게 되면 Seqential read 하게 된다. 물론 다 그런거는 아니겠지만 대부분 Random access 하게 되면 Single block I/O 가 되며, Seqential read 하게 되면 Multi block I/O를 하게 되어 훨씬 I/O양을 줄일 수 있는 효과를 가져올 수 있다.

물론 이 내용들은 머릿속에서 엇박자로 알고 있는 부분들이라 다시 정리하게 되는 것 같다. (이해는 가지만 또 설명하게 되면 어버버 되는 상황??ㅠ)

자세한 내용은 아래에서 읽으면서 정리하는 것을 추천한다.

- I／O 효율화 원리

http://wiki.gurubee.net/pages/viewpage.action?pageId=29065463

해당 내용을 이해한다면 왜 Index를 사용안하고 Full table scan 이 더 효율적인지 이해할 수 있을 것이다.

두번째 내용은 Group by 사용과 성능 이슈 (이 부분은 기존 dbguide.net 내용을 펌~~~)

업무를 진행하다 보면 group by를 많이 사용하게 된다...내 의지와 상관없이...통계 때문일 것이다.

SELECT A.부서코드

, B.부서명

, SUM(A.판매수량) AS 판매수량

, SUM(A.판매금액) AS 판매금액

FROM 판매실적 A -- 1천만 건 이상의 대용량 테이블(10년치 판매 실적)

, 부서 B -- 수백 건 미만의 부서코드

WHERE A.부서코드 = B.부서코드

AND A.판매일자 BETWEEN ? AND ? -- 조회 구간 최대 1주일(인덱스 있음)

GROUP BY A.부서코드, B.부서명

ORDER BY A.부서코드, B.부서명

여기서는 데이터 구간이 총 데이터의 1/100 , 10만건 이하이기에 인덱스를 활용해야 한다고 한다.

또한, 부서명은 order by 절에 영향을 주지 않으며, 부서 테이블은 오로지 부서명을 조회하는 용도로만 사용한다.

부서 테이블은 부서명 조회 용도이며 부서테이블과 관련한 조건절이 없다.

SELECT A.부서코드

, (SELECT 부서명 FROM 부서 WHERE 부서코드 = A.부서코드) AS 부서명

, SUM(A.판매수량) AS 판매수량

, SUM(A.판매금액) AS 판매금액

FROM 판매실적 A -- 1천만 건 이상의 대용량 테이블(10년치 판매 실적)

WHERE A.판매일자 BETWEEN ? AND ? -- 조회 구간 최대 1주일(인덱스 있음)

GROUP BY A.부서코드

ORDER BY A.부서코드

위와 같이 변경하면 부서 테이블에 대한 접근 빈도수를 최대한 줄일 수 있음.

Group by 절의 수행 이전에 부서 테이블을 접근하였으나

개선된 쿼리는 group by 절의 수행 이후에 부서 테이블을 접근하므로 접근 빈도수가 대폭 줄어든 효과

Order by 절의 선행컬럼에 부서명이 있거나, 조건절에 부서 테이블의 컬럼이 있다면 Outer Join 방식으로 변경 불가능

SELECT A.부서코드

, B.부서명

, SUM(A.판매수량) AS 판매수량

, SUM(A.판매금액) AS 판매금액

FROM 판매실적 A -- 1천만 건 이상의 대용량 테이블(10년치 판매 실적)

, 부서 B -- 수백 건 미만의 부서코드

WHERE A.부서코드 = B.부서코드

AND A.판매일자 BETWEEN ? AND ? -- 조회 구간 최대 1주일(인덱스 있음)

AND B.사용여부 = ‘Y’ -- 현재 시점에 사용하는 부서코드

GROUP BY B.부서명, A.부서코드

ORDER BY B.부서명, A.부서코드

아래와 같이 인라인 뷰 방식의 쿼리로 개선 가능

SELECT A.부서코드

, B.부서명

, A.판매수량

, A.판매금액

FROM

(

SELECT 부서코드

, SUM(판매수량) AS 판매수량

, SUM(판매금액) AS 판매금액

FROM 판매실적 -- 1000만 건 이상의 대용량 테이블(10년치 판매 실적)

WHERE 판매일자 BETWEEN ? AND ? -- 조회 구간 최대 1주일(인덱스 있음)

GROUP BY 부서코드

) A, 부서 B -- 수백 건 미만의 부서코드

WHERE A.부서코드 = B.부서코드

AND B.사용여부 = ‘Y’ -- 현재 시점에 사용하는 부서코드

ORDER BY B.부서명, A.부서코드

부서 테이블에 대한 접근 빈도수를 최대한 줄일 수 있었으며, Group by 절의 수행 이후에 부서 테이블을 접근하는 부분이라 접근 빈도수도 줄어드는 효과

하지만, 최종 집계된 부서의 개수가 부서코드 테이블의 전체 개수의 1/100 이상이라면 아래의 쿼리처럼 힌트절 조정을 통하여 성능 개선을 추가적으로 가능

첫번째 쿼리와 같이 Full 로 변경함으로써 성능 효과 개선 가능

SELECT /*+ FULL(B) */

A.부서코드

, B.부서명

, A.판매수량

, A.판매금액

FROM

(

SELECT 부서코드

, SUM(판매수량) AS 판매수량

, SUM(판매금액) AS 판매금액

FROM 판매실적 -- 1000만 건 이상의 대용량 테이블(10년치 판매 실적)

WHERE 판매일자 BETWEEN ? AND ? -- 조회 구간 최대 1주일(인덱스 있음)

GROUP BY 부서코드

) A, 부서 B -- 수백 건 미만의 부서코드

WHERE A.부서코드 = B.부서코드

AND B.사용여부 = ‘Y’ -- 현재 시점에 사용하는 부서코드

ORDER BY B.부서명, A.부서코드

만약 조건절의 판매일자 조회 구간이 한 달 이상이라면 이번에도 인덱스를 사용치 않는 방법으로 아래와 같이 힌트를 이용해 변경 가능

SELECT /*+ FULL(A) FULL(B) */

A.부서코드

, B.부서명

, A.판매수량

, A.판매금액

FROM

(

SELECT 부서코드

, SUM(판매수량) AS 판매수량

, SUM(판매금액) AS 판매금액

FROM 판매실적 -- 1000만 건 이상의 대용량 테이블(10년치 판매 실적)

WHERE 판매일자 BETWEEN ? AND ? -- 조회 구간 최대 1주일(인덱스 있음)

GROUP BY 부서코드

) A, 부서 B -- 수백 건 미만의 부서코드

WHERE A.부서코드 = B.부서코드

AND B.사용여부 = ‘Y’ -- 현재 시점에 사용하는 부서코드

ORDER BY B.부서명, A.부서코드

조회 구간이 한달 이상이라면 대규모의 집계 처리를 의미하므로 두 테이블 모두 인덱스를 타는 것보다는 타지 않는 것이 더 선능에 좋을 것.

Group by 절의 어떠한 형식이나 어떠한 조건에 따라서 성능 개선의 방법은 다양하게 다를 수 있다.

2번째 내용들은 이해를 하기보다는 정리 수준이라 쿼리 개발 때 참고해서 설계하는 것이 좋을 듯 싶다.

저작자표시 비영리

'Oracle > DBA' 카테고리의 다른 글

[Oracle] Process / Session 모니터링 (0)	2016.01.17
[펌][ORACLE] ORA-에러 (0)	2015.12.22
[Oracle] Index monitoring (0)	2015.12.14
[Oracle] Partition Local Index 테스트 (0)	2015.12.02
[ORACLE] ASM 에 Datafile 추가 (1)	2015.11.25

MySQL 관련 Log 종류에 대해서 다시 정리해 보았다.

Binary Log 관련하여 추가 정리 및 Parameter 정리는 더 추가 해야겠다.

아래 내용들은 역활에 대해서 많이들 알고 있으며 평소에도 자주 보는 것들이다.

이것보다 더 자세한 Parameter 를 검색해서 정리하여 추가해 봐야겠다.

1. Error Log

- log_error 파라미터에 경로 정의

- 경로를 정의하지 않으면 daradir 파라미터에 설정된 경로에 *.err 로 생김

- MySQL 이 시작하는 과정과 관련된 정보성 및 에러 메시지 저장

- 마지막으로 종료할 때 비정상적으로 종료된 경우 나타나는 InnoDB의 트랜잭션 복구 메시지

- innodb_force_recovery 파라미터를 0보다 큰 값으로 설정하고 재시작 추천

- 쿼리 처리 도중에 발생하는 문제에 대한 에러 메시지

- 비정상적으로 종료된 컨넥션 메시지(Aborted connection)

- max_connect_errors 시스템 변수 값이 터무니 없이 낮을 경우 발생할 수도 있음

- 네트워크 문제일 경우도 있음

- InnoDB의 모니터링 명령이나 상태 조회 명령("Show Engine Innodb Status") 의 결과 메시지

- MySQL의 종료 메시지

2. General Log file

- MySQL 서버에서 실행되는 쿼리를 기록

- 쿼리가 실행되기 전에 MySQL 이 쿼리 요청을 받으면 바로 기록하기 때문에 쿼리 실행 중 에러가 발생해도 로그파일에 기록

- 5.1.12 이전에는 "general-log" 이며, 이상에서는 "general_log_file" 로 파라미터 정의

- 5.1 이상에서는 쿼리 로그 파일이 아닌 테이블에 저장하도록 설정이 가능 -> log_output 파라미터에 의해 결정

- general log 영구 적용

$ vi /etc/my.cnf

general_log = 1

general_log_file = /var/log/mysql_general.log

$ service mysqld restart

- mysql> set global general_log = off;

3. Slow Query log

- log_query_time 파라미터를 이용하여 초 단위로 설정 하여 이상의 시간이 소요된 쿼리가 모두 기록

- 쿼리가 정상적으로 실행이 완료 되어야 Slow Query log에 기록될 수 있음

(정상적으로 실행이 완료됐고 실행하는 데 걸린 시간)

- slow 관련 설정은 Dynamic 으로 set global 명령으로 재시작 없이 수정 가능

mysql> show variables like 'slow%';

mysql> show variables like 'long%';

mysql> show variables like 'log%';

mysql> set global show_query_log = ON;

mysql> set global show_query_log = OFF;

mysql> set global long_query_time = 10;

ex) 5.1 미만

long_query_time = 1

log_slow_queries = /var/log/mysql-slow.log

ex) 5.1 이상

log-output = File 또는 Table

slow-query-log = 1

long_query_time = 10

slow_query_log_file = /var/log/mysql-slow.log

log-bin=/home/mysql_log/bin_log/bin # 빈로그 저장 설정 및 저장할 디렉토리 지정

binlog_cache_size = 2M # binlog cache 사이즈

max_binlog_size = 50M # bin로그 최대 파일 사이즈

expire_logs_days = 10 # 보관기간

- 인덱스를 사용하지 않는 쿼리 추출용 옵션 변수 on/off

mysql> log_queries_not_using_indexes = off

#==========================================================================================================================================

# Time : 110202 12:13:14 => 쿼리 종료 시간

# User@Host: root[root] @ localhost [] => 쿼리 실행한 사용자

# Query_time : 15.407663 => 수행시간 Lock_time : 0.000198 => Update문을 실행하기 위해 테이블 락을 기다렸다는 의미 Row_sent: 0 =>쿼리 결과의 몇건을 클라이언트로 보냈는지 표시 Rows_examined : 5 => 쿼리가 처리되기 위해 몇건의 데이터를 검색 했는지 카운트

Update tab set fd=100 where fd=10;

#==========================================================================================================================================

- MyISAM 이나 Memory Storage Engine 에서는 테이블 단위의 잠금을 사용하기에 select 쿼리도 1초 이상 소요될 가능성 있음.

- InnoDB도 select 쿼리에 대해 lock_time 이 0이 아니는 경우가 생기지만 MySQL Engine 레벨에서 설정한 테이블 잠금 때문일 가능성이 있음

- 사용자가 " Lock Table 테이블 " 명령으로 획득한 잠금에 의해서 생긴 슬로우 쿼리는 로그에 기록되지 않음

4. Binary Log와 Relay Log

- 바이너리 로그파일은 마스터 MySQL 서버에 생성되고 릴레이 로그는 슬레이브 MySQL 서버에 생성된다는 것 말고는 바이너리 로그와 릴레이 로그 파일의 내용이나 포맷은 동일

- 바이너리 로그파일에는 Select 등의 문장은 포함되지 않고 DML 쿼리가 기록

- mysqlbinlog 를 이용하여 바이너리 파일을 텍스트로 변형 가능

ex) mysqlbinlog binlog.000012 > binlog.sql

ex) Slave와 Master 동기화 방법

- mysql> stop slave stuats;

mysql> change master to master_log_file = 'binlog.000013', master_log_pos = '443232';

mysql> start slave status;

[추가내용]

저작자표시 비영리

'MySQL' 카테고리의 다른 글

[MySQL] mysqllbinlog event_type: 19 (0)	2016.10.20
[MySQL] Binary log 정리 (0)	2016.10.18
[MySQL] Query 관련 수정 (Index) (0)	2016.09.29
[펌][MySQL] 대용량 테이블의 경우 성능 개선을 위한 10 가지 방안 (0)	2016.08.03
[MySQL] Stored Procedure 장단점 (2)	2016.07.19

Login 통계 관련하여 설계를 진행 했다.

그 동안 Login / out 정보를 테이블로 각기 다르게 추가를 하였다.

그러다 보니 Login/out 정보를 제대로 관리가 되지 않았다.

그래서 아래와 같이 설계 하였다.

create table LoginResult (

PlayerID varchar(50),

Name varchar(30),

WorldNum int(2) unsigned,

CurrentChannel int(2) unsigned,

LoginIP varchar(15) NOT NULL,

PayPlayCheck enum('0','1') NOT NULL default '0',

LoginDatetime datetime NOT NULL default '0000-00-00 00:00:00',

LogoutDatetime datetime NOT NULL default '0000-00-00 00:00:00',

Status enum('0','1','2') NOT NULL default '0'

);

create index idx_Login_PlayerID on LoginResult (PlayerID,Name);

create index idx_Login_Status on LoginResult (Status desc,Name);

간단하다.

- Login 할 때는 Insert / out 할때는 Update를 진행 한다.

Status

0	Logout 상태일 때
1	Login 상태 일 때
2	Login 후 정상적으로 out 하지 않았을 때

이렇게 구성한 후 일일 평균 / 특정 구간 동안의 평균을 낸 쿼리를 다음과 같이 구성하였다.

SELECT

WorldNum,

D.Name,

CurrentChannel,

SUM(CASE WHEN STATUS='1' THEN 1 END) cntNow,

SUM(CASE WHEN DATE_FORMAT(LoginDatetime, '%Y-%m-%d') = DATE_FORMAT(NOW(), '%Y-%m-%d') THEN 1 END) cntCon,

SEC_TO_TIME

(AVG

(CASE WHEN

STATUS IN ('0','1')

AND DATE_FORMAT(LoginDatetime, '%Y-%m-%d') = DATE_FORMAT(NOW(), '%Y-%m-%d')

THEN IF (DATE_FORMAT(LogoutDatetime, '%Y-%m-%d') = '0000-00-00', SEC_TO_TIME(UNIX_TIMESTAMP(NOW())- UNIX_TIMESTAMP(LoginDatetime)),

SEC_TO_TIME(UNIX_TIMESTAMP(LogoutDatetime)- UNIX_TIMESTAMP(LoginDatetime)))

END)

) AS t

FROM USERINFO.LoginResult,DARKEDEN.WorldInfo D

WHERE

DATE_FORMAT(LoginDatetime, '%Y-%m-%d') >= SUBDATE(NOW(), INTERVAL 1 MONTH)

AND WorldNum = D.ID

GROUP BY WorldNum, CurrentChannel

ORDER BY WorldNum, CurrentChannel

위와 같이 구성하면 다음과 같은 실행 계획이 나온다.

Possible_keys 가 null 인 것을 보면 Index 를 사용하지 않는 것을 확인 할 수 있다.

여기서 빨간색으로 하이라이트 한 것을 확인 가능하다.

Index를 사용하지 못하는 경우가 몇가지가 있다.(가장 기본으로 알고 있어야 하는 것 중 하나로 난 생각한다)

그 중 한가지가 조건절을 함수로 변경하는 경우 Index를 사용 못하게 된다.

다음과 같이 변경해 보자

SELECT

WorldNum,

D.Name,

CurrentChannel ,

sum(case when Status='1' then 1 end) cntNow ,

sum(case when date_format(LoginDatetime, '%Y-%m-%d') = date_format(now(), '%Y-%m-%d') then 1 end) cntCon ,

sec_to_time( avg( case when Status in ('0','1') and date_format(LoginDatetime, '%Y-%m-%d') = date_format(now(), '%Y-%m-%d') then if ( date_format(LogoutDatetime, '%Y-%m-%d') = '0000-00-00' ,SEC_TO_TIME(unix_timestamp(now())-unix_timestamp(LoginDatetime)) ,SEC_TO_TIME(unix_timestamp(LogoutDatetime)-unix_timestamp(LoginDatetime)) ) end ) )as t

FROM USERINFO.LoginResult ,DARKEDEN.WorldInfo D

WHERE LoginDatetime >= SUBDATE(now(), INTERVAL 1 month)

AND WorldNum = D.ID

GROUP BY WorldNum, CurrentChannel

ORDER BY WorldNum, CurrentChannel

함수를 빼버렸다.

사실 나도 왜 저렇게 DATE_FORMAT 사용 했는지 모르겠다....습관도 아닐텐데...특정 날짜의 구간을 구하다 보니 반자동으로 DATE_FORMAT 를 사용했는 듯 싶다.

다음과 같이 확인해 볼 수 있다.

하지만 rows 수가 늘어난 것을 확인 가능하다......이건 아니잖아....ㅠ

나의 튜닝 목표 중 하나가 row 수를 줄이는 것이다.(랜덤 I/O 도 줄이는 것이다)

옵티마이저가 선택하는 것이니 이유가 있을 것이다.......OTL

저작자표시 비영리

'MySQL' 카테고리의 다른 글

[MySQL] Binary log 정리 (0)	2016.10.18
[MySQL] Log 정리 (0)	2016.10.05
[펌][MySQL] 대용량 테이블의 경우 성능 개선을 위한 10 가지 방안 (0)	2016.08.03
[MySQL] Stored Procedure 장단점 (2)	2016.07.19
[펌][MySQL] Warning: Using a password on the command line interface can be insecure. (0)	2016.07.18

1. Global Cache (Query Cache?? / SP에서 사용되는???) :

- Oracle 에서는 Library Cache에서 쿼리들에 대한 Plan 을 보유한다. 또한, LRU 알고리즘을 이용하기 때문에 사용이 잘 안되느 쿼리들에 대해서는 메모리에서 밀려나게 된다. MySQL에서는 개념이 조금 다른듯...정리하자.

이참에 설정 값들에 대해서도 정리를 해놓자. my.cnf 에 설정하는 변수들에 대한 정보

- SP 는 실행과 동시에 session 단위로 메모리 할당한다고 하는데, Oracle 도 Procedure가 실행되면 관련 session 이 생긴다. 물론 모니터링하면 User는 Oracle로 뜬다. SP 가 실행되면 생기는 현상에 대해서 Detail 하게 정리가 필요하다.

2. found_rows

아래 내용을 의미하는 걸까?

https://blog.asamaru.net/2015/09/11/using-sql-calc-found-rows-and-found-rows-with-mysql/

- Oracle에서는 index를 추가하거나 변경을 하게 되면 기존에 잘 동작하던 쿼리들도 실행 계획이 변경되기도 한다. 또한 통계정보를 임의로 수집하는 경우 실행 계획이 변경되는 경우도 있다. 그래서 11g 에서부터는 "지연 적용?"의 개념으로 기존과 달라지는 부분을 확인할 수 있는 좋은 기능이다.

역시 검색하면 욱짜 선생님 블로그가 제일 눈에 띈다.

참고하면 좋을 듯 싶다.

http://ukja.tistory.com/95

3. MySQL 의 격리 수준

이 부분은 이해하고 넘어가는 수준으로 알고 있었다.

"개발자와 DBA를 위한 Real MySQL" - 위키북스 의 191쪽을 확인하면 된다.

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SERIALIZABLE

4가지 인데, 각각의 설명이 잘 나와 있으니 이것만 보고 정리해도 될 듯 싶다.

참고로 InnoDB 는 REPEATABLE READ 이다 (3번째..ㅋㅋㅋ이건 알고 있었다..몇번째라는것과 대략 Commit 전후로 상황들...그림으로 이해한거라 말로 설명을 못한 부분이 어쩌면 제대로 모른다는 뜻이겠지....예전에 누군가가 말로 설명 못하는거면 모른다고 이야기 했던게 떠오른다.....ㅠㅠ)

4. log 종류 및 복제 구축을 위한 binlog 관련 설정 정리("개발자와 DBA를 위한 Real MySQL" - 위키북스 - 79page)

이외에도 생각나면 하나씩 추가하면서 정리 해야겠다.

DBA는 공부할 것이 많아서 알면 알수록 새롭다. 그래서 지루할 틈이 없다..하지만 모르면 모를수록 할게 없는게 DB 인 듯 싶다.

하던것만 장애 안생기면 상관 없으니 말이다.....

오늘도 No Pain No Gain.!!!

저작자표시 비영리

'Life' 카테고리의 다른 글

지난 추석 인사 (0)	2016.09.20
요즘 근황 16.07.15 (0)	2016.07.15
필요 테스트 및 공부해야 될 내용 (0)	2016.07.04
누군가에게 제안하기 전에.. (0)	2016.07.01
블로그의 의미 (0)	2016.03.14

지금까지 백업을 진행 했다면,

반대로 복구가 필요한 경우가 생긴다.

대부분의 블로그나 심지어 Percona 사이트에서도 아래와 같이 복구를 진행 한다.

아래는 복구 관련 메뉴얼이다.

https://www.percona.com/doc/percona-xtrabackup/2.3/innobackupex/incremental_backups_innobackupex.html

innobackupex --copy-back BASE-DIR

BASE-DIR 는 백업을 진행한 폴더를 뜻한다.

즉, 백업을 진행하고 나면 백업 폴더내 2016-09-20_11-40-34와 같은 폴더가 생긴다.(날짜_시간으로 폴더가 생김)

이렇게 하면 my.cnf 내 BASEDIR 에 있는 내용을 참고하여 해당 폴더에 복구를 진행하게 된다.

하지만, 문제는 BASEDIR 에 해당하는 디렉토리가 비어 있어야 한다. 비어 있지 않으면 에러가 발생한다.

160920 15:33:41 innobackupex: Starting the copy-back operation

IMPORTANT: Please check that the copy-back run completes successfully.

At the end of a successful copy-back run innobackupex

prints "completed OK!".

innobackupex version 2.4.4 based on MySQL server 5.7.13 Linux (x86_64) (revision id: df58cf2)

Original data directory /home/DATABASE/Default_DB is not empty!

하지만 말이 쉬워서 그렇지 해당 폴더를 비우게 되면 DB 운영을 중단해야 하는 경우가 발생한다.

운영해야 되는 상황에서는 힘든 경우가 발생한다.

그래서 여러 옵션을 찾아보고 시도를 했으나 번번히 실패했다.

내가 강구한 방법은 cnf 파일을 수정하는 것이다.

하지만, cnf 파일을 수정하기에는 위험하기에 /etc/my.cnf 를 백업한 후 백업한 파일을 수정하고 해당 수정 파일을 바라보도록 설정하였다.

(역시, 안될때에는 잠시 쉬면서 다른 방안 찾는것이.....ㅎ)

[root@DBTEST02:/home/backup/game/2016-09-20_11-40-34]# cp /etc/my.cnf /etc/my_backup.cnf

my_backup.cnf 내 BASEDIR 변수에 자신이 복구하고자 하는 위치의 정보를 설정

기존 /home/DATABASE/Default_DB를 /home/DATABASE/InnoDB/Game3로 변경

datadir = /home/DATABASE/InnoDB/Game3

[root@DBTEST02:/home/backup/game/2016-09-20_11-40-34]# innobackupex --defaults-file=/etc/my_backup.cnf --copy-back /home/backup/game/2016-09-20_11-40-34

160920 16:37:17 innobackupex: Starting the copy-back operation

IMPORTANT: Please check that the copy-back run completes successfully.

At the end of a successful copy-back run innobackupex

prints "completed OK!".

innobackupex version 2.4.4 based on MySQL server 5.7.13 Linux (x86_64) (revision id: df58cf2)

160920 16:37:17 [01] Copying ibdata1 to /home/DATABASE/InnoDB/Game3/ibdata1

160920 16:37:19 [01] ...done

160920 16:37:19 [01] Copying ./performance_schema/events_waits_summary_by_host_by_event_name.frm to /home/DATABASE/InnoDB/Game3/performance_schema/events_waits_summary_by_host_by_event_name.frm

160920 16:37:19 [01] ...done

160920 16:37:19 [01] Copying ./performance_schema/table_lock_waits_summary_by_table.frm to /home/DATABASE/InnoDB/Game3/performance_schema/table_lock_waits_summary_by_table.frm

160920 16:37:19 [01] ...done

....

160920 16:37:22 [01] Copying ./DARKEDEN/WeekItemGive.frm to /home/DATABASE/InnoDB/Game3/DARKEDEN/WeekItemGive.frm

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/SkullObject.frm to /home/DATABASE/InnoDB/Game3/DARKEDEN/SkullObject.frm

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/UserIPInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/UserIPInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/SetItemOptionInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/SetItemOptionInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/EffectHoodlumStigma.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/EffectHoodlumStigma.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/FasciaInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/FasciaInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/ETCInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/ETCInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/VampireETCInfo.frm to /home/DATABASE/InnoDB/Game3/DARKEDEN/VampireETCInfo.frm

160920 16:37:22 [01] ...done

160920 16:37:22 [01] Copying ./DARKEDEN/TunningOptionRatioInfo.ibd to /home/DATABASE/InnoDB/Game3/DARKEDEN/TunningOptionRatioInfo.ibd

160920 16:37:22 [01] ...done

160920 16:37:22 completed OK!

이렇게 하면, 정상적으로 복구된 파일들을 확인할 수 있다.

하지만, 여기서 추가로 /etc/my.cnf 에 포트를 추가로 설정 및 복구된 파일들의 권한을 mysql로 변경해 준다.

이후, "mysqld_multi start 포트" 로 실행 후 자신이 복구하고자 하는 데이터를 복구 진행하면 된다.

정리

1. cnf 파일 백업 및 백업파일 BASEDIR 수정(복구를 원하는 폴더로 설정)

2. innobackupex --defaults-file=/etc/my_backup.cnf(BASEDIR 수정한파일) --copy-back /home/backup/game/2016-09-20_11-40-34(백업한 폴더)

3. 복구가 완료된 폴더에 권한을 mysql 로 수정

4. 복구를 위해 복구 파일을 DB로 올리기 위해 my.cnf 에 multi start 로 추가 (포트 추가- Clone DB)

5. mysqld_multi start 포트

6. 복구 확인

이렇게 mysql clone DB??? 를 진행해 보았다.

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] Backup 방법2 (추가 full backup) (0)	2016.09.20
[Xtrabackup] Backup 방법 ( Full / Incremental) (2)	2016.09.13
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 (0)	2016.09.08

지난 innobackupex 명령어를 단순히 따라 하는 것에서 벗어나

하나씩 저희 회사에 맞게 변경을 하고 있습니다.

이게 진정 회사를 위한 공부겠죠..?

각설하고...

지난 명령어는 아래와 같습니다.

[root@DBTEST02:/root]# innobackupex --user=DB유저명 --password=비밀번호--socket=/tmp/mysql_8003.sock /home/backup/game/

나름 저희 회사에 맞게 변경한다고 한 것이지만 여기서 빼놓고 간 부분이 있습니다.

위와 같이 진해을 하면 Default DB 의 위치를 backup 한 다는 것을..

잠시 /etc/my.cnf 를 확인해 보면

[mysqld]

user = mysql

basedir = /usr/local/mysql

datadir = /home/DATABASE/Default_DB

tmpdir = /usr/local/mysql/DB/tmp

datadir 가 Default DB 위치다.

그래서 위의 innobackupex 를 하면 port 가 8003 인 곳의 datadir 가 아닌 Default 위치의 데이터가 백업 되는 것을 확인할 수 있다.

그렇다면, 어떻게 진행해야 될까?

아래와 같이 defaults-file 를 선언해 주면 된다.

[root@DBTEST02:/root]#innobackupex --defaults-file=/home/DATABASE/InnoDB/Game2/ --user=root --password= --socket=/tmp/mysql_8003.sock /home/backup/game/

여기서 --defaults-file 은 앞쪽에 위치해야 한다. 혹시나 해당 변수를 뒤에다 선언하면 에러가 발생한다.

xtrabackup: Error: --defaults-file must be specified first on the command line

제대로 백업이 되는지는 로그만 봐도 알 수 있다.

아래 보면 해당 위치의 DB까지 모두 백업 되는 것을 확인할 수 있다.

[root@DBTEST02:/home/backup/game]# innobackupex --defaults-file=/home/DATABASE/InnoDB/Game2/ --user=root --password= --socket=/tmp/mysql_8003.sock --databases=DARKEDEN /home/backup/game/

160920 10:52:00 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.

At the end of a successful backup run innobackupex

prints "completed OK!".

160920 10:52:00 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/tmp/mysql_8003.sock' as 'root' (using password: NO).

160920 10:52:00 version_check Connected to MySQL server

160920 10:52:00 version_check Executing a version check against the server...

160920 10:52:00 version_check Done.

160920 10:52:00 Connecting to MySQL server host: localhost, user: root, password: set, port: 0, socket: /tmp/mysql_8003.sock

Using server version 5.6.32-debug-log

innobackupex version 2.4.4 based on MySQL server 5.7.13 Linux (x86_64) (revision id: df58cf2)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /home/DATABASE/InnoDB/Game2/

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup: innodb_log_group_home_dir = ./

xtrabackup: innodb_log_files_in_group = 2

xtrabackup: innodb_log_file_size = 50331648

InnoDB: Number of pools: 1

160920 10:52:00 >> log scanned up to (21174002)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 442 for DARKEDEN/ShoulderArmorInfo, old maximum was 0

160920 10:52:01 >> log scanned up to (21174002)

160920 10:52:02 >> log scanned up to (21174002)

160920 10:52:03 >> log scanned up to (21174002)

160920 10:52:04 [01] Copying ./ibdata1 to /home/backup/game/2016-09-20_10-52-00/ibdata1

160920 10:52:04 >> log scanned up to (21174002)

160920 10:52:05 >> log scanned up to (21174002)

160920 10:52:05 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/ContributeDegree.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/ContributeDegree.ibd

160920 10:52:06 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/OustersWristletObject.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/OustersWristletObject.ibd

160920 10:52:06 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/SubInventoryInfo.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/SubInventoryInfo.ibd

160920 10:52:06 [01] ...done

160920 10:52:06 [01] Copying ./DARKEDEN/HighEnchantLog.ibd to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/HighEnchantLog.ibd

...

160920 10:52:10 [01] Copying ./DARKEDEN/VampireETCInfo.frm to /home/backup/game/2016-09-20_10-52-00/DARKEDEN/VampireETCInfo.frm

160920 10:52:10 [01] ...done

160920 10:52:10 Finished backing up non-InnoDB tables and files

160920 10:52:10 [00] Writing xtrabackup_binlog_info

160920 10:52:10 [00] ...done

160920 10:52:10 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...

xtrabackup: The latest check point (for incremental): '21174002'

xtrabackup: Stopping log copying thread.

.160920 10:52:10 >> log scanned up to (21174002)

160920 10:52:10 Executing UNLOCK TABLES

160920 10:52:10 All tables unlocked

160920 10:52:10 Backup created in directory '/home/backup/game/2016-09-20_10-52-00'

MySQL binlog position: filename 'Bin_Log.000051', position '120'

160920 10:52:10 [00] Writing backup-my.cnf

160920 10:52:10 [00] ...done

160920 10:52:10 [00] Writing xtrabackup_info

160920 10:52:10 [00] ...done

xtrabackup: Transaction log of lsn (21174002) to (21174002) was copied.

160920 10:52:11 completed OK!

incremental 백업도 비슷하게 진행하면 될 것 같다.

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???) (2)	2016.09.20
[Xtrabackup] Backup 방법 ( Full / Incremental) (2)	2016.09.13
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 (0)	2016.09.08

모두들 추석 연휴 잘 보내셨습니까!!!

역시 유부남은 추석 연휴도 바쁘네요-ㅎㅎ아버지가 이런 말씀을 하시더군요..

"내 아들놈이 이제는 아빠가 되어 있더라..."

ㅎㅎ참 많은 뜻이 숨어 있네요-

이 말이 머리로 먼저 이해 하기 이전에 가슴에서 이해가 되더군요.

정확히 이해가 되기 보다는 가슴에서 알아 듣는 듯한 느낌이..

세계 일주를 하는 친구놈한테서도 메시지가 오더군요. 추석 잘 보내라고-ㅎ

"니가 먼저 연락이 안와서 내가 한다..."

로 시작 되는 카톡..ㅎ

이 말은 가슴에 화살이 슝...ㅋㅋㅋㅋ미안해-ㅎㅎ

언제부턴가 주위 사람을 챙기는 습관을 바쁘다는 이유로 버리고 있더군요.

어느 하나를 포기하고 하나를 얻는 다는거...그로 인해서 서운한 감정들..미안한 감정들..

꼭 포기를 하지 않고 한걸음 더 움직이면 되는 것을...

저는 변명을 하고 있네요-

저작자표시 비영리

'Life' 카테고리의 다른 글

[20160927] 공부해야 될 내용 (0)	2016.09.27
요즘 근황 16.07.15 (0)	2016.07.15
필요 테스트 및 공부해야 될 내용 (0)	2016.07.04
누군가에게 제안하기 전에.. (0)	2016.07.01
블로그의 의미 (0)	2016.03.14

Xtrabackup 을 사용하는 방법에 대해 테스트 해 보았다.

마음도 심숭생숭하여 빨리 진행될 일을 너무 느긋하게 진행 되었다.

InnoDB 를 이용한 백업 으로써 Incremental backup 도 함께 해 보았다.

Incremental 에 대한 개념은 Oracle Rman 백업과 같은 개념으로 생각해도 될 것 같다.

Full Backup 의 경우 데이터의 양이 증가할 수록 시간도 오래 걸린다.

이에 따라, 변경된 데이터만 백업을 함으로서 백업의 시간을 획기적으로 단축할 수 있다.

이후 복구 시에는 Full backup 으로 복구 후 나머지 변경된 데이터만 Incremental 백업을 가지고 적용함으로써

무손실로 복구를 할 수 있다.

물론 이 개념들은 모두 Oracle Rman 백업 / 복구 때의 지식으로 Xtrabackup 의 경우 다를 수도 있다.

추가적으로 MySQL LSN 이 있는데

* lsn 이 log sequence number 의 약자로써 전체 DB의 버전 정보를 뜻함

- 변경 사항이 발생할 때마다 번호가 증가하여 채번

* Oracle로 따져보면 SCN 와 비슷

(DB Link를 많이 사용하다 보면 SCN 관련하여 full 이 차서 DB down 되는 현상이 있엇던 것이 기억난다...11g 등에서 어느정도 해결되었다고는 했는데..)

1. Full Backup

* innobackupex 명령어를 이용하여 user 와 passwd 를 입력하여 진행

* Port를 따로 지정한 경우나, 멀티로 띄우는 경우 --socket 옵션을 지정하여 명시

* /home/backup/game/ 으로 어느 곳에 백업을 할 것인지 명시를 하게 되면, 자동으로 '2016-09-09_16-58-17' 처럼 날짜 시간으로 디렉토리 자동생성

* config 파일을 지정시 --defaults-file=MY.CNF 처럼 명시 가능

[root@DBTEST02:/root]# innobackupex --user=DB유저명 --password=비밀번호--socket=/tmp/mysql_8003.sock /home/backup/game/

....

160909 16:58:19 Executing UNLOCK TABLES

160909 16:58:19 All tables unlocked

160909 16:58:19 Backup created in directory '/home/backup/game/2016-09-09_16-58-17'

MySQL binlog position: filename 'Bin_Log.000049', position '7396794'

160909 16:58:19 [00] Writing backup-my.cnf

160909 16:58:19 [00] ...done

160909 16:58:19 [00] Writing xtrabackup_info

160909 16:58:19 [00] ...done

xtrabackup: Transaction log of lsn (1600627) to (1600627) was copied.

160909 16:58:19 completed OK!

2. Preparing a full backup with innobackupex

* 백업을 생성한 후에 해당 백업 데이터는 아직 restore 할 수 있는 상태가 아님.

* rollback 하는 commit되지 않은 transaction이나 재실행 되어야 하는 transaction이 있을 수 있음

* 미완된 작업들을 정리하는 작업을 함으로서 데이터 파일의 일관성을 유지하는 작업을 Prepare작업

* 해당 작업이 정상적으로 완료 되면 백업된 데이터 파일들은 이제 복구용으로 사용 가능

* innobackupex를 사용하여 백업 파일의 일관성을 맞추기 위해 --apply-log 옵션을 사용하면 된다. 백업된 위치를 옵션으로 주어 작업을 진행한다.

* Prepare 작업 동안에 백업이 진행되는 동안에 생성된 Transaction 내용을 담은 로그 파일안에 커밋된 Transaction 들을 재실행을 한다. 그리고, 그것들 중에 커밋 구문이 실행되지 않은 transaction들은 롤백된다.

이 작업을 완료하게 되면, 모든 정보들은 테이블 스페이스에 저장되고, 새로운 로그 파일이 생성된다.

내부적으로는 xtrabackup --prepare 를 2번 실행하게 된다.

Prepare 작업 시에 좀 더 빨리 진행하고 싶다면 --use-memoryh 옵션을 사용할 수 있다.(Default 100mb)

* innobackupex --apply-log --use-memory=4G /home/backup/game/2016-09-09_16-58-17

※ Transaction 의 일관성을 유지하기 위해서 innobackupex 의 Full backup을 진행한 후 완료된 작업에 대해(생성된 백업 디렉토리) --apply-log 옵션을 추가하여 한번 더 진행하면 파일의 일관성을 맞출 수 있다.

* 아래는 apply-log 를 진행 한 후의 메시지 들이다.

3. Incremental backup

- Incremental backup에 대한 개념은 초반에 살짝 언급한 바와 같이 백업 이후의 변경된 내용들에 대해서만 백업을 진행

- 기준은 LSN 의 정보를 보고 추적하여 진행

* --incremental-basedier 의 경우 마지막으로 full backup 한 위치에 대한 데이터 내용을 뜻하는 것으로, 해당 내용들을 확인 후 incremental backup을 진행하기 위한 기본 정보이다.

* 풀백업이든 증분 백업이든 최종 위치를 작성 후에 진행해야지만, 증분백업을 제대로 진행할 수 있다.

* innobackupex --incremental --user=DB유저ID --password=DB유저 패스워드 --socket=/tmp/mysql_8003.sock /home/backup/game/ --incremental-basedir=/home/backup/game/2016-09-12_10-59-37/

* incremental 백업을 완료 하게 되면 xtrabackup_checkpoints 파일이 생기는데 해당 내용을 확인해 보면 아래와 같다

backup_type = incremental

from_lsn = 1601102

to_lsn = 1601102

last_lsn = 1601102

compact = 0

recover_binlog_info = 0

* 혹시라도 lsn 을 알고 있다면, 해당 번호가지고 수동으로 incremental 를 진행할 수 있다.

(시작되는 번호를 명시하면 자동으로 마지막까지 진행 한다.)

innobackupex --incremental --user=DB유저ID --password=DB유저 패스워드 --socket=/tmp/mysql_8003.sock /home/backup/game/ --incremental-lsn=1600627

[root@DBTEST02:/home/backup/game/2016-09-12_11-26-40]# ll

total 108

-rw-r----- 1 root root 418 Sep 12 11:26 backup-my.cnf

-rw-r----- 1 root root 81920 Sep 12 11:26 ibdata1.delta

-rw-r----- 1 root root 44 Sep 12 11:26 ibdata1.meta

-rw-r----- 1 root root 23 Sep 12 11:26 xtrabackup_binlog_info

-rw-r----- 1 root root 117 Sep 12 11:26 xtrabackup_checkpoints

-rw-r----- 1 root root 563 Sep 12 11:26 xtrabackup_info

-rw-r----- 1 root root 2560 Sep 12 11:26 xtrabackup_logfile

[root@DBTEST02:/home/backup/game/2016-09-12_11-26-40]# vi xtrabackup_checkpoints

backup_type = incremental

from_lsn = 1600627

to_lsn = 1601102

last_lsn = 1601102

compact = 0

recover_binlog_info = 0

* backup_type = incremental 이라고 적혀 있으며 lsn 관련된 내용을 보면 위치를 확인할 수 있다.

* 반드시 백업이 완료 된 후

* incremetal 실행 결과 xtrabackup_checkpoints 파일을 확인해 보는 습관이 필요할 듯 싶다.

해당 문서는 아래 블로그를 참고로 하였습니다.

http://ani2life.com/wp/?p=1290

http://mysqldba.tistory.com/240

저작자표시 비영리

'MySQL > Xtrabackup' 카테고리의 다른 글

[Xtrabackup] innobackupex Full backup 복구 (MySQL Clone DB???) (2)	2016.09.20
[Xtrabackup] Backup 방법2 (추가 full backup) (0)	2016.09.20
[XtraBackup] Precona XtraBackup 설치 on CentOS 5.5 & MySQL 5.6.32 (0)	2016.09.08

Louis.Kim 의 제 3막