일반적인 문제

Cloud DB for MySQL을 이용하면서 다음과 같은 문제를 겪을 수 있습니다. 문제별 원인과 해결 방법을 확인하고 적절하게 조치해 주십시오.

MySQL Server의 개별 시작 및 정지

MySQL Server를 개별로 시작하거나 정지할 수 없습니다.

원인

MySQL Server의 개별 시작 또는 정지는 지원하지 않으며, 재시작 및 삭제만 가능합니다. 개별 MySQL Server를 정지하여 일시적으로 요금이 청구되지 않는 형태로 사용할 수는 없습니다.

해결 방법

MySQL Server의 재시작 또는 삭제만 수행해 주십시오. 재시작을 수행할 경우 해당 MySQL Server가 설치된 가상 서버와 해당 서버가 동시에 재시작됩니다.

MySQL Server 접속 오류

MySQL Server 접속 시 오류가 발생합니다.
SSL VPN을 사용 중인데 Cloud DB for MySQL에 접속되지 않습니다.

원인

MySQL Server에 접속하려면 사전에 MySQL Server와 통신할 애플리케이션 서버를 생성해야 합니다. 사전 작업을 해두지 않으면 정상적으로 네이버 클라우드 플랫폼의 Cloud DB for MySQL을 정상적으로 사용할 수 없습니다.

해결 방법

애플리케이션 서버 확인
Cloud DB for MySQL에서 생성한 MySQL Server는 현재 네이버 클라우드 플랫폼 내에서만 접근이 가능하기 때문에 애플리케이션 서버 역시 네이버 클라우드 플랫폼 내에 생성해야 합니다. 전반적인 서버 생성의 흐름은 사용 시나리오를 확인 후 아래의 각 플랫폼 환경별 시작 가이드를 참조해 주십시오.

• 전체 사용 시나리오
• Cloud DB for MySQL 시작

MySQL Server 접속 방법 확인
네이버 클라우드 플랫폼 서버에서 MySQL Server에 접속하는 방법은 다음과 같습니다.

• 네이버 클라우드 플랫폼 서버에서 Private 도메인을 사용한 접근: Cloud DB for MySQL 시작
• 클라우드 외부에서의 접근: SSL VPN을 사용한 접근

Master Server 재시작 시 Failover

Master Server를 재시작했는데 Failover가 수행되지 않습니다.

원인

장애가 발생하는 경우만 Failover가 자동 진행되며, 사용자의 재시작 명령으로는 진행되지 않습니다.

해결 방법

장애 상황이 아니므로 별도로 조치할 사항이 없습니다.

Failover 수행

서비스 오픈 전 Master Server 장애로 인한 Failover 상황을 재현하여 애플리케이션에 영향이 없는지 사전에 점검하기 위해 Failover를 수행하고자 합니다.

해결 방법

Failover를 수행하는 방법은 DB Server의 Master DB Failover를 참조해 주십시오. Failover를 진행하는 동안 서버 접속이 되지 않을 수 있습니다.

MySQL Server의 예기치 않은 재시작

사용자가 재시작하지 않았는데 MySQL Server가 재시작되었습니다.
MySQL Server에 일시적으로 접속할 수 없다가 자동으로 복구되었습니다.
고가용성(HA) 구성에서 Master Server가 예기치 않게 Failover되었습니다.

원인

MySQL Server는 다음과 같은 경우 사용자의 재시작 요청 없이 재시작될 수 있습니다.

• DB 프로세스 재시작: 메모리가 부족하여 운영체제가 DB 프로세스(mysqld)를 강제로 종료(OOM, Out Of Memory)하거나 DB 프로세스가 비정상 종료되면, DB 프로세스가 자동으로 다시 시작됩니다. 서버는 재시작되지 않습니다. DB 프로세스가 다시 시작된 후 데이터 복구(crash recovery)를 마치고 접속이 가능해지기까지 수 초에서 수 분이 걸릴 수 있습니다.
• 서버 재시작: 과도한 메모리 또는 CPU 사용으로 서버가 응답하지 않는 상태가 지속되거나, 서버가 동작하는 물리 서버 또는 스토리지에 장애가 발생하면 서버가 강제로 재시작될 수 있습니다.

