'RDB/mariadb'에 해당되는 글 13건

where 조건절에 OR 연산을 사용한다면 반영 전에 실행계획을 반드시 확인해야한다.
보통은 거의 쓰지 않거나 최소한으로 쓰는 것이 좋고 대용량테이블을 건드린다면 성능이슈가 발생할 가능성이 크다.
이럴경우 해결할 수 있는 방법은 오라클은 힌트가 있고 mysql은 이전에는 union all로 쪼개서 병합하는 방식을 썼는데
mysql 5.1 이후부터(maridb는 5.0부터던가?..) 인덱스중에 느린 편이지만 index_merge라는 것을 쓸 수 있다.

옵티마이져가 equal 연산(=AND)이 아니더라도 인덱스끼리 분리 추출해서 병합해서 return 해주는 방식인데 인덱스 성능중에 느린 축이라서 무시했는데..

-->이번에 대용량쿼리 튜닝하면서 MariaDB 10.3.8 의 index_merge 성능에 놀라 따로 정리하기로 한다.

1. index_merge 지원여부확인

- mysql or mariadb 버전에서 인덱스병합을 지원하는지 확인해본다.

[maria@localhost ~]$ mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.3.8-MariaDB-log MariaDB Server

MariaDB [(none)]> select @@optimizer_switch\G;
*************************** 1. row ***************************
@@optimizer_switch: index_merge=on // 지원확인 O
				   ,index_merge_union=on 
				   ,index_merge_sort_union=on 
				   ,index_merge_intersection=on 
				   ,index_merge_sort_intersection=off
				   ,engine_condition_pushdown=off
				   ,index_condition_pushdown=on
				   ,derived_merge=on
				   ,derived_with_keys=on
				   ,firstmatch=on
				   ,loosescan=on
				   ,materialization=on
				   ,in_to_exists=on
				   ,semijoin=on
				   ,partial_match_rowid_merge=on
				   ,partial_match_table_scan=on
				   ,subquery_cache=on
				   ,mrr=off
				   ,mrr_cost_based=off
				   ,mrr_sort_keys=off
				   ,outer_join_with_cache=on
				   ,semijoin_with_cache=on
				   ,join_cache_incremental=on
				   ,join_cache_hashed=on
				   ,join_cache_bka=on
				   ,optimize_join_buffer_size=off
				   ,table_elimination=on
				   ,extended_keys=on
				   ,exists_to_in=on
				   ,orderby_uses_equalities=on
				   ,condition_pushdown_for_derived=on
				   ,split_materialized=on

2. index_merge란?

보통 인덱스 접근방법 = 타입(type) 은 하나의 인덱스만 사용한다.
이와 달리 index_merge 는 2개 이상의 인덱스를 이용해 각각의 검색결과를 만들어낸 후 그 결과를 병합하는 처리방식이다. 하지만 여러 번의 경험을 보면 이름만큼 그렇게 효율적으로 작동하는 것 같지는 않았다. index_merge 접근방식에는 다음과 같은 특징이 있다.

1) 여러 인덱스를 읽어야 하므로 일반적으로 range 접근방식보다 효율성이 떨어진다.
2) AND와 OR 연상이 복잡하게 연결된 쿼리에서는 제대로 최적화되지 못할 때가 많다. -> 데이터 분포도에 따라 옵티마이져가판단함
3) 전문 검색 인덱스(fulltext)를 사용하는 쿼리에서는 index_merge가 적용되지 않는다.
4) index_merge 접근방식으로 처리된 결과는 항상 2개 이상의 집합이 되기 때문에 그 두 집합의 교집합이나 합집합 또는 중복 제거와 같은 부가적인 작업이 더 필요하다.

#실행계획 인덱스 타입 빠른 순서
system > const > eq_ref > ref > fulltext > ref_or_null > unique_subquery > index_subquery > range > index_merge > index > ALL
->all 빼놓곤 다 인덱스스캔이고 뒤로 갈수록 성능이 떨어진다.

