전체보기 84

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

WiredTiger.lock 다른 MongoDB 서버 인스턴스가 동시에 사용하지 못하도록 잠금 역할을 하기 위한 파일이다. 이 파일은 MongoDB의 WiredTiger 스토리지 엔진이 정상적으로 셧다운 됐는지 판단하는 데 참조되는 파일이다. MongoDB가 재시작되면서 초기화될 때 해당 파일이 남아 있으면 비정상적으로 종료됐다고 판단하고 복구 모드를 시작한다. LogMessage : Recovering data from the last clean checkpoint 파일을 강제로 삭제해버리면 복구 모드를 실행하지 않아서 데이터가 손실될 수 있다. WiredTiger.turtle 스토리지 엔진의 설정 내용을 담고 있다. WiredTiger.wt 스토리지 엔진의 메타 데이터를 저장하는 컬렉션의 데이터 파일..

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

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으로 변경 됨에 따라 테이블 행의 포맷이 상이하여 에러..

MariaDB/장애 2020.07.02

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

1.클러스터링 인덱스 지원 엔진 - InnoDB, TokuDB 2. 클러스터링 인덱스 적용 대상 - 프라이머리 키(PK) 3. 클러스터링 인덱스 구성 방법 - PK 기준으로 정렬되어 레코드가 저장되며, PK가 변경된다면 레코드의 물리적인 저장 위치가 변경 된다.(Non 클러스터 테이블은 INSERT 될때 파일의 끝 또는 임의의 빈공간에 저장되고, 위치 변경은 없다. 레코드가 저장 된 주소(ROWID)를 식별 아이디로 인식함) - 클러스터키를 구성하는 우선순위는 아래와 같다. - PK가 있으면 클러스터 키로 선택 > NOT NULL 제약조건의 유니크 인덱스 중에서 첫번째 인덱스를 클러스터 키로 선택 > 임의의 유니크 값을 생성하여 클러스터 키로 선택 4. 클러스터링 인덱스와 보조 인덱스(Secondary ..

MariaDB/Admin 2020.06.23

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

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)); Q..

MariaDB/Admin 2020.05.29

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

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]> c..

MariaDB/Admin 2020.05.20

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

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을 해결 할 수 있는 가장 좋은 ..

MariaDB/Admin 2020.05.14

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

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 normall..

MariaDB/장애 2020.03.18

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

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

MariaDB/장애 2020.03.13

[장애] we intentionally generate a memory trap

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;

MariaDB/장애 2020.03.12

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

1. 내용1.1 환경- MariaDB Version : 10.1.12- DB 서버 2대 이중화 구성 1.2 내용- 서버 Port 변경 후 mha_controller 실행 시 에러 발생하며 실행되지 않음 [hiwdbusr@hiwsvr02 scripts]$ ./mha_controller.shssh: 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. ..

MariaDB/장애 2020.02.28