aDBanced Team

[MongoDB][ADMIN]WiredTiger 데이터 파일 구조 필수 개념

DBA_JSH — Sun, 6 Jun 2021 18:47:59 +0900

WiredTiger.lock

다른 MongoDB 서버 인스턴스가 동시에 사용하지 못하도록 잠금 역할을 하기 위한 파일이다.

이 파일은 MongoDB의 WiredTiger 스토리지 엔진이 정상적으로 셧다운 됐는지 판단하는 데 참조되는 파일이다. MongoDB가 재시작되면서 초기화될 때 해당 파일이 남아 있으면 비정상적으로 종료됐다고 판단하고 복구 모드를 시작한다.

LogMessage : Recovering data from the last clean checkpoint

파일을 강제로 삭제해버리면 복구 모드를 실행하지 않아서 데이터가 손실될 수 있다.

WiredTiger.turtle

스토리지 엔진의 설정 내용을 담고 있다.

WiredTiger.wt

스토리지 엔진의 메타 데이터를 저장하는 컬렉션의 데이터 파일이다.

컬렉션과 인덱스에 대해서 별도의 데이터 파일을 할당하도록 구현됐다. 데이터베이스나 컬렉션을 통째로 삭제하지 않고, 개별 인덱스를 삭제해도 해당 인덱스가 사용하던 디스크 공간을 운영체제로 반납해서 다른 용도로 활용할 수 있게 한 것이다.

인덱스의 이름과 무관하게 파일명을 부여하기 때문에 파악하기 어렵다. 따라서 아래와 같이 조회해보면 확인할 수 있다.

ex ) db.order.stats({indexDetails:true})

WiredTigerLAS(Look Aside Table).wt(MySQL TmpTable과 유사)

스토리지 엔진의 캐시에서 재활용할 수 있는 공간이 부족하면 WiredTiger 스토리지 엔진의 이빅션 서버는 필요한 만큼의 여유 공간을 만들어야 사용자 요청 쿼리를 원활하게 처리할 수 있다.

캐시에서 제거해야 하는 데이터 페이지들이 더티 페이지 상태여서 디스크에 기록해야 할 때 필요하다면 임시로 WiredTigerLAS.wt 데이터 파일을 사용하게 된다.

diagnostic.data(62 ~ 66p)

내부 정보를 1초에 한번씩 모아서 별도의 파일로 기록한다.