해결 방법

다음 순서로 재시작 여부와 원인을 확인한 후 조치해 주십시오.

1. 재시작 여부와 시각 확인

• 네이버 클라우드 플랫폼 콘솔에서 Menu > All Services > Database > Cloud DB for MySQL > Monitoring 메뉴를 차례대로 클릭한 후 [DB Logs] 탭에서 해당 MySQL Server의 Error log를 확인해 주십시오.
  • 재시작된 시각에 MySQL 시작 로그가 기록됩니다.
  • 정상 종료 로그(Shutdown complete) 없이 다음 로그가 기록되었다면 DB 프로세스 또는 서버가 비정상 종료된 후 다시 시작된 것입니다. MySQL 버전에 따라 로그 형식은 다를 수 있습니다.

    [InnoDB] Database was not shutdown normally!
    [InnoDB] Starting crash recovery.
    

  • 데이터 복구가 끝나면 ready for connections 로그가 기록되고 접속이 가능해집니다.
• Event 메뉴에서 해당 시각에 발생한 이벤트를 확인해 주십시오.
  • 고가용성 구성에서 Failover가 발생했다면 Event 이름이 Failover인 이벤트가 MySQL Failover completed. Active Master is {서버 이름} 내용으로 기록됩니다. 새로 Master Server가 된 서버를 확인할 수 있습니다.

2. 원인 점검

• Monitoring 메뉴의 [OS Dashboard] 탭과 [DB Dashboard] 탭에서 재시작 직전의 Memory Usage(%), Free Memory, Swap(%), CPU Usage(%), Connections 추이를 확인해 주십시오. Cloud DB for MySQL은 메모리 사용률이 90% 내외까지 올라가는 것이 정상이지만, 재시작 직전에 Memory Usage(%)가 그보다 더 오르거나 Free Memory가 0에 가깝게 줄었다면(Swap Memory를 사용 중이면 Swap(%)도 증가) 메모리 부족이 원인일 가능성이 높습니다.
• [Query Timeline] 탭에서 재시작 직전에 수행된 쿼리를 확인해 주십시오. 대량 정렬, 조인, 임시 테이블 등 메모리를 많이 사용하는 쿼리가 있다면 튜닝해 주십시오. 자세한 내용은 Query Timeline 그래프 차트를 참조해 주십시오.

3. 재시작 후 상태 확인

• DB Server 화면의 MySQL Server 목록에서 상태가 운영중인지 확인하고, 실제로 MySQL Server에 접속하여 쿼리가 정상적으로 수행되는지 점검해 주십시오. 상태가 Unknown으로 표시되면 Unknown 상태를 참조해 주십시오.
• Failover가 발생했다면 Master Server와 Standby Master Server의 역할(DB Role)이 변경되었는지 확인해 주십시오.
• Standby Master Server와 Slave Server의 Replication 상태를 확인해 주십시오. Replication이 중단되었다면 Replication 오류를 참조해 주십시오. 확인 방법은 Replication 상태 확인을 참조해 주십시오.
• 애플리케이션이 끊어진 연결을 다시 맺는지 확인해 주십시오. 애플리케이션은 IP 주소가 아닌 접속 도메인을 사용해야 Failover 후 새 Master Server로 접속됩니다. 애플리케이션 또는 운영체제가 DNS 조회 결과를 오래 저장(캐시)하면 Failover 후에도 이전 서버로 접속을 시도할 수 있으니 DNS 캐시 설정도 함께 점검해 주십시오.

4. 재발 방지 (메모리 부족이 원인인 경우)

메모리 부족으로 재시작이 발생했다면 다음 방법을 검토해 주십시오.