#실행계획 extra 부분
1.Using intersect(...)
각각의 인덱스를 사용할 수 있는 조건이 AND로 연결된 경우 각 처리 결과에서 교집합을 추출해내는 작업을 수행했다는 의미이다.

2.Using union(...)
각 인덱스를 사용할 수 있는 조건이 OR로 연결된 경우 각 처리 결과에서 합집합을 추출해내는 작업을 수행했다는 의미다.

3.Using sort_union(...)
Using union과 같은 작업을 수행하지만 Using union으로 처리될 수 없는 경우(OR로 연결된 상대적으로 대량의 range 조건들)이 방식으로 처리된다. Using sort_union 과 Using_union의 차이점은
Using sort_union은 PK만 먼저 읽어서 정렬하고 병합한 후에야 비로소 레코드를 읽어서 반환할 수 있다는 것이다.

Using union()과 Using sort_union()은 둘다 충분히 인덱스를 사용할 수 있는 조건이 OR로 연결된 경우에 사용된다.
Using union()은 대체로 동등 비교(Equal)처럼 일치하는 레코드 건수가 많지 않을 때 사용되고, 각 조건이 크다 또는 작다와 같이 상대적으로 많은 레코드에 일치하는 조건이 사용되는 경우
Using sort_union()이 사용된다. 하지만 실제로는 레코드 건수에 거의 관계없이 각 WHERE 조건에 사용된 비교조건이 모두 동등조건이면 Using union()이 사용되며, 그렇지 않으면 Using_sort_union()이 사용된다.

#알고리즘 참고
 Mysql 내부적으로 이 둘의 차이는 정렬 알고리즘에서 싱클 패스 정렬 알고리즘과 투 패스 정렬 알고리즘의 차이와 같다. Using union()이 싱글패스 정렬 알고리즘을 사용한다면,
Using sort_union()은 투패스 정렬 알고리즘을 사용한다. (Real Mysql 334P)

3. 성능튜닝사례

1) where 조건절 확인

WHERE B.SEQ = '16'
AND A.xxx_YN != 'Y'
AND ( C.xx_KEY = '40' OR ( C.xxx_KEY = '518' AND C.xxx_CD != '01' ) )
AND ( ( A.xx_CD IN ( '1', '3' ) AND C.xxxx_CD NOT IN ( '88' ) AND C.xxx_KEY = '401' )
OR ( A.xxx_CD = '2' AND C.xxxx_CD IN ( '01', '09' ) AND C.xxx_KEY = '1518' )
OR ( CI.xxx_KEY = '48' AND A.xxxx_CD NOT IN ( '9' ) ) )

--> 다른팀에서 성능튜닝을 문의해서 확인해보니 굳이 실행계획 안봐도 성능안나오게 생겼다.

복잡한 or연산을 분리해서 테이블 rows건수 보고 union all로 풀려다가 데이터 분포도가 좋은 컬럼이 인덱스가 안되어있어 추가하고

or연산의 index_merge 성능을 한번 확인해보기로 했다.

2) 인덱스 추가후 실행계획 확인

풀스캔이 사라지면서 rows수는 50만건에서 2000여건으로 많이 줄였고, 수행시간은 3초에서 0.05초로 줄었다.

-> 와우 index_merge가 이렇게 빨랐었나?ㅎ

3. 결론

최고의 튜닝은 버전업! 단 버그만 없다면 (MariaDB 10.2 쓰는거 다 10.3이상으로 올려야겠다...;)

데이터 분포도가 좋은 컬럼은 or연산에서 느린 index_merge라도 엄첨 빠르다.

끝~

참조 : Real Mysql

하루 단위 풀백업이 1.4T가 넘어가면서 xtrabackup에 압축이슈가 발생하였다.
xtrabackup은 2시간내외로 끝나는데 tar 압축은 10시간이 넘어가다보니 좀더 나은 방법을 검토 중에
좋은 참조 문서를 발견하였다.