- 운영체제의 상태 정보(/proc/stats. /proc/meminfo, /sys/block/* /stat)

- serverStatus

- replSetGetStatus

- local.oplog.rs.stats 컬렉션의 collStas

- buildInfo

- getCmdLineOpts

- hostInfo

일정 용량을 초과하면 새로운 파일로 기록하는 형태로 로테이션 된다.

수집되는 진단 데이터를 FTDC(Full Time Data Capture)라고 하는데, FTDC와 관련된 옵션은 MongoDB 시작 될때 또는 운영 중에 변경 가능하다.

[장애] ERROR 1808 (HY000): Schema mismatch (Expected FSP_SPACE_FLAGS=0x21, .ibd file contains 0x0.)

DBA_JSH — Thu, 2 Jul 2020 16:57:11 +0900

1. 내용

1.1 환경

- CentOS 7.4

- MariaDB Version : 10.1.12, 10.3.8

1.2 내용

1) 10.1.12 MariaDB 데이터 파일(ibd)을 10.3.8 MariaDB로 데이터 임포트 실패

 - MariaDB [(none)]> ALTER TABLE test.mig_tb IMPORT TABLESPACE ;
   ERROR 1808 (HY000): Schema mismatch (Expected FSP_SPACE_FLAGS=0x21, .ibd file contains 0x0.)

2. 원인 분석

2.1 테이블 행 포맷 변경

- 10.1.12에서 테이블의 ROW_FORMAT은 COMPACT였으나, 10.3.8에서는 DYNAMIC으로 변경 됨에 따라 테이블 행의 포맷이 상이하여 에러 발생

2.2 신규 파라미터

     - innodb_default_row_format = 'dynamic'  
	MariaDB [(none)]> SHOW VARIABLES LIKE '%innodb_default_row_format%';
	+---------------------------+---------+
	| Variable_name             | Value   |
	+---------------------------+---------+
	| innodb_default_row_format | dynamic |
	+---------------------------+---------+
	1 row in set (0.000 sec)

3. 해결

- 10.3.8 MariaDB 테이블 행 포맷을 Compact로 변경

SET  GLOBAL  innodb_default_row_format = 'COMPACT'; 
- 테이블 생성 후 데이터 임포트 
MariaDB [(none)]> ALTER TABLE test.img_tb IMPORT TABLESPACE ;
Query OK, 0 rows affected, 1 warning (0.160 sec)
- 테이블 행 포맷 재변경 
SET  GLOBAL  innodb_default_row_format = 'DYNAMIC';

[MariaDB][ADMIN] INNODB 클러스터 인덱스(클러스터 테이블) 개념 및 성능 분석

DBA_JSH — Tue, 23 Jun 2020 23:39:56 +0900

1.클러스터링 인덱스 지원 엔진

- InnoDB, TokuDB

2. 클러스터링 인덱스 적용 대상

- 프라이머리 키(PK)

3. 클러스터링 인덱스 구성 방법

- PK 기준으로 정렬되어 레코드가 저장되며, PK가 변경된다면 레코드의 물리적인 저장 위치가 변경 된다.(Non 클러스터 테이블은 INSERT 될때 파일의 끝 또는 임의의 빈공간에 저장되고, 위치 변경은 없다. 레코드가 저장 된 주소(ROWID)를 식별 아이디로 인식함)

- 클러스터키를 구성하는 우선순위는 아래와 같다.

- PK가 있으면 클러스터 키로 선택 > NOT NULL 제약조건의 유니크 인덱스 중에서 첫번째 인덱스를 클러스터 키로 선택 > 임의의 유니크 값을 생성하여 클러스터 키로 선택

4. 클러스터링 인덱스와 보조 인덱스(Secondary index)와의 관계

- InnoDB 테이블의 모든 보조 인덱스는 해당 레코드가 저장된 주소가 아니라 PK값을 저장하도록 구현 됨(인덱스 검색 > 레코드의 PK확인 > PK로 테이블 검색 후 최종 데이터 추출)

5. 클러스터링 인덱스 장단점

- 장점 : PK로 검색 할때 처리 성능이 매우 빠름, 모든 보조 인덱스가 PK를 갖고 있기 때문에 인덱스만으로 처리 될 수 있는 경우가 많음(커버링 인덱스)

- 단점 : 모든 보조 인덱스가 PK를 갖고 있기 때문에 인덱스 크기가 커짐, INSERT 할 때 PK에 의해 레코드의 저장 위치가 결졍되어 처리 성능이 느림, PK를 변경 할때 DELETE, INSERT가 발생하여 처리 성능이 느림

6. Non-Clusterd Index(B-Tree) Vs Clusterd Index

- 공통점: 키 값으로 정렬되어 저장

- 차이점: B-Tree의 리프 노드와 달리 클러스터링 인덱스의 리프 노드에는 레코드의 모든 컬럼이 같이 저장되어 있음

6.1 테스트

#테스트 환경

- CentOS 7.4

- MariaDB 10.3.8

# 테스트 내용

- Clusterd Index(InnoDB) 와 Non-Clusterd Index(MyISAM) 크기 및 성능 비교

1. 테스트 테이블 및 데이터 생성 

/*클러스터링 테이블 생성*/
CREATE TABLE test.INNODB_CLUSTER_TABLE(
  SEQ_NO  int(9) NOT NULL AUTO_INCREMENT,
  CONN_DATE datetime NOT NULL ,
  ID varchar(100) NOT NULL ,  
  NAME varchar(100) NOT NULL ,
  PRIMARY KEY (SEQ_NO,CONN_DATE)  
) ENGINE=InnoDB ;

/*Non클러스터링 테이블 생성*/
CREATE TABLE test.MyISAM_NON_CLUSTER_TABLE(
  SEQ_NO  int(9) NOT NULL AUTO_INCREMENT,
  CONN_DATE datetime NOT NULL ,
  ID varchar(100) NOT NULL ,  
  NAME varchar(100) NOT NULL ,
  PRIMARY KEY (SEQ_NO,CONN_DATE)  
) ENGINE=MyISAM ;

/*200만건  데이터 적재*/
INSERT INTO test.INNODB_CLUSTER_TABLE(CONN_DATE,ID,NAME) 
SELECT CONCAT('2020-03-', LPAD(FLOOR(1+RAND()*30),2,'0'),' 09:51:30.000'),SUBSTRING (MD5( RAND ()) from 1 for 6),SUBSTRING (MD5( RAND ()) from 1 for 6)
FROM   seq_1_to_2000000;

INSERT INTO test.MyISAM_NON_CLUSTER_TABLE(CONN_DATE,ID,NAME) 
SELECT CONCAT('2020-03-', LPAD(FLOOR(1+RAND()*30),2,'0'),' 09:51:30.000'),SUBSTRING (MD5( RAND ()) from 1 for 6),SUBSTRING (MD5( RAND ()) from 1 for 6)
FROM   seq_1_to_2000000;

2. 클러스터링 테이블과 Non클러스터링 테이블 용량 비교 
  - INNODB_CLUSTER_TABLE(ibd ) : 96MB
  - MyISAM_NON_CLUSTER_TABLE(MYD) + MyISAM_NON_CLUSTER_TABLE(MYI) = 54M + 30M = 84MB

3. 클러스터링 인덱스과 Non클러스터링 인덱스(B-Tree) 생성
ALTER TABLE test.INNODB_CLUSTER_TABLE ADD INDEX INNODB_CLUSTER_TABLE_IX01(ID,NAME);
ALTER TABLE test.MyISAM_NON_CLUSTER_TABLE ADD INDEX INNODB_CLUSTER_TABLE_IX01(ID,NAME);

4. 인덱스 추가 후 용량 비교(보조 인덱스에 클러스터 키가 추가되어 생성 되기 때문에 동일한 인덱스를 생성해도 2배이상 용량 차이가 발생)
  - INNODB_CLUSTER_TABLE(ibd ) : 156(+60)MB
  - MyISAM_NON_CLUSTER_TABLE(MYD) + MyISAM_NON_CLUSTER_TABLE(MYI) = 54M + 30M(+24) = 108MB

5. 클러스터링 인덱스와 Non클러스터인덱스 성능 비교 
  5.1  PK 인덱스 컬럼 조회(PK인덱스 조건)
  SELECT  A.SEQ_NO, A.CONN_DATE        
  FROM    test.INNODB_CLUSTER_TABLE A 
  WHERE   1=1
  AND   A.SEQ_NO BETWEEN 1 AND 1500000
  AND   A.CONN_DATE BETWEEN STR_TO_DATE(202003010100,'%Y%m%d%H%i%s') AND STR_TO_DATE(20200310235959,'%Y%m%d%H%i%s');
  483815 rows in set (0.572 sec)

  SELECT  A.SEQ_NO ,A.CONN_DATE       
  FROM    test.MyISAM_NON_CLUSTER_TABLE A 
  WHERE   1=1
  AND   A.SEQ_NO BETWEEN 1 AND 1500000
  AND   A.CONN_DATE BETWEEN STR_TO_DATE(202003010100,'%Y%m%d%H%i%s') AND STR_TO_DATE(20200310235959,'%Y%m%d%H%i%s');
  499694 rows in set (0.671 sec)

  비교 결과 : PK컬럼만 사용 할때는 성능의 차이는 거의 없다.


  5.2 테이블 전체 컬럼 조회(PK인덱스 조건) 
  SELECT  A.SEQ_NO ,A.CONN_DATE ,A.ID ,A.NAME 
  FROM    test.INNODB_CLUSTER_TABLE A 
  WHERE   1=1
  AND   A.SEQ_NO BETWEEN 1 AND 1500000
  AND   A.CONN_DATE BETWEEN STR_TO_DATE(202003010100,'%Y%m%d%H%i%s') AND STR_TO_DATE(20200310235959,'%Y%m%d%H%i%s');
  483815 rows in set (0.695 sec)

  SELECT  A.SEQ_NO ,A.CONN_DATE ,A.ID ,A.NAME 
  FROM    test.MyISAM_NON_CLUSTER_TABLE A 
  WHERE   1=1
  AND   A.SEQ_NO BETWEEN 1 AND 1500000
  AND   A.CONN_DATE BETWEEN STR_TO_DATE(202003010100,'%Y%m%d%H%i%s') AND STR_TO_DATE(20200310235959,'%Y%m%d%H%i%s');
  499694 rows in set (3.087 sec)

  비교 결과 : 클러스터 인덱스는 모든 컬럼을 갖고 있기 때문에 테이블 엑세스가 없다. 
                      Non클러스터 인덱스는 테이블 엑세스 하여 컬럼의 값을 불러 온다.

  5.3  보조 인덱스 컬럼 조회(보조인덱스 조건)
  SELECT  A.ID ,A.NAME 
  FROM    test.INNODB_CLUSTER_TABLE A 
  WHERE   1=1
  AND     A.ID LIKE '9%'
  AND     A.NAME LIKE 'b%';
  15700 rows in set (0.135 sec)

  SELECT  A.ID ,A.NAME 
  FROM    test.MyISAM_NON_CLUSTER_TABLE A 
  WHERE   1=1
  AND     A.ID LIKE '9%'
  AND     A.NAME LIKE 'b%';
  15644 rows in set (0.201 sec)

  5.4  테이블 전체 컬럼 조회(보조인덱스 조건)
  SELECT  A.SEQ_NO ,A.CONN_DATE ,A.ID ,A.NAME 
  FROM    test.INNODB_CLUSTER_TABLE A 
  WHERE   1=1
  AND     A.ID LIKE '9%'
  AND     A.NAME LIKE 'b%';
  15700 rows in set (0.106 sec)

  SELECT  A.SEQ_NO ,A.CONN_DATE,A.ID ,A.NAME 
  FROM    test.MyISAM_NON_CLUSTER_TABLE A 
  WHERE   1=1
  AND     A.ID LIKE '9%'
  AND     A.NAME LIKE 'a%';
  15718 rows in set (1 min 0.115 sec)

  비교 결과 : 클러스터 보조 인덱스는 PK값을 갖고 있기 때문에, 테이블 엑세스 없이 테이블의 전체 컬럼을 조회 할 수 있다.
                 Non클러스터 보조 인덱스는 테이블 엑세스 하여 컬럼의 값을 불러 온다.

7. 결론

- MariaDB(MySQL)의 InnoDB 클러스터링 인덱스(테이블)는 정렬 구조 테이블이기 때문에 DML 성능 저하 및 저장 공간 과사용이라는 단점을 갖고 있으나, 데이터 조회 할 때 매우 뛰어난 성능을 보장하는 특징을 갖고 있다.

- 클러스터링 인덱스를 정확히 이해하고 SQL을 작성해야 최대 성능을 끌어 낼 수 있다.

참고 URL : https://12bme.tistory.com/149

[MariaDB][ADMIN] Deadlock found when trying to get lock; try restarting transaction 장애 원인 및 처리 방법

DBA_JSH — Fri, 29 May 2020 18:00:58 +0900

1.데드(Dead) 락

- 다중 문 트랜잭션을 사용 할 때 커밋을 하지 않을 때 발생하는 락을 말한다.

2. 장애 상황

- 두 개 이상의 트랜잭션이 서로 락을 해제할 때까지 기다리면서 전체적인 작업이 전혀 진행되지 못하는 상태를 데드락이라고 한다.

- MariaDB INNODB는 데드락 감지기를 갖고 있으며, 트랜잭션 중 하나를 롤백하고 에러를 출력하여 데드락에 빠지는 것을 방지 한다.

3. 테스트

#테스트 환경

- CentOS 7

- MariaDB 10.3.8

3.1 트랜잭션 락 발생

1. 테스트 테이블 및 데이터 생성 
MariaDB [test]> create table deadlock( no int(10) unsigned not null auto_increment, primary key(no));
Query OK, 0 rows affected (0.608 sec)

MariaDB [test]> insert into deadlock values();
Query OK, 1 row affected (0.002 sec)

MariaDB [test]> insert into deadlock select null from deadlock;
Query OK, 1 row affected (0.001 sec)
Records: 1  Duplicates: 0  Warnings: 0

MariaDB [test]> insert into deadlock select null from deadlock;
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0

2.데드락 발생 
#session 1 

  - AUTO COMMIT = ON일 경우 즉시 커밋이 되기 때문에 테스트를 위해서 OFF로 변경한다.
  - 트랜잭션을 시작(BEGIN)하고 insert문을 실행 한 후 트랜잭션 종료를 하지 않는다. 

MariaDB [test]> set session autocommit = OFF;
Query OK, 0 rows affected (0.000 sec)

MariaDB [test]> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            0 |
+--------------+
1 row in set (0.000 sec)

MariaDB [test]> BEGIN;

Query OK, 0 rows affected (0.000 sec)

  - 값 8을 삽입 한다.
MariaDB [test]> insert into deadlock values();
Query OK, 1 row affected (0.001 sec)

MariaDB [test]> select * from deadlock;
+----+
| no |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  6 |
|  7 |
|  8 |
+----+

#session 2 

  - AUTO COMMIT = ON일 경우 즉시 커밋이 되기 때문에 테스트를 위해서 OFF로 변경한다.
  - 트랜잭션을 시작(BEGIN)하고 insert문을 실행 한 후 트랜잭션 종료를 하지 않는다. 

MariaDB [test]> set session autocommit = OFF;
Query OK, 0 rows affected (0.000 sec)

MariaDB [test]> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            0 |
+--------------+
1 row in set (0.000 sec)

MariaDB [test]> BEGIN;
Query OK, 0 rows affected (0.000 sec)

MariaDB [test]> insert into deadlock values();
Query OK, 1 row affected (0.000 sec)

  - 값 10을 삽입 한다.
MariaDB [test]> select * from deadlock;
+----+
| no |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  6 |
|  7 |
| 10 |
+----+
7 rows in set (0.000 sec)

#session 1 
  - deadlock 테이블의 no값이 8번을 10번으로 업데이트 하자.
  
MariaDB [test]> update deadlock set no = 10 where no = 8;

#session 2 
  - deadlock 테이블의 no값이 10번을 8번으로 업데이트 하자.
  - session 2에서 deadlock이 발생했다는 에러를 반환하고 실패 한다.
MariaDB [test]> update deadlock set no = 8 where no = 10;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

#session 1
  - 업데이트를 성공 했다.
  - no값이 10인 로우는 session2에서 트랜잭션 진행 중이였기 때문에 대기하다가 
    deadlock에러 발생후 트랜잭션이 종료 되어 업데이트에 성공 했다.

MariaDB [test]> update deadlock set no = 10 where no = 8;
Query OK, 1 row affected (2.202 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [test]> select * from deadlock;
+----+
| no |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  6 |
|  7 |
| 10 |
+----+
7 rows in set (0.000 sec)

MariaDB [test]> commit;
Query OK, 0 rows affected (0.002 sec)

MariaDB [test]> show engine innodb status\G;

  - innodb가 데드락을 어떻게 탐지하고 처리 했는지 자세한 내용을 확인해 보자.
  - session 2에서 발생한 트랜잭션을 롤백(ROLLBACK)하면서 데드락을 종료 시켰다. 

------------------------
LATEST DETECTED DEADLOCK
------------------------
2020-05-21 17:17:20 0x7fed807ad700
*** (1) TRANSACTION:
TRANSACTION 125390168, ACTIVE 566 sec updating or deleting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 2
MySQL thread id 861802, OS thread handle 140676419942144, query id 169973223 localhost root Updating
update deadlock set no = 10 where no = 8
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 68400 page no 3 n bits 80 index PRIMARY of table "test"."deadlock" trx id 125390168 lock mode S locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 0000000a; asc     ;;
 1: len 6; hex 00000779516b; asc    yQk;;
 2: len 7; hex 290000032e14e0; asc )   .  ;;

*** (2) TRANSACTION:
TRANSACTION 125391211, ACTIVE 489 sec updating or deleting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 2
MySQL thread id 861988, OS thread handle 140658039510784, query id 169973512 localhost root Updating
update deadlock set no = 8 where no = 10
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 68400 page no 3 n bits 80 index PRIMARY of table "test"."deadlock" trx id 125391211 lock_mode X locks rec but not gap
Record lock, heap no 9 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 0000000a; asc     ;;
 1: len 6; hex 00000779516b; asc    yQk;;
 2: len 7; hex 290000032e14e0; asc )   .  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 68400 page no 3 n bits 80 index PRIMARY of table "test"."deadlock" trx id 125391211 lock mode S locks rec but not gap waiting