• 메모리 사용량을 높이는 쿼리를 튜닝해 주십시오.
• DB Config 관리에서 innodb_buffer_pool_size 값을 현재 값보다 10~20% 정도 줄여 주십시오. 변경 방법은 메모리 사용량 증가를 참조해 주십시오.
• DB Server 설정에서 메모리 할당 라이브러리(Malloc-lib)를 TCMalloc 또는 jemalloc으로 변경해 주십시오.
• Swap Memory 설정을 사용으로 변경해 주십시오.
• MySQL Server 스펙 변경으로 메모리가 더 큰 서버 타입으로 변경해 주십시오.

5. 알림 설정

재시작을 빠르게 인지할 수 있도록 Cloud Insight에서 Event Rule을 설정해 주십시오.

• 네이버 클라우드 플랫폼 콘솔에서 Menu > All Services > Management & Governance > Cloud Insight > Configuration > Event Rule 메뉴를 차례대로 클릭해 주십시오.
• 다음 항목에 대한 Event Rule을 설정해 주십시오.
  • mysql_active: DB 프로세스 응답 여부 (응답 시 100, 응답 없음 시 0)
  • mem_pct: 메모리 사용률
• 자세한 설정 방법은 Event Rule 설정을 참조해 주십시오.

삭제된 데이터 복구

삭제된 데이터를 복구해야 합니다.

원인

서버 리소스 삭제 시 모든 데이터가 삭제되기 때문에 복구가 불가능합니다.

해결 방법

삭제된 데이터는 복구할 수 없습니다. 서버를 삭제하기 전에 Object Storage에 백업 데이터를 업로드하여 일정 시간 보관 후 반납해 주십시오. Object Storage에 업로드된 백업을 통한 복원은 Xtrabackup을 통한 백업 파일 복원을 참조해 주십시오.

데이터베이스 생성

데이터베이스를 직접 생성하고자 합니다.

원인

권한 오남용으로 인한 문제를 방지하고자 사용자에게 직접적인 데이터베이스 생성 권한은 부여하지 않고 있습니다.

해결 방법

DB 생성은 아래 3가지 방법을 통해 진행해 주십시오. 데이터베이스 생성 시 DDL 권한을 가진 계정은 생성된 데이터베이스에 대해 모든 권한을 갖게 됩니다.

• 콘솔을 통한 데이터베이스 생성
• Stored Procedure를 사용한 데이터베이스 생성
• Cloud DB for MySQL API를 사용한 데이터베이스 생성

MySQL Server의 임계값 초과 알림

MySQL Server의 임계값 초과 이벤트 알림을 받을 수 없습니다.

원인

Cloud DB for MySQL은 서버 성능과 운영체제에 대한 모니터링 서비스와 이벤트 수집 서비스를 제공하며, Cloud Insight와 연동하여 사용자가 직접 임계값을 설정해야 합니다. Cloud Insight의 연동과 사용자 설정값에 오류가 있을 경우 정상적으로 알람이 전송되지 않을 수 있습니다.

해결 방법

Cloud DB for MySQL의 모니터링 결과와 이벤트 수집 결과는 Cloud Insight와 연동하여 메일이나 SNS로 알람을 통보하도록 설정할 수 있습니다. 자세한 사용 방법은 Monitoring, Event을 참조해 주십시오.

Replication 오류

Replication 오류가 발생하며 Replication이 멈췄습니다.

원인

상황에 따라 여러 가지 원인이 있을 수 있습니다. 자세한 내용은 해결 방법을 확인해 주십시오.

해결 방법

• [Skip Replication Error] 버튼을 클릭하여 오류가 발생한 쿼리를 일회성으로 스킵 처리합니다. 이 경우, Master Server의 데이터와 정합성을 완벽히 맞추지 않기 때문에 이후 오류가 다시 발생하고 Replication이 멈출 수 있습니다.
• Replication error가 발생한 DB를 재설치합니다. 이 경우, 마지막 백업본으로 DB를 재구축하고 Master Server와 데이터 정합성을 맞춥니다. 재구축 시 일정 시간이 소요되며 재구축을 완료한 후에는 Master Server와 같은 데이터를 가집니다.
  Skip Replication Error 기능 및 DB 재설치에 대한 설명은 DB Server의 Replication 상태 확인을 참조해 주십시오.