일단 증분백업을 검토해봤지만.. 아무래도 관리하기 귀찮다. 어쩔 수 없이 증분백업데이터를 한번은 merge 해야하고, 관리이슈가 크기 때문에 풀백업을 유지하고
압축시간을 줄일 수 있는 방법을 찾던 중에 pigz라는 것을 찾게 되었다.

오라클의 parallel 힌트같이 압축중에 데이터 용량이 큰 파일을 만났을 시 process를 늘려서 한번에 처리하는 똑똑한 압축툴이다. tar과 같이 쓸 수 있어 기존로직을 많이 변경하지 않아도 되서 테스트를 진행하였다.

###parallel 압축 gz 방식 검토 ###
#서버에 pigz가 설치되어있는지 확인

rpm -qa | grep pigz

#pigz-2.3.4-1.el6.x86_64.rpm 설치

[root@ temp]# rpm -Uvh pigz-2.3.4-1.el6.x86_64.rpm
경고: pigz-2.3.4-1.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
준비 중...               ########################################### [100%]
   1:pigz                   ########################################### [100%]

#1) 기존 압축방식과 비교
1-1) tar.gz
tar -cvzf test.tar.gz backup
#시작 17:10분

#종료 17:52분

--> 42분

1-2) tar pigz
tar 명령어에 외부 압축프로그램 바로 지정하는 방식을 사용한다면,
tar -I pigz -cvf blah.tar.gz blah blah 압축하기
tar -I pigz -xvf blah blah blah 압축풀기

#바로테스트진행
tar -I pigz -cvf test2.tar.gz backup

#top 확인

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 

5454 root 20 0 1813m 17m 584 S 1247.8 0.1 12:29.46 pigz
5453 root 20 0 113m 1272 1044 D 18.8 0.0 0:12.01 tar
358 root 20 0 0 0 0 S 2.3 0.0 6:35.84 kswapd1
357 root 20 0 0 0 0 S 1.7 0.0 11:00.23 kswapd0
5490 webadmin 20 0 15424 1660 912 R 0.7 0.0 0:00.44 top
--> cpu 1247%...ㄷㄷㄷ 상용서비스에서 쓸 수 있을까;

#시작 17:54분 

#종료 18:04분

--> 10분

#1-3) Process 설정

-p, --processes n Allow up to n compression threads (default is the
number of online processors, or 8 if unknown)

-->cpu의 Core 수를 조절할 수 있게 설정된다. 정확하게는 하이퍼스레딩 개수이다.

예를들어 물리 core가 8 core라면 top으로보면 1600% 까지 쓸 수 있다고 보면된다.

하지만 실제로 확인해보면 오버클럭되서 max는 1880% 정도까지 나온다.

Compress a directory using tar:
tar cf - path/to/directory | pigz > filename.tar.gz

#1-4) pigz 압축률 테스트
tar -cvf - backup | pigz -9 -p 4 > test2.tar.gz

#top 확인

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
591 root 20 0 322m 4152 592 S 404.9 0.0 29:37.29 pigz
590 root 20 0 113m 1284 1052 S 3.3 0.0 0:10.82 tar
357 root 20 0 0 0 0 S 0.7 0.0 11:18.11 kswapd0
229 root 20 0 0 0 0 S 0.3 0.0 20:33.63 kblockd/3
-->압축률 (9: 성능이 좋은것, 설정은 12까지 있는데 이건 잘 사용 안하는 거 같다)
압축해서 데이터 사이즈는 줄어들었지만 너무느리다.

# 압축률 default 로 테스트
tar -cvf - backup | pigz -6 -p 6 > test2.tar.gz

--> 압축률 default , process 6
--> 수행시간 10분

데이터 사이즈는 tar.gz로 압축할 떄와 비슷하지만 수행시간을 1/4로 줄였다.
core도 서버와 DB가 사용할 부분을 남겨놓고 설정했고
가장 원하는 방식으로 테스트를 마쳤다.

#반영