Record lock, heap no 8 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 00000008; asc     ;;
 1: len 6; hex 000007794d58; asc    yMX;;
 2: len 7; hex 630000033617ae; asc c   6  ;;

*** WE ROLL BACK TRANSACTION (2)

4. 해결방법 및 결론

- 2개의 세션에서 트랜잭션 중에 각 각 다른 세션에서 추가 된 행을 업데이트 하려고 할 때 서로 lock이 해제 될때만을 가디리며 교착상태에 빠진다.

- 오토커밋을 사용 할 경우, 반대쪽 세션에서 즉시 값을 업데이트 할 수 있기 때문에 교착상태에 빠지지 않는다.

- INNODB에서 데드락을 감지하여 한쪽 세션에 대해서 롤백을 진행하여 교착상태에 빠지진 않지만 언제 어떤 쿼리가 롤백 될지 모르기 때문에 데드락이 발생하지 않기 쿼리를 작성하는 것이 중요하다.

[MariaDB][ADMIN] Lock wait timeout exceeded; try restarting transaction 장애 원인 및 처리 방법

DBA_JSH — Wed, 20 May 2020 09:15:06 +0900

1.트랜잭션 락

- 다중 문 트랜잭션을 사용 할 때 커밋을 하지 않을 때 발생하는 락을 말한다.

