MariaDB 트러블슈팅 및 장애 대응
1️⃣ ERROR 1045 (28000): Access denied for user 해결
1.1 문제 설명
ERROR 1045 (28000): Access denied for user
오류는 주로 MariaDB에 접속할 때 권한 문제로 발생합니다. 이 오류는 사용자가 데이터베이스에 접근하려고 할 때 권한이 부여되지 않았거나 비밀번호가 잘못되었을 경우 발생합니다.
1.2 해결 방법
-
사용자 확인: MariaDB에 로그인하여 사용자와 그 권한을 확인합니다.
SELECT user, host FROM mysql.user;
-
비밀번호 확인: 비밀번호를 확인하거나 변경하여 문제를 해결할 수 있습니다.
SET PASSWORD FOR 'username'@'host' = PASSWORD('newpassword');
-
사용자 권한 부여: 사용자가 특정 데이터베이스에 접속할 수 있도록 권한을 부여합니다.
GRANT ALL PRIVILEGES ON database_name.* TO 'username'@'host' IDENTIFIED BY 'password'; FLUSH PRIVILEGES;
-
my.cnf 파일 확인:
bind-address
설정이 제대로 되어 있는지 확인합니다. 로컬에서만 접근을 허용하거나 원격 접근을 차단할 수 있습니다.
2️⃣ Too many connections 문제 해결
2.1 문제 설명
Too many connections
오류는 MariaDB 서버가 처리할 수 있는 연결 수를 초과했을 때 발생합니다. 기본적으로 MariaDB는 설정된 max_connections
값만큼 연결을 허용합니다.
2.2 해결 방법
-
현재 연결 수 확인 MariaDB에서 현재 열린 연결 수를 확인하려면 다음 쿼리를 사용합니다.
SHOW STATUS LIKE 'Threads_connected';
-
max_connections 값 확인 및 증가
max_connections
값을 늘려서 더 많은 연결을 허용할 수 있습니다.SHOW VARIABLES LIKE 'max_connections'; SET GLOBAL max_connections = 500; -- 예시로 500으로 설정
-
잠금된 연결 종료 불필요한 연결을 종료하여
max_connections
초과 문제를 해결할 수 있습니다.SHOW PROCESSLIST; -- 실행 중인 쿼리 목록 KILL connection_id; -- 문제 있는 연결 종료
3️⃣ Deadlock found when trying to get lock 문제 해결
3.1 문제 설명
Deadlock
은 두 개 이상의 트랜잭션이 서로를 기다리며 무한 대기 상태에 빠지는 현상입니다. MariaDB에서 트랜잭션 간에 잠금이 서로 충돌하면 Deadlock
오류가 발생합니다.
3.2 해결 방법
-
Deadlock 발생 원인 분석 MariaDB 로그에서 deadlock 정보를 확인할 수 있습니다.
SHOW ENGINE INNODB STATUS;
-
트랜잭션 격리 수준 조정 트랜잭션의 격리 수준을 조정하여 Deadlock을 방지할 수 있습니다. 예를 들어,
READ COMMITTED
격리 수준을 사용할 수 있습니다.SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
-
트랜잭션의 순서 변경 트랜잭션이 동일한 자원에 접근할 때 순서를 변경하여 충돌을 피할 수 있습니다.
-
비즈니스 로직 수정
Deadlock
을 유발할 수 있는 코드나 로직을 수정하여 문제를 예방할 수 있습니다.
4️⃣ MySQL server has gone away 오류 분석 및 해결
4.1 문제 설명
MySQL server has gone away
오류는 MariaDB 서버와 클라이언트 간의 연결이 끊어졌을 때 발생합니다. 이는 대개 쿼리가 너무 오래 걸리거나 서버가 응답하지 않을 때 발생할 수 있습니다.
4.2 해결 방법
-
wait_timeout
설정 변경 클라이언트와 서버 간의 연결이 끊어지지 않도록wait_timeout
값을 늘려야 할 수 있습니다.SHOW VARIABLES LIKE 'wait_timeout'; SET GLOBAL wait_timeout = 28800; -- 예시로 8시간으로 설정
-
쿼리 최적화 쿼리가 오래 걸리면
MySQL server has gone away
오류가 발생할 수 있습니다. 쿼리 성능을 최적화하여 처리 시간을 줄입니다. -
max_allowed_packet
크기 조정 전송할 데이터 크기가 너무 크면 오류가 발생할 수 있습니다.max_allowed_packet
크기를 늘려 해결할 수 있습니다.SHOW VARIABLES LIKE 'max_allowed_packet'; SET GLOBAL max_allowed_packet = 67108864; -- 예시로 64MB로 설정
5️⃣ Replication Delay 문제 해결
5.1 문제 설명
Replication Delay는 마스터 서버에서 변경된 데이터가 슬레이브 서버에 반영되기까지 시간이 지연되는 현상입니다. 이는 데이터베이스 복제에서 발생할 수 있는 문제입니다.
5.2 해결 방법
-
슬레이브 서버의 상태 확인 슬레이브 서버에서 복제 상태를 확인하여 지연이 발생하는 원인을 파악합니다.
SHOW SLAVE STATUS\G
-
복제 스레드의 상태 확인
Slave_IO_Running
과Slave_SQL_Running
값이Yes
인지 확인합니다. 만약No
인 경우, 복제 프로세스에 문제가 발생한 것입니다. -
디스크 I/O 성능 확인 디스크 성능이나 네트워크 성능이 낮으면 복제 지연이 발생할 수 있습니다. I/O 성능을 개선하여 문제를 해결할 수 있습니다.
-
슬레이브 서버의 처리 성능 조정 슬레이브 서버의
innodb_flush_log_at_trx_commit
값을2
로 설정하여 성능을 높일 수 있습니다.
6️⃣ 테이블 손상 (corrupt table) 문제 복구 (myisamchk, innodb_force_recovery)
6.1 문제 설명
테이블 손상은 데이터베이스 테이블의 데이터가 읽을 수 없거나, 일부 손상된 경우 발생합니다. 이는 주로 MyISAM 또는 InnoDB 테이블에서 발생할 수 있습니다.
6.2 해결 방법
6.2.1 MyISAM 테이블 복구 (myisamchk)
-
테이블 점검 손상된 테이블을 확인하려면
myisamchk
명령어를 사용하여 점검합니다.myisamchk -c /var/lib/mysql/my_database/my_table.MYI
-
테이블 복구 테이블을 복구하려면
myisamchk
명령어에-r
옵션을 사용합니다.myisamchk -r /var/lib/mysql/my_database/my_table.MYI
6.2.2 InnoDB 테이블 복구 (innodb_force_recovery)
-
innodb_force_recovery
설정 InnoDB 테이블이 손상된 경우innodb_force_recovery
값을 설정하여 복구를 시도할 수 있습니다.[mysqld] innodb_force_recovery = 1
-
서버 재시작 후 데이터 백업 설정 후 서버를 재시작하여 데이터를 백업하고, 복구를 진행합니다.