개발DB의 실제 반영은 xtrabackup에서 지원하는 --stream =  tar을 사용하여 굳이 백업 디렉토리를 만들지 않고

압축파일로만 관리하도록 반영하였다.

-> 이후 10.4로 DB upgrade를 하면서 한번 더 확인했는데

mariabackup에서는 --stream = tar은  지원하지않는다. 대신 xbstream 이라는 압축포멧을 default로 지원한다.

참조 : mariadb.com/kb/en/mariabackup-options/#-stream

/usr/bin/innobackupex \
--host=127.0.0.1 \
--user=root \
--password='비번' \
--ibbackup=xtrabackup \
--no-lock \
--stream=tar ./ | pigz -p 6 > backup.tar.gz

상용DB는 위와 같은 방식이 아니라 장애시 바로 점검이 가능하도록 백업디렉토리와 압축파일을 분리하여 관리하고 있다.

실제 상용에 적용할 때는 --no-lock 옵션을 사용하기 때문에 바로 압축하는 방식을 사용하지 못하였다. apply log를 합친 다음에 압축을 하여야 하기 때문이다.

1) xtrabackup -> 2) applay_log merge -> 3) pigz 압축 -> 4) transfer

# pigz 적용스크립트

tar -cf - 압축디렉토리 | pigz -p 6 > 압축파일이름.tar.gz
// -cvf로 하면 압축파일을 볼수있는데 압축파일이 TB 단위다 보니 이거 넣으면 확실히 더 느리다 걍 뺀다.

#pigz Man page
pigz --version (return code: 0)
pigz 2.4

tar --use-compress-program="pigz -p 4" -cvf mvno-test.tar.gz backup

pigz --help (return code: 0)
Usage: pigz [options] [files ...]
will compress files in place, adding the suffix '.gz'. If no files are
specified, stdin will be compressed to stdout. pigz does what gzip does,
but spreads the work over multiple processors and cores when compressing.

Options:
-0 to -9, -11 Compression level (level 11, zopfli, is much slower)
--fast, --best Compression levels 1 and 9 respectively
-b, --blocksize mmm Set compression block size to mmmK (default 128K)
-c, --stdout Write all processed output to stdout (won't delete)
-d, --decompress Decompress the compressed input
-f, --force Force overwrite, compress .gz, links, and to terminal
-F --first Do iterations first, before block split for -11
-h, --help Display a help screen and quit
-i, --independent Compress blocks independently for damage recovery
-I, --iterations n Number of iterations for -11 optimization
-J, --maxsplits n Maximum number of split blocks for -11
-k, --keep Do not delete original file after processing
-K, --zip Compress to PKWare zip (.zip) single entry format
-l, --list List the contents of the compressed input
-L, --license Display the pigz license and quit
-m, --no-time Do not store or restore mod time
-M, --time Store or restore mod time
-n, --no-name Do not store or restore file name or mod time
-N, --name Store or restore file name and mod time
-O --oneblock Do not split into smaller blocks for -11
-p, --processes n Allow up to n compression threads (default is the
number of online processors, or 8 if unknown)
-q, --quiet Print no messages, even on error
-r, --recursive Process the contents of all subdirectories
-R, --rsyncable Input-determined block locations for rsync
-S, --suffix .sss Use suffix .sss instead of .gz (for compression)
-t, --test Test the integrity of the compressed input
-v, --verbose Provide more verbose output
-V --version Show the version of pigz
-Y --synchronous Force output file write to permanent storage
-z, --zlib Compress to zlib (.zz) instead of gzip format

1) xtrabackup 장애

- 사업팀의 긴급요청으로 테스트기를 구축할 여유없이 바로 상용기에 임시테이블 생성 및 대용량 FILE을 insert 할 수 밖에 없는 상황이 생김

xtrabackup은 일단위로 풀백업하는 상황이었고, 여기에 대용량 파일을 insert 하다가

xtrabackup과 충돌하여 행이 걸렸다.