2. 장애 상황

- session 1, session 2 2개의 세션 중에 session 1에서 트랜잭션을 시작(BEGIN) 명령어를 실행하고 update문을 수행하였다. 같은 시간 session 2에서는 동일한 테이블의 같은 행을 update 수행했고 lock이 발생 했다.

- session 2에 발생한 락은 무엇이며, 어떤 세션의 쿼리의 의해서 lock이 발생했는지지 원인을 파악하고 lock을 해결 할 수 있는 가장 좋은 방법은 무엇인가?

3. 테스트

#테스트 환경

- CentOS 7

- MariaDB 10.3.8

3.1 트랜잭션 락 발생

1. 테스트 테이블 및 데이터 생성

MariaDB [test]> create table hanglock( no int(10) unsigned not null auto_increment, primary key(no));

Query OK, 0 rows affected (0.608 sec)

MariaDB [test]> insert into hanglock values();

Query OK, 1 row affected (0.002 sec)

MariaDB [test]> insert into hanglock select null from hanglock;

Query OK, 1 row affected (0.001 sec)

Records: 1 Duplicates: 0 Warnings: 0

MariaDB [test]> insert into hanglock select null from hanglock;

Query OK, 2 rows affected (0.001 sec)

Records: 2 Duplicates: 0 Warnings: 0