Replication 지연 완화

Replication 지연이 발생합니다.

원인

Replication 지연은 MySQL의 Replication 스펙과 사용자 애플리케이션의 동작에 의한 현상으로 Cloud DB for MySQL의 장애가 아닙니다.
Replication 지연은 다음과 같은 경우에 발생합니다.

• Master DB에 쓰기 부하가 높은 경우
• 쓰기 쿼리가 많이 유입되는 경우
• 하나의 트랜잭션으로 대량의 변경 작업 후 commit한 경우
• Primary Key가 없는 테이블에 많은 row를 변경하는 쿼리를 수행한 경우
• 오랜 시간의 수행이 필요한 쿼리가 유입되는 경우
• 락으로 인해 대기하는 경우

Monitoring의 Query Timeline 그래프 차트에서 지연을 발생하는 쿼리를 확인할 수 있습니다. Query Timeline에서 지연이 증가하는 시점을 검색하거나 지연되고 있는 서버의 Query Timeline 및 실행 중인 바이너리 로그 보기를 확인해 주십시오.

해결 방법

Replication 지연 발생 시 innodb_flush_log_at_trx_commit Config 값을 변경하고 Master DB의 Replication 지연의 원인이 되는 Primary Key가 없는 테이블에 Primary Key를 추가한 후 Standby Master Server를 재구축해야 합니다.

• Master DB의 innodb_flush_log_at_trx_commit 값에 대한 설명 및 변경 방법은 MySQL 가이드와 DB Server의 DB Config 관리를 참조해 주십시오.
• Master DB의 Primary Key가 없는 테이블에 Primary Key 추가 후 Standby Master 재구축하는 방법은 두 가지가 있습니다.
  • Replication 상태 확인에서 재설치해 주십시오.
  • Master Server의 고가용성 설정을 해제한 후 재설정해 주십시오.

mysqldump 유틸리티 오류

mysqldump를 이용하여 백업 또는 복구 시 에러가 발생합니다.

원인

Cloud DB for MySQL은 완전 관리형 서비스으로 모든 권한을 제공하지 않습니다.

해결 방법

• mysqldump 유틸리티를 이용하여 백업 시 적절한 옵션을 추가해야 합니다. 자세한 내용은 mysqldump를 통한 백업을 참조해 주십시오.
• mysqldump 유틸리티를 이용하여 복구 시 실행할 수 없는 문장을 제거해야 합니다. 자세한 내용은 mysqldump를 통한 백업 파일 복원을 참조해 주십시오.

Unknown 상태

Cloud DB for MySQL 콘솔에서 DB 서버 상태가 Unknown으로 표시됩니다.

원인

• DB 서버에 과도한 부하가 발생하여 모니터링 지표 수집이 지연되거나 실패한 경우, 해당 Master 또는 Slave 서버의 상태가 Unknown으로 표시됩니다.
• Replication이 Stop 상태로 1시간 이상 지속된 경우, Standby Master 서버의 상태가 Unknown으로 표시됩니다.
• Replication Delay(Seconds_Behind_Master)가 1시간 이상 누적된 경우, Standby Master 서버의 상태가 Unknown으로 표시됩니다.

해결 방법