추후에 테스트기에서 데이터 insert 성공후 확인한 정보는 해당 파일사이즈는 약 100G, insert시 인덱스까지 생성하다보니 실제 tablespace의 파일사이즈는 150G정도임 수행시간은 약 16시간정도였다.

2) Lock관련 로그

MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
+-----------+-------------------------+---------------+---------------------+--------------+---------------------+
| THREAD_ID | LOCK_MODE               | LOCK_DURATION | LOCK_TYPE           | TABLE_SCHEMA | TABLE_NAME          |
+-----------+-------------------------+---------------+---------------------+--------------+---------------------+
|  20362137 | MDL_INTENTION_EXCLUSIVE | NULL          | Global read lock    |              |                     |
|  20362137 | MDL_SHARED_READ         | NULL          | Table metadata lock | MDLDB        | TB_COM_xxx_xxxx       |
|  20362137 | MDL_SHARED_READ         | NULL          | Table metadata lock | MDLDB        | TB_STA_MC_xxx_xxxx |
|  20310373 | MDL_SHARED_WRITE        | NULL          | Table metadata lock | MDLDB        | TMP_LOAD_xxx_xxxx   |
|  20362137 | MDL_SHARED_READ         | NULL          | Table metadata lock | MDLDB        | TB_MDL_xxx_xxxx     |
|  20362137 | MDL_SHARED_WRITE        | NULL          | Table metadata lock | MDLDB        | TB_STA_SVC_xxx_xxxx  |
+-----------+-------------------------+---------------+---------------------+--------------+---------------------+

select * from information_schema.innodb_trx;

MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
+-----------+------------------+---------------+---------------------+--------------+-------------------+
| THREAD_ID | LOCK_MODE        | LOCK_DURATION | LOCK_TYPE           | TABLE_SCHEMA | TABLE_NAME        |
+-----------+------------------+---------------+---------------------+--------------+-------------------+
|  20310373 | MDL_SHARED_WRITE | NULL          | Table metadata lock | MDLDB        | TMP_LOAD_xxx_xxxx |
+-----------+------------------+---------------+---------------------+--------------+-------------------+
1 row in set (0.03 sec)

MariaDB [(none)]> select * from information_schema.innodb_trx;

----------+--------------+---------------------+-----------------------+------------------+------------+---------------------+-----------+---------------------+-------------------+-------------------+------------------+-----------------------+-----------------+-------------------+-------------------------+---------------------+-------------------+------------------------+----------------------------+---------------------------+------------------+----------------------------+
| trx_id   | trx_state    | trx_started         | trx_requested_lock_id | trx_wait_started | trx_weight | trx_mysql_thread_id | trx_query | trx_operation_state | trx_tables_in_use | trx_tables_locked | trx_lock_structs | trx_lock_memory_bytes | trx_rows_locked | trx_rows_modified | trx_concurrency_tickets | trx_isolation_level | trx_unique_checks | trx_foreign_key_checks | trx_last_foreign_key_error | trx_adaptive_hash_latched | trx_is_read_only | trx_autocommit_non_locking |
+----------+--------------+---------------------+-----------------------+------------------+------------+---------------------+-----------+---------------------+-------------------+-------------------+------------------+-----------------------+-----------------+-------------------+-------------------------+---------------------+-------------------+------------------------+----------------------------+---------------------------+------------------+----------------------------+
| 70509851 | ROLLING BACK | 2019-11-09 07:06:36 | NULL                  | NULL             |   52876634 |            20310373 | NULL      | rollback            |                 0 |                 1 |                1 |                  1136 |               0 |          52876633 |                       0 | READ COMMITTED      |                 1 |                      1 | NULL                       |                         0 |                0 |                          0 |
+----------+--------------+---------------------+-----------------------+------------------+------------+---------------------+-----------+---------------------+-------------------+-------------------+------------------+-----------------------+-----------------+-------------------+-------------------------+---------------------+-------------------+------------------------+----------------------------+---------------------------+------------------+----------------------------+
1 row in set (0.07 sec)

3) 장애원인파악