MariaDB [test]> insert into hanglock select null from hanglock;

Query OK, 4 rows affected (0.001 sec)

Records: 4 Duplicates: 0 Warnings: 0

MariaDB [test]> insert into hanglock select null from hanglock;

Query OK, 8 rows affected (0.001 sec)

Records: 8 Duplicates: 0 Warnings: 0

2.트랜잭션 발생

#session 1

- 트랜잭션을 시작(BEGIN)하고 업데이트문을 실행 한 후 트랜잭션 종료를 하지 않는다.

MariaDB [test]> BEGIN;

Query OK, 0 rows affected (0.000 sec)

MariaDB [test]> UPDATE hanglock set no = 33 where no = 27;

Query OK, 1 row affected (0.000 sec)

Rows matched: 1 Changed: 1 Warnings: 0

#session 2

- session 1과 동일한 로우 업데이트를 실행 한다.

MariaDB [test]> BEGIN;

Query OK, 0 rows affected (0.000 sec)

- session 1에서 트랜잭션을 종료하지 않았기 때문에 대기 한다.

MariaDB [test]> update hanglock set no = 36 where no = 27;

MariaDB [test]> ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

- 대기 시간은 innodb_lock_wait_timeout에 설정 된 초만큼 대기하다가 종료 된다.

MariaDB [test]> show variables like '%innodb_lock_wait_timeout%';

+--------------------------+-------+

| Variable_name | Value |

+--------------------------+-------+

| innodb_lock_wait_timeout | 180 |

+--------------------------+-------+

1 row in set (0.001 sec)

#session 3

- session 3에서 현재 락에 걸려 있는 상황을 모니터링 한다.

- 2개의 로우에 lock이 발생 했다는 사실을 알 수 있으나, 어떤 세션에서 락을 걸었는지 또는 기다리는지 알 수 없다.

MariaDB [information_schema]> select * from innodb_locks\G;

*************************** 1. row ***************************

lock_id: 123423579:63806:3:16

lock_trx_id: 123423579

lock_mode: X

lock_type: RECORD

lock_table: "test"."hanglock"

lock_index: PRIMARY

lock_space: 63806

lock_page: 3