• Master 또는 Slave 서버에서 상태가 Unknown으로 표시된 경우, SHOW PROCESSLIST 또는 Performance Schema를 활용하여 부하를 유발하는 쿼리를 식별하고, 해당 쿼리에 대한 튜닝을 통해 서버 부하를 완화해 주십시오.
• Standby Master 서버에서 상태가 Unknown으로 표시된 경우, Standby Master 서버를 재설치한 후 replication이 중단되거나 지연된 원인을 분석해 주십시오.
  • Write Master 서버에서 대량의 DML 쿼리 또는 long transaction이 수행되었는지 점검하여, 유사한 상황이 재발하지 않도록 조치해 주십시오.
  • Standby Master 서버에서 상태가 Unknown 상태인 경우, 데이터 유실 방지를 위하여 Master DB 장애 시 자동 Failover 기능이 제한됩니다. 원활한 HA 기능을 위하여 빠른 시일 내에 조치해 주시기 바랍니다.

미지원 엔진 테이블 생성 제한

MyISAM, BLACKHOLE, FEDERATED, ARCHIVE, MEMORY 엔진을 사용하는 테이블을 생성할 수 없습니다.

원인

Cloud DB for MySQL에서는 아래 테이블 엔진을 지원하지 않습니다.

• MyISAM, BLACKHOLE, FEDERATED, ARCHIVE, MEMORY
• 해당 엔진은 트랜잭션 미지원, 데이터 일관성 부족, 클라우드 환경에서의 복제 및 장애 조치 제한 등의 이유로 사용이 제한됩니다.

해결 방법

신규 테이블 생성 시 InnoDB 엔진을 사용해 주십시오.

현재 사용 중인 테이블 엔진 확인

SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE 
FROM information_schema.TABLES 
WHERE ENGINE IN ('MyISAM','BLACKHOLE','FEDERATED','ARCHIVE','MEMORY')
    AND TABLE_SCHEMA NOT IN ('information_schema','mysql','performance_schema','sys');

기존 테이블 엔진 변경

ALTER TABLE 테이블명 ENGINE = InnoDB;

콘솔 알림 팝업 오류

일부 콘솔 동작 시 아래와 같은 알림 팝업이 발생합니다.

• CASE 1: MySQL Replication 지연이 있는 상태입니다. 지연이 모두 해소된 이후에 다시 시도해 주세요.

• CASE 2: DB 서버 통신이 원활하지 않아 Master DB Failover를 진행할 수 없습니다. 잠시 후 다시 시도해 주세요.

• CASE 3: 백업 시간 전후에는 작업을 진행할 수 없습니다. 작업을 진행하려면 백업 시간을 조정해 주세요.

• CASE 4: 백업이 진행 중입니다. 백업이 완료된 이후 작업을 진행해 주세요. 백업 소요 시간은 사용자 데이터 크기에 비례하여 증가합니다.

• CASE 5: Database Migration Service 완료 후 자동 백업이 아직 수행되지 않았습니다. 자동 백업은 완료일 기준 약 24시간 이내에 수행되며, 완료된 뒤 다시 시도해 주세요.

원인 및 해결 방법

CASE 1

• 원인

  • Replication 오류로 인한 중지 또는 Replication Delay 발생

• 해결 방법

  • Replication 오류 또는 Delay 발생 시: Standby Master 재설치 또는 Replication Delay 해소 후 재시도

CASE 2

• 원인

  • HA 모니터가 정상적으로 구동되지 않은 상태

• 해결 방법

  • 일시적인 현상일 수 있으므로 잠시 후 다시 시도해 주십시오. 장시간 동일 팝업이 노출될 경우 고객센터를 통해 문의해 주시기 바랍니다.

CASE 3

• 원인

  • 백업 시간대에는 일부 작업이 제한됨

• 해결 방법

  • DB Server > DB Status > [Backup 설정 관리] 탭 메뉴에서 Backup 시간을 조정한 후 작업을 진행해 주십시오.

CASE 4

• 원인

  • Standby Master에서 백업이 진행 중인 상태

• 해결 방법

  • 백업 완료 후 작업을 다시 시도해 주십시오. 백업 소요 시간은 데이터 크기에 따라 달라질 수 있습니다.

CASE 5

• 원인

  • DMS(Database Migration Service) 사용 당일

• 해결 방법

  • Standby Master 재설치 진행 후 재시도