xtrabackup과 충돌로 행이걸려 제대로 insert가 안되고 innodb에서 자체 롤백중이었다.

show processlist; 에서 확인한 결과는 killed 상태였고 여기서 kill 명령어는 제대로 수행되지 않았다.

xtrabackup 로그를 확인해보니 apply_log 데이터를 쓰면서 백업물리파일의 sequence를 저장하다가 임시테이블의 트랜젝션이 끝나지 않아 무한대기에 루프를 돌고 있는 상황이었다.

xtrabackup apply_log)

InnoDB: Doing recovery: scanned up to log sequence number 7058198598656 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 7058198892824 (100%)
InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 278336723 row operations to undo
InnoDB: Trx id counter is 70558720
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: xtrabackup: Last MySQL binlog file position 7587824, file name ./mysql-bin.000001
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Rolling back trx with id 70509851, 278336723 rows to undo
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...

InnoDB: Progress in percents: 1InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: page_cleaner: 1000ms intended loop took 31280119ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
InnoDB: 5.7.13 started; log sequence number 7058198892824
InnoDB: xtrabackup: Last MySQL binlog file position 7587824, file name ./mysql-bin.000001

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Waiting for 1 active transactions to finish
InnoDB: Waiting for 1 active transactions to finish
InnoDB: Waiting for 1 active transactions to finish
InnoDB: Waiting for 1 active transactions to finish
InnoDB: Waiting for 1 active transactions to finish
InnoDB: Waiting for 1 active transactions to finish
InnoDB: Waiting for 1 active transactions to finish

....

ps -ef에서 kill -9를 하고 싶었으나.. 구글링 결과 끔찍한 결과를 초래할 수 있다는 경고가 많았다. clean up까지는 최장 72시간이 걸릴수도 있다고 하였고, 시스템이 다운되는 것을 염려하여 일단 innodb 의 자체 롤백을 믿어보기로하고 기다렸다.

#주의점 : session을 Kill 하게 되면 SMON에 의해서 Clean-up되는 시간이 필요함

SQL에서 Session Kill 후에 OS에서 kill -9 명령어를 또 다시 날리게 되면 SMON을 Kill하게 되므로 DB가 Shutdown 됨

#참조사이트

https://otsteam.tistory.com/58

4) 장애해결

기다리고.. 기다렸다. 시스템 성능저하는 어쩔 수 없었고..다행이도 실시간 데이터 merge에는 문제없었다. 

50시간 정도 걸려 rollback이 끝났다. 기다리는 게 맞긴 맞다. ㅠ 살았다...

문제가 된 임시테이블은 Drop하였고, xtrabackup은 apply-log 프로세스는 innodb의 롤백이 완료되었으나 여전히 끝나지않고 행 걸려있어 Kill 시켰다.

MariaDB [(none)]> show processlist;
+----------+-------------+-----------------------+-------+---------+------+--------------------------+------------------+----------+
| Id       | User        | Host                  | db    | Command | Time | State                    | Info             | Progress |
+----------+-------------+-----------------------+-------+---------+------+--------------------------+------------------+----------+
|        3 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|        1 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge coordinator | NULL             |    0.000 |
|        4 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|        2 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|        5 | system user |                       | NULL  | Daemon  | NULL | InnoDB shutdown handler  | NULL             |    0.000 |
| 18731450 | mdlbat      | 172.31.8.77:36718     | MDLDB | Sleep   |   11 |                          | NULL             |    0.000 |
| 20426479 | mdlbat      | 172.31.8.77:44052     | MDLDB | Sleep   |   84 |                          | NULL             |    0.000 |
20 rows in set (0.00 sec)

.....

+----------+-------------+-----------------------+-------+---------+------+--------------------------+------------------+----------+
20 rows in set (0.00 sec)

--> 장애복구완료