lock_rec: 16

lock_data: 19

*************************** 2. row ***************************

lock_id: 123423493:63806:3:16

lock_trx_id: 123423493

lock_mode: X

lock_type: RECORD

lock_table: "test"."hanglock"

lock_index: PRIMARY

lock_space: 63806

lock_page: 3

lock_rec: 16

lock_data: 19

2 rows in set (0.000 sec)

ERROR: No query specified

- lock을 요청한 세션과, lock에 의해 대기중인 세션을 확인 할 수 있다.

MariaDB [information_schema]> select * from innodb_lock_waits\G;

*************************** 1. row ***************************

requesting_trx_id: 123423579

requested_lock_id: 123423579:63806:3:16

blocking_trx_id: 123423493

blocking_lock_id: 123423493:63806:3:16

1 row in set (0.000 sec)

- innodb_trx 테이블을 조회를 통해사 상세한 정보를 확인 할 수 있다. trx_state 컬럼을 통해서 lock 상태를 확인 할 수 있으며, trx_mysql_thread_id로 lock을 발생 시킨 세션을 종료 할 수 있다.

MariaDB [information_schema]> select * from innodb_trx\G;

*************************** 1. row ***************************

trx_id: 123423493

trx_state: RUNNING

trx_started: 2020-05-19 08:33:08

trx_requested_lock_id: NULL

trx_wait_started: NULL

trx_weight: 4

trx_mysql_thread_id: 714185

trx_query: NULL

trx_operation_state: NULL

trx_tables_in_use: 0

trx_tables_locked: 1

trx_lock_structs: 2

trx_lock_memory_bytes: 1136

trx_rows_locked: 1

trx_rows_modified: 2

trx_concurrency_tickets: 0

trx_isolation_level: READ COMMITTED

trx_unique_checks: 1

trx_foreign_key_checks: 1

trx_last_foreign_key_error: NULL

trx_is_read_only: 0

trx_autocommit_non_locking: 0

*************************** 2. row ***************************

trx_id: 123423579

trx_state: LOCK WAIT

trx_started: 2020-05-19 08:33:22

trx_requested_lock_id: 123423579:63806:3:16

trx_wait_started: 2020-05-19 08:37:21

trx_weight: 2

trx_mysql_thread_id: 713497

trx_query: update hanglock set no = 200 where no = 19

trx_operation_state: starting index read

trx_tables_in_use: 1

trx_tables_locked: 1

trx_lock_structs: 2

trx_lock_memory_bytes: 1136

trx_rows_locked: 2

trx_rows_modified: 0

trx_concurrency_tickets: 0

trx_isolation_level: READ COMMITTED

trx_unique_checks: 1

trx_foreign_key_checks: 1

trx_last_foreign_key_error: NULL

trx_is_read_only: 0

trx_autocommit_non_locking: 0

2 rows in set (0.000 sec)

ERROR: No query specified

- lock을 잡고 있는 세션(714185)을 kill 한다.

[hiwdbusr@hiwsvr01 ~]$ mysqladmin -uroot -pNetand1410 kill 714185

#session 2

- lock wait 중이던 session 2의 update 작업이 완료 되었다.

MariaDB [test]> update hanglock set no = 200 where no = 19;

Query OK, 1 row affected (1 min 4.808 sec)

Rows matched: 1 Changed: 1 Warnings: 0

4. 해결방법 및 결론

- 트랜잭션을 시작(BEGIN)하고 쿼리를 수행 후 종료(COMMMIT/ROLLBACK)을 하지 않으면 트랜잭션이 계속 락을 유지 하기 때문에 반드시 COMMIT 또는 ROLLBACK을 통해 종료 한다.

- 트랜잭션 LOCK이 발생 했을 경우, 위의 테이블을 통해 LOCK을 발생시킨 대상을 찾아서 적절히 조치를 취해야 한다.

[MariaDB][ADMIN] Waiting for table metadata lock 장애 처리 방법

DBA_JSH — Thu, 14 May 2020 11:59:50 +0900

1.메타데이터 락

- 트랜잭션이 시작되면 사용하는 테이블에 대한 메타데이터 락을 걸고 트랜잭션이 완료될 때 메타데이터 락을 해제 한다. 이때 테이블의 정의를 바꾸려는 모든 스레드는 트랜잭션이 끝날때까지 기다려야 한다. (DDL, CREATE, DROP, ALTER)

2. 장애 상황

- session 1, session 2, session3의 3개의 세션 중에 session 1에서 트랜잭션을 시작(BEGIN) 명령어를 실행하고 SELECT문을 수행하였다. 같은 시간 session 2에서는 동일한 테이블을 drop 명령어를 수행했고, session 3에서는 데이터 insert 작업을 수행하였다.

- session 2, session 3는 metalock이 발생하였는데 lock을 해결 할 수 있는 가장 좋은 방법은 무엇인가?

3. 테스트

#테스트 환경

- CentOS 7

- MariaDB 10.3.8

3.1 메타데이터 락 발생

#session 1 
MariaDB [test]> create table test.metalock ( id varchar(100));
Query OK, 0 rows affected (0.027 sec)

MariaDB [test]> insert into test.metalock(id) values('test1');
Query OK, 1 row affected (0.001 sec)

#트랜잭션 시작 
MariaDB [test]> BEGIN;
Query OK, 0 rows affected (0.000 sec)

MariaDB [test]> select id from test.metalock;
+-------+
| id    |
+-------+
| test1 |
+-------+
1 row in set (0.000 sec)

#session 2
# DDL metalock 발생 
MariaDB [test]> drop table test.metalock;

#session 3
# DML metalock 발생(session 1이 아닌 session 2에 의해 metalock 발생)
 ,만약 session 2에서 DDL 작업이 없었다면 session 3은 metalock이 발생하지 않는다. 
MariaDB [test]> insert into test.metalock(id) values('test2');

#session 4
# matalock에 의해 대기 중인 세션 확인 
[hiwdbusr@hiwsvr01 ~]$ mysqladmin -uroot -pNetand1410 processlist |grep meta
| 379126 | root        | localhost |      | Query  | 16  | Waiting for table metadata lock  | drop table test.metalock | 0.000    |
| 379651 | root        | localhost | test | Query  | 4   | Waiting for table metadata lock  | insert into test.metalock(id) values('test2') | 0.000    |

#session 4
# metalock 발생 세션 확인( 현재 쿼리가 수행 중이라면, TRX_QUERY 값에 쿼리가 출력되며, 쿼리 실행이 완료 되었다면 NULL로 표시 된다.)
MariaDB [information_schema]> SELECT   A.TRX_ID
    ->         ,A.TRX_STATE
    ->         ,A.TRX_STARTED
    ->         ,A.TRX_QUERY
    ->         ,A.TRX_MYSQL_THREAD_ID
    -> FROM    INFORMATION_SCHEMA.INNODB_TRX A\G;
*************************** 1. row ***************************
             TRX_ID: 422151421839768
          TRX_STATE: RUNNING
        TRX_STARTED: 2020-05-14 08:57:02
          TRX_QUERY: NULL  
TRX_MYSQL_THREAD_ID: 380511
1 row in set (0.000 sec)

#TRX_MYSQL_THREAD_ID 번호로 processlist에서 재확인 
[hiwdbusr@hiwsvr01 ~]$ mysqladmin -uroot -pNetand1410 processlist |grep 380511
| 380511 | root        | localhost           | test     | Sleep       | 139   | 


4. 해결 방법 
해결방법 1 : meta lock을 유발시킨 세션을 kill 한다. 

#session 4
[hiwdbusr@hiwsvr01 ~]$ mysqladmin -uroot -pNetand1410 kill 380511;

#session 2
# 트랜잭션 진행 중이던 session 1을 kill 함으로 session 2가 대기 현상을 끝내고 DML 작업 완료 
MariaDB [(none)]> drop table test.metalock;
Query OK, 0 rows affected (4 min 21.864 sec)

#session 3
# session 2에 의해 metalock이 발생 했었고, session 2에서 테이블을 삭제 했기 때문에 테이블을 찾을 수 없다는 에러와 함께 작업 종료 
MariaDB [test]> insert into test.metalock(id) values('test2');
ERROR 1146 (42S02): Table 'test.metalock' doesn't exist

해결방법 2 : meta lock에 걸린 세션을 kill 한다.
#session 4
# session 2,3을 모두 kill 한다. 
[hiwdbusr@hiwsvr01 ~]$ mysqladmin -uroot -pNetand1410 kill 380511,379651;

해결방법 3 : lock_wait_timeout 파라미터 시간을 조정하여 lock 대기 시간을 줄인다.
( 단, 파라미터 변경 전에 접속 한 세션은 적용 대상이 아니며, 재접속 후에 반영 된다.)

#session 4
MariaDB [(none)]> show variables '%lock_wait_timeout%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| lock_wait_timeout        | 86400 |
+--------------------------+-------+

MariaDB [(none)]> set global lock_wait_timeout = 2;
Query OK, 0 rows affected (0.000 sec)

#session 2
MariaDB [(none)]> drop table test.metalock;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

#session 3
MariaDB [test]> insert into test.metalock(id) values('test3');
Query OK, 1 row affected (0.002 sec)

5. 결론

- 트랜직션을 시작(BEGIN) 했다면, 반드시 COMMIT 또는 ROLLBACK을 명시해줘야 lock이 발생하지 않는다.

- metalock이 발생을 최소화 하기 위해선 파라미터(lock_wait_timeout)를 조절하여 트랜잭션이 진행 중일 때는 DDL작업 수행 시 바로 타임아웃 되게 한다.

- 운영 중에 이미 metalock이 발생 했다면, lock을 발생 시킨 세션을 끊어서 그 다음 작업을 진행되게 하거나 lock에 걸려 대기하고 있는 세션을 끊는 방법을 선택 한다.( 업무에 따라서 세션을 끊어도 서비스에 영향이 없는 방향으로 선택한다.)

[장애] The log sequence numbers 1616840 and 1616840 in ibdata files do not match the log sequence number 31169132 in the ib_logfiles

유희수 — Wed, 18 Mar 2020 22:20:35 +0900

1. 내용

1.1 환경

- MariaDB Version : v10.1.12

- AWS 환경

1.2 내용

- MariaDB 재부팅 후 DB 비정상 동작

2. 원인 분석

2.1 로그 분석

- ibdata의 시퀀스 넘버와 ib_logfiles의 시퀀스 넘버가 일치하지 않음

- MariaDB가 정상적으로 종료되지 않아 MariaDB 시작 시 복구 진행을 시도하지만

실제로는 복구된 항목 없이 DB가 시작됨

[Note] InnoDB : The log sequence numbers 1616840 and 1616840 in ibdata files do not match the log sequence number 31169132 in the ib_logfiles
[Note] Database was not shutdown normally!
[Note] Starting crash recovery.
...중략
[ERROR] Got an error from thread_id=4, /home/buildbot/buildbot/build/storage/myisam/ha_myisam.cc:951
[ERROR] MySQL thread id 4, OS thread handle 0x7f6218066b00, qurey id 9 localhost root Checking table CHECK TABLE 'SQ_JOB_LOCK_ID'
[ERROR] mysqld: Table './APPAMDB/SQ_JOB_LOCK_ID' is marked as crashed and should be repaired
[Warning] Checking table: './APPAMDB/SQ_JOB_LOCK_ID'
[Warning] REcovering table : './APPAMDB/SQ_JOB_LOCK_ID'
[Note] Found 0 of 1 rows when repairing './APPAMDB/SQ_JOB_LOCK_ID'
...중략

2.2 테이블 점검

- 로그에 나온 테이블 상태 점검 시 에러 발생

- 명령어

전체 테이블 : mysqlcheck -uroot -proot -A

특정 테이블 : mysqlchekck -uroot -proot -a [DB] [Table]

DB.TABLE
Warning : 1 client is using or hasn't cloesd the table properly
Warning : Size of datafile is:13   Should be :0
Error : Record-count is not ok; is 1  Should be :0
Warning : Found 1 key parts.  Should be :0
Error : Corrupt

2.3 분석 결과

- MariaDB 재부팅 후 MyISAM 엔진을 사용하고 있는 테이블이 깨져 DB가 정상동작하지 않음

3. 해결

1) mysqlcheck를 통한 강제 복구

- 명령어 : mysqlcheck -uroot -proot --auto-repair [DB] [Table]

2) innodb_force_recovery=1 옵션 설정 후 DB 재부팅

- /etc/my.cnf 파일에서 옵션 수정

3) DB 재구성

[장애] ERROR 2003(HY000): Can't connection to MySQL server on 'x.x.x.x'(113 "No route to host")

유희수 — Fri, 13 Mar 2020 09:17:52 +0900

1. 내용

1.1 환경

- MariaDB Version : v10.1.12

- DB 서버 2대 이중화 구성

1.2 내용

1) Master 서버 장애 발생 후 Slave 서버로 Fail over 실패

2) Slave 서버 DB 외부에서 접속 불가

2. 원인 분석

2.1 방화벽 확인

- 방화벽이 활성화되어 외부에서 연결이 되지 않음

-> 외부 접속이 불가하여 Fail over 실패

3. 해결

- 방화벽 해제

  systemctl disable firewalld

- SELinux 해제

  [root@hiwsvr01 ~]# sestatus
  SELinux status:                 disabled

[장애] we intentionally generate a memory trap

유희수 — Thu, 12 Mar 2020 14:27:34 +0900

1. 내용

1.1 환경

- MariaDB Version : v10.1.12

- DB 서버 2대 이중화 구성

1.2 내용

- DB 중단

we intentionally generate a memory trap

2. 원인 분석

2.1 용량 확인

- /hiware6/dbms/log의 사용이 100%로 잔여 용량이 없어 DB 중단됨

3. 해결 방법

1) MariaDB MHA Binary log file 제거

purge master to logs '파일명'

2) binary log file 보관 주기 변경

2-1) vi /etc/my.cnf 수정

expire_logs_days 값 변경

2-2) 설정값 변경

set global expire_logs_days = 7;

[장애] ssh: connect to host 10.10.10.191 port 22: Connection refused

유희수 — Fri, 28 Feb 2020 10:02:38 +0900

1. 내용

1.1 환경

- MariaDB Version : 10.1.12

- DB 서버 2대 이중화 구성

1.2 내용

- 서버 Port 변경 후 mha_controller 실행 시 에러 발생하며 실행되지 않음

[hiwdbusr@hiwsvr02 scripts]$ ./mha_controller.sh
ssh: connect to host 10.10.10.191 port 22: Connection refused
ssh: connect to host 10.10.10.192 port 22: Connection refused
[ERR-005] Unable to perform programs on MariaDB MHA master server. Please start the program on the Slave server. (Current Status : Unknown)

2. 원인 분석

2.1 ssh config 확인

- 변경되기 이전 port로 ssh 통신을 시도하여 에러 메시지 발생됨

3. 해결 방법

3.1 Master/Slave 서버의 ssh config 파일 수정

- 'Port' 항목을 찾아 변경된 port 번호로 수정 (주석# 표시가 되어있는 경우 주석 해제)

- 수정 파일 : /etc/ssh/ssh_config , /etc/ssh/sshd_config

3.2 ssh 재시작

- root 권한으로 재시작 실행

- 명령어 : systemctl restart sshd