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


[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??? 를 진행해 보았다.

반응형

지난 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 백업도 비슷하게 진행하면 될 것 같다.


반응형

+ Recent posts