대용량 처리는 웬만하면 상용기에서 하지말자...

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 116393
Server version: 10.2.15-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show processlist;
+--------+-------------+-----------------------+-------+---------+------+--------------------------+------------------+----------+
| Id     | User        | Host                  | db    | Command | Time | State                    | Info             | Progress |
+--------+-------------+-----------------------+-------+---------+------+--------------------------+------------------+----------+
|      1 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge coordinator | NULL             |    0.000 |
|      2 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|      4 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|      3 | system user |                       | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|      5 | system user |                       | NULL  | Daemon  | NULL | InnoDB shutdown handler  | NULL             |    0.000 |
| 116393 | root        | localhost             | NULL  | Query   |    0 | init                     | show processlist |    0.000 |
+--------+-------------+-----------------------+-------+---------+------+--------------------------+------------------+----------+
MariaDB [(none)]>

mariadb 10.0.14에서 10.2.15로 업그레이드 후 처음 보는 프로세스가 5개가 떠 있다.

저게 뭐하는 걸까 찾아보았다.

1.InnoDB purge coordinator
2.InnoDB purge worker
3.InnoDB shutdown handler

1. InnoDB purge coordinator / worker

- InnoDB purge coordinator 및 worker는 InnoDB에서 purge 작업을 진행하기 위해 필요한 프로세스 입니다.
InnoDB의 purge 기능이란 데이터의 변경이 발생하였을 때, 다른 트랜잭션의 읽기 일관성(MVCC)을 위해 변경 전의 데이터를 롤백 세그먼트에 기록해두게 되는데, 이 데이터가 더 이상 필요하지 않게 될 경우 해당 세그먼트를 재사용하기 위해 청소하는 것을 의미합니다.
Purge를 수행하게 되면 쿼리의 성능 저하를 방지할 수 있고, 변경 및 삭제된 자료들이 차지하고 있는 디스크 공간을 확보할 수 있게 됩니다.
InnoDB purge worker 프로세스는 그런 purge 작업을 실제로 수행하는 프로세스이며, InnoDB purge coordinator는 언제 어떤 worker가 purge 작업을 수행할지 관리하는 프로세스입니다.

InnoDB purge coordinator -> rollback segment 재사용(purge) 스케줄러

InnoDB purge worker -> rollback segment 재사용(purge) 수행 프로세스

2. InnoDB shutdown handler

InnoDB shutdown handler 프로세스는 InnoDB가 종료 시 안정성을 높이기 위해서 추가된 프로세스입니다.
해당 프로세스는 InnoDB 종료 전 buffer flush와 같이 반드시 수행되어야 하는 일들을 모두 수행 후 shutdown이 될 수 있도록 해줍니다

InnoDB shutdown handler -> InnoDB 종료시 buffer flush 프로세스(데이터 안정성 up)

참조사이트

: https://support.s-core.co.kr/hc/ko/articles/360000537081-MariaDB-10-2-%EB%B6%80%ED%84%B0-%EC%83%9D%EA%B8%B4-%EC%83%88%EB%A1%9C%EC%9A%B4-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EB%93%A4%EC%9D%80-%EB%AD%94%EA%B0%80%EC%9A%94-

MariaDB는 mysql 의 Clone DB로 mysql과 거의 동일하다 10.3.x 버전부터는 Mysql과 다른 길을 걷고 있기 때문에 10.3.x 버전부터는 적용시 검토가 필요하다.

여기서는 stable 버전중에 mysql 5.7과 호환이 가능한 10.2.26 버전을 설치해본다.

1,.파일다운로드 페이지

https://downloads.mariadb.org/mariadb/10.2.26/

2. 설치 파일 선택(현재 OS는 CentOS 6.10)

mariadb-10.2.26-linux-systemd-x86_64.tar.gz -> CentOS 7 이상 설치x

mariadb-10.2.26-linux-glibc_214-x86_64.tar.gz (requires GLIBC_2.14+)

--> 2.14보다 아래라서 설치x

mariadb-10.2.26-linux-x86_64.tar.gz --> 설치가능O

3. Mariadb-10.2.26 설치

-- 초기설정은 Mysql 5.7과 같다 다른부분만 기술한다.