Database > RDS for MariaDB > DB 인스턴스

DB 인스턴스

DB 인스턴스는 가상 장비와 설치된 MariaDB을 아우르는 개념으로, RDS for MariaDB에서 제공하는 MariaDB의 단위입니다. DB 인스턴스의 운영체제에 직접 접근할 수 없으며, DB 인스턴스 생성 시 입력한 포트로만 데이터베이스에 접근할 수 있습니다. 사용할 수 있는 포트 범위는 3306~43306입니다.

DB 인스턴스는 고객이 부여하는 이름과 자동으로 부여되는 32바이트 아이디로 식별됩니다. DB 인스턴스 이름은 아래와 같은 제약 사항이 있습니다.

  • DB 인스턴스 이름은 리전별로 고유해야 합니다.
  • DB 인스턴스 이름은 1~100자의 영문자, 숫자, 일부 기호(-, _, .)만 사용할 수 있으며, 첫 번째 글자는 영문자만 사용할 수 있습니다.

알아두기

2025년 7월 점검 이후 고가용성 DB 인스턴스는 Primary뿐만 아니라 Standby의 이름도 입력하도록 변경되었습니다. Standby의 이름에도 Primary와 동일한 제약 사항이 적용되며, Primary와 Standby의 이름은 서로 달라야 합니다. 점검 이전에 생성한 DB 인스턴스는 Standby의 이름이 Primary와 동일합니다.

DB 인스턴스 생성

다음 설정으로 DB 인스턴스를 생성할 수 있습니다.

가용성 영역

NHN Cloud는 물리 하드웨어 문제로 생기는 장애에 대비하기 위해 전체 시스템을 여러 개의 가용성 영역으로 나누어 두었습니다. 이 가용성 영역별로 저장 시스템, 네트워크 스위치, 상면, 전원 장치가 모두 별도로 구성돼 있습니다. 한 가용성 영역 내에서 생기는 장애는 다른 가용성 영역에 영향을 주지 않으므로 서비스 전체의 가용성이 높아집니다. DB 인스턴스를 여러 가용성 영역에 나눠 구축한다면 서비스의 가용성을 더욱 높일 수 있습니다. 여러 가용성 영역에 흩어져서 생성된 DB 인스턴스끼리 네트워크로 통신할 수 있으며, 이때 발생하는 네트워크 사용 비용은 부과되지 않습니다.

주의

이미 생성한 DB 인스턴스의 가용성 영역은 변경할 수 없습니다.

DB 엔진

아래에 명시된 버전을 사용할 수 있습니다. 신규 DB 인스턴스 생성 및 Read Replica 추가는 메이저 버전당 상위 7개 마이너 버전까지만 지원합니다.

버전 비고
11.8
MariaDB 11.8.8
MariaDB 11.8.6
11.4
MariaDB 11.4.14
MariaDB 11.4.10
MariaDB 11.4.7
10.11
MariaDB 10.11.18
MariaDB 10.11.16
MariaDB 10.11.13
MariaDB 10.11.8
MariaDB 10.11.7
10.6
MariaDB 10.6.25 신규로 생성하거나 Read Replica를 추가할 수 없습니다.
MariaDB 10.6.22 신규로 생성하거나 Read Replica를 추가할 수 없습니다.
MariaDB 10.6.16 신규로 생성하거나 Read Replica를 추가할 수 없습니다.
MariaDB 10.6.12 신규로 생성하거나 Read Replica를 추가할 수 없습니다.
MariaDB 10.6.11 신규로 생성하거나 Read Replica를 추가할 수 없습니다.
10.3
MariaDB 10.3.30 신규로 생성하거나 Read Replica를 추가할 수 없습니다.

DB 엔진에 관한 자세한 내용은 DB 엔진에서 확인할 수 있습니다.

DB 인스턴스 타입

DB 인스턴스는 타입에 따라 서로 다른 CPU 코어 수와 메모리 용량을 갖습니다. DB 인스턴스 생성 시 데이터베이스 워크로드에 따라 알맞은 DB 인스턴스 타입을 선택해야 합니다.

타입 설명
m2 CPU와 메모리를 균형 있게 설정한 타입입니다.
c2 CPU의 성능을 높게 설정한 인스턴스 타입입니다.
r2 다른 자원에 비해 메모리 사용량이 많은 경우 사용할 수 있습니다.
x1 고사양의 CPU와 메모리를 지원하는 타입입니다. 높은 성능이 필요한 서비스나 애플리케이션에 사용합니다.

이미 생성한 DB 인스턴스의 타입은 콘솔에서 손쉽게 변경할 수 있습니다.

주의

이미 생성한 DB 인스턴스의 타입을 변경하면 DB 인스턴스가 종료되므로 수 분 동안 서비스가 중단됩니다.

데이터 스토리지

데이터 스토리지에 데이터베이스의 데이터 파일을 저장합니다. DB 인스턴스는 HDD, SSD의 2가지 데이터 스토리지 유형을 지원합니다. 데이터 스토리지 유형에 따라 성능과 가격이 다르므로 데이터베이스 워크로드에 따라 알맞은 유형을 선택해야 합니다. 데이터 스토리지는 20GB~2TB로 생성할 수 있습니다.

주의

이미 생성한 DB 인스턴스의 데이터 스토리지 유형은 변경할 수 없습니다.

알아두기

데이터 스토리지를 2TB 이상 사용하려면 NHN Cloud 고객지원으로 문의하세요.

아래 작업은 데이터 스토리지의 I/O 사용률이 높아지기 때문에 수행되는 동안 DB 인스턴스의 성능이 저하될 수 있습니다.

  • 단일 DB 인스턴스의 백업
  • 단일 DB 인스턴스의 고가용성 구성
  • Read Replica 생성
  • Read Replica 재구축
  • Standby 재구축
  • 특정 시점으로 복원
  • 단일 DB 인스턴스에서 백업 후 Object Storage로 백업 파일 내보내기

고가용성

고가용성 DB 인스턴스는 가용성과 데이터 내구성을 높이고, 장애를 허용하는 데이터베이스를 제공합니다. 고가용성 DB 인스턴스는 Primary, Standby로 구성되며 서로 다른 가용성 영역에 생성됩니다. Standby는 장애에 대비한 DB 인스턴스로 평소에는 사용할 수 없습니다. 고가용성 DB 인스턴스는 Standby에서 백업이 수행되기 때문에 백업으로 인한 성능 저하를 회피할 수 있습니다. 고가용성 DB 인스턴스가 제공하는 여러 기능은 고가용성 DB 인스턴스에서 확인할 수 있습니다.

네트워크

DB 인스턴스에 연결할 VPC 서브넷을 선택해야 합니다. 동일한 서브넷에 연결된 Compute 서비스의 인스턴스 간에는 별도의 플로팅 IP 없이 통신할 수 있으며, 네트워크 트래픽 비용이 청구되지 않습니다. DB 인스턴스는 기본적으로 모든 네트워크 접근을 차단하므로 접속을 원하는 경우 DB 보안 그룹을 적용해야 합니다.

주의

이미 생성한 DB 인스턴스의 서브넷은 변경할 수 없습니다.

플로팅 IP

외부에서 DB 인스턴스에 접근하려면 플로팅 IP를 DB 인스턴스에 연결해야 합니다. Internet Gateway가 연결된 서브넷을 연결할 경우에만 플로팅 IP를 생성할 수 있습니다. 플로팅 IP는 사용과 동시에 과금되며, 이와 별개로 플로팅 IP를 통한 인터넷 방향의 트래픽이 발생할 경우 별도로 과금됩니다.

파라미터 그룹

파라미터 그룹은 DB 인스턴스에 설치된 데이터베이스를 설정할 수 있는 파라미터의 집합입니다. DB 인스턴스 생성 시 반드시 하나의 파라미터 그룹을 선택해야 합니다. 파라미터 그룹은 생성 이후에도 자유롭게 변경할 수 있습니다. 자세한 파라미터 그룹 내용은 파라미터 그룹 항목을 참고합니다.

DB 보안 그룹

DB 보안 그룹은 외부 침입에 대비해 접속을 제한하는 데 사용합니다. 송수신 트래픽에서 특정 포트 범위 또는 데이터베이스 포트에 접근을 허용할 수 있습니다. DB 인스턴스에 여러 개의 DB 보안 그룹을 적용할 수 있습니다. 자세한 DB 보안 그룹 내용은 DB 보안 그룹 항목을 참고합니다.

백업

DB 인스턴스의 데이터베이스를 주기적으로 백업하도록 설정하거나, 콘솔에서 원하는 시기에 백업을 생성할 수 있습니다. 백업이 수행되는 동안 성능 저하가 발생할 수 있습니다. 서비스에 영향을 주지 않으려면 서비스 부하가 적은 시간에 백업하기를 권장합니다. 백업으로 인한 성능 저하를 원치 않으면 고가용성 구성을 사용하거나, 이전 백업 이후 데이터의 증분만 백업할 수 있으며, Read Replica에서 백업을 수행할 수 있습니다. 백업 파일은 내부 백업 스토리지에 저장되며, 백업 용량에 따라 과금됩니다. 필요한 경우 NHN Cloud의 Object Storage로 내보낼 수 있습니다. 예상치 못한 장애에 대비해 주기적으로 백업을 수행하도록 설정하기를 권장합니다. 자세한 백업 내용은 백업 및 복원 항목을 참고합니다.

유지 관리

유지 관리 기능을 사용하면 DB 인스턴스의 다양한 변경 작업을 원하는 시간대에 수행할 수 있습니다. DB 인스턴스 수정, DB 엔진 버전 업그레이드, DB 인스턴스 운영체제 업그레이드 등의 작업은 재시작이 필요해 다운타임이 발생할 수 있습니다. 유지 관리 기간을 설정하면 이러한 작업을 서비스 부하가 적은 시간대에 실행할 수 있습니다.

유지 관리 기간

DB 인스턴스 생성 또는 수정 시 유지 관리 기간을 설정할 수 있습니다. 유지 관리 기간을 설정하지 않으면 22:00~06:00 사이의 30분이 임의로 자동 할당됩니다. 유지 관리 기간은 자동 백업 시간과 겹칠 수 없습니다.

알아두기

유지 관리 기간은 유지 관리 시작 요일, 유지 관리 시작 시간, 유지 관리 윈도우(30분 단위)로 구성됩니다.

유지 관리 작업

유지 관리 작업은 사용자 유지 관리 작업과 Provider 유지 관리 작업으로 구분됩니다.

사용자 유지 관리 작업

사용자가 직접 실행을 예약할 수 있는 작업입니다.

  • DB 인스턴스 수정(DB 인스턴스 사양 변경, 포트 변경, 파라미터 그룹 변경 등)
  • DB 엔진 버전 업그레이드
  • DB 인스턴스 운영체제 업그레이드

Provider 유지 관리 작업

NHN Cloud에서 제공하는 유지 관리 작업입니다.

  • 파라미터 그룹 변경 사항 적용
  • 하이퍼바이저 점검을 위한 마이그레이션

유지 관리 적용 시점

유지 관리 작업 수행 시 적용 시점을 선택할 수 있습니다.

  • 즉시 적용: 요청 즉시 유지 관리 작업을 수행합니다.
  • 다음 유지 관리 기간에 적용: 다음 유지 관리 기간에 작업을 수행합니다.

유지 관리 상태

DB 인스턴스 목록에서 각 인스턴스의 유지 관리 상태를 확인할 수 있습니다.

상태 설명
없음 예약 및 보류 중인 유지 관리 작업이 없습니다.
다음 적용 사용자 유지 관리 작업이 다음 유지 관리 기간에 실행 예정입니다.
적용 중 유지 관리 작업이 진행 중입니다.
필수 필수 Provider 유지 관리 작업이 보류 중입니다.
사용 가능 필수가 아닌 Provider 유지 관리 작업이 보류/준비 중입니다.

알아두기

고가용성 DB 인스턴스의 Standby는 유지 관리 상태가 표시되지 않습니다.

유지 관리 탭

DB 인스턴스 상세 화면의 유지 관리 탭에서 다음 정보를 확인할 수 있습니다.

  • 유지 관리 시작 요일 및 기간
  • 다음 유지 관리 기간
  • 유지 관리 상태
  • 준비 중인 유지 관리 작업 목록(다음 유지 관리 기간에 실행될 작업)
  • 보류 중인 유지 관리 작업 목록

준비 중인 유지 관리 작업은 보류 또는 삭제 버튼을 클릭하여 유지 관리 기간에서 제외할 수 있습니다. 보류 중인 Provider 유지 관리 작업은 즉시 적용 또는 다음 유지 관리 기간에 적용을 선택하여 수동으로 적용할 수 있습니다.

작업 실행 순서

유지 관리 기간 내의 모든 작업은 등록 순서에 따라 순차적으로 실행됩니다. 단, 만료 일시가 지난 필수 유지 관리 작업은 가장 먼저 실행됩니다. 유지 관리 기간 내에 실행되지 못한 작업은 다음 유지 관리 기간에 다시 실행됩니다.

알아두기

자동 백업 및 DB 인스턴스가 '작업 중' 상태에서 유지 관리 기간이 시작되어 유지 관리 시간이 계속 미뤄질 경우 해당 유지 관리는 우선 생략하고 다음 유지 관리 기간에 실행됩니다. 유지 관리 작업이 생략되면 이벤트가 생성됩니다.

기본 알림

DB 인스턴스 생성 시 기본 알림을 설정할 수 있습니다. 기본 알림을 설정하면 {DB 인스턴스 이름}-default 이름으로 새로운 알림 그룹이 생성되며 아래 알림 항목이 자동으로 설정됩니다. 기본 알림으로 생성된 알림 그룹은 자유롭게 수정, 삭제할 수 있습니다. 자세한 알림 그룹 내용은 알림 그룹 항목을 참고합니다.

항목 비교 방법 임곗값 지속 시간
CPU 사용률 >= 80% 5분
Storage 남은 사용량 <= 5,120MB 5분
Database Connection Status <= 0 0분
Storage 사용량 >= 95% 5분
데이터 스토리지 결함 <= 0 0분
Connection Ratio >= 85% 5분
메모리 사용량 >= 90% 5분
Slow Query >= 60 counts/min 5분

삭제 보호

삭제 보호를 활성화하면 실수로 DB 인스턴스가 삭제되지 않도록 보호할 수 있습니다.

DB 인스턴스 목록

콘솔에서 생성된 DB 인스턴스를 확인할 수 있습니다. DB 인스턴스 그룹 단위로 묶어서 보거나, 개별 DB 인스턴스로 볼 수 있습니다.

db-instance-list_ko

❶ DB 인스턴스 화면 모드를 변경할 수 있습니다. ❷ 버튼을 클릭하여 그룹 안에 속한 DB 인스턴스를 펼치거나 접을 수 있습니다. ❸ 가장 최근 수집된 모니터링 지표를 보여줍니다. ❹ 현재 상태를 볼 수 있습니다. ❺ 진행 중인 작업이 있으면 스피너가 나타납니다. ❻ 검색 조건을 변경할 수 있습니다.

DB 인스턴스의 상태는 아래와 같은 값으로 구성되며, 사용자의 행위와 현재 상태에 따라 변경됩니다.

상태 설명
BEFORE_CREATE 생성 이전
AVAILABLE 사용 가능
STORAGE_FULL 용량 부족
FAIL_TO_CREATE 생성 실패
FAIL_TO_CONNECT 연결 실패
REPLICATION_STOP 복제 중단
FAILOVER 장애 조치 완료
SHUTDOWN 중지됨

변경할 수 있는 검색 조건은 아래와 같습니다.

db-instance-filter_ko

❶ 파라미터 변경 사항 적용이 필요한 DB 인스턴스를 필터링 조건으로 검색할 수 있습니다.

DB 인스턴스 그룹 상세

DB 인스턴스 목록을 그룹 화면으로 본 뒤 DB 인스턴스 그룹을 선택하면 그룹 상세 정보를 확인할 수 있습니다. 그룹 상세 화면에는 다음 탭이 표시됩니다.

탭 설명
기본 정보 DB 인스턴스 그룹 이름과 ID, 고가용성 구성, Primary 및 Standby 이름, Ping 설정을 확인합니다.
DB 스키마 & 사용자 그룹에 속한 DB 인스턴스의 DB 스키마와 사용자를 관리합니다. DB 스키마와 사용자 기능은 개별 DB 인스턴스 상세가 아닌 DB 인스턴스 그룹 상세에서 제공합니다.

DB 스키마 & 사용자

DB 인스턴스 그룹 상세의 DB 스키마 & 사용자 탭에서는 그룹에 속한 데이터베이스의 스키마와 사용자를 조회 및 제어할 수 있습니다.

DB 스키마 생성

db-instance-detail-schema_ko

❶ 생성을 클릭하면 DB 스키마의 이름을 입력할 수 있는 팝업 창이 나타납니다. ❷ DB 스키마 이름을 입력한 뒤 확인을 클릭하여 DB 스키마를 생성할 수 있습니다.

DB 스키마 이름은 아래와 같은 제약 사항이 있습니다.

  • 1~64자의 영문자, 숫자, _만 사용할 수 있으며, 첫 번째 글자는 영문자만 사용할 수 있습니다.
  • information_schema, performance_schema, db_helper, sys, mysql, rds_maintenance는 DB 스키마 이름으로 사용할 수 없습니다.

생성된 DB 스키마의 이름은 수정할 수 없습니다.

DB 스키마 삭제

db-instance-detail-schema-delete-ko

❶ 삭제할 DB 스키마를 선택 후 드롭다운 메뉴를 클릭합니다. ❷ 삭제 메뉴를 클릭하면 삭제 확인 팝업 화면이 나타납니다. 확인을 클릭하여 삭제를 요청할 수 있습니다.

사용자 생성

db-instance-detail-user-create-ko

❶ + 생성을 클릭하면 사용자 추가 팝업 화면이 나타납니다. ❷ 사용자 ID를 입력합니다.

사용자 ID는 아래와 같은 제약 사항이 있습니다.

  • 1~32자여야 합니다.
  • mysql.session, mysql.sys, mysql.infoschema, sqlgw, admin, etladm, alertman, prom, rds_admin, rds_mha, rds_repl은 사용자 ID로 사용할 수 없습니다.

❸ Password를 입력합니다. ❹ 접속을 허용할 Host IP를 입력합니다. % 문자를 사용하면 허용할 Host IP를 범위로 지정할 수 있습니다. 예: 1.1.1.%는 1.1.1.0~1.1.1.255 사이의 모든 IP를 의미합니다. ❺ 사용자에게 부여할 권한을 선택합니다. 부여할 수 있는 권한과 설명은 다음과 같습니다.

READ * 조회 권한이 있습니다.

GRANT SELECT, SHOW VIEW, PROCESS, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO '{user_id}'@'{host}';
GRANT SELECT ON `mysql`.* TO '{user_id}'@'{host}';
GRANT SELECT, EXECUTE ON `sys`.* TO '{user_id}'@'{host}';
GRANT SELECT ON `performance_schema`.* TO '{user_id}'@'{host}';

CRUD * READ 권한을 포함하며, 데이터를 변경할 수 있는 권한이 있습니다.

GRANT INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE ON *.* TO '{user_id}'@'{host}';

DDL * CRUD 권한을 포함하며, DDL 쿼리를 실행할 수 있는 권한이 있습니다.

GRANT CREATE, DROP, INDEX, ALTER, CREATE VIEW, REFERENCES, EVENT, ALTER ROUTINE, CREATE ROUTINE, TRIGGER, RELOAD ON *.* TO '{user_id}'@'{host}';
GRANT EXECUTE ON `mysql`.* TO '{user_id}'@'{host}';

CUSTOM * 외부 데이터베이스 백업으로부터 DB 인스턴스를 복원한 경우, 데이터베이스에 존재하는 모든 사용자는 CUSTOM 권한으로 표현됩니다. * CUSTOM 권한 템플릿에는 어떤 권한이 있는지 알 수 없습니다. * CUSTOM 권한 템플릿에서 다른 권한 템플릿으로 변경한 경우 다시 CUSTOM 권한 템플릿으로 변경할 수 없습니다.

사용자 수정

db-instance-detail-user-modify-ko

❶ 수정할 사용자 행의 수정을 클릭하면 사용자 정보를 수정할 수 있는 팝업 화면이 나타납니다. ❷ Password를 입력하지 않으면 변경되지 않습니다. ❸ 사용자 인증에 적용할 플러그인을 변경하려면 반드시 Password를 변경해야 합니다.

사용자 삭제

db-instance-detail-user-delete-ko

❶ 삭제할 사용자를 선택 후 드롭다운 메뉴를 클릭합니다. ❷ 삭제를 클릭하면 삭제 확인 팝업 화면이 나타납니다. 확인을 클릭하여 삭제를 요청할 수 있습니다.

DB 인스턴스 그룹 수정

그룹 상세 화면의 기본 정보 탭에서 수정을 클릭하면 그룹 단위로 설정을 변경할 수 있습니다. 변경 요청은 비동기로 처리되며, 완료될 때까지 해당 그룹의 상태와 진행 중인 작업을 확인합니다.

수정 화면에서 다음 항목을 변경할 수 있습니다.

항목 설명
DB 인스턴스 그룹 이름 1~100자의 영문자, 숫자, -, _, .를 사용할 수 있으며 첫 글자는 영문자여야 합니다.
Primary 이름 그룹 이름과는 별도로 관리됩니다.
고가용성 여부 단일 구성은 고가용성 구성으로 전환할 수 있고, 고가용성 구성은 단일 구성으로 전환할 수 있습니다.
Standby 이름 고가용성을 새로 설정할 때 입력합니다. Primary 이름과 같을 수 없으며, 이름 규칙은 Primary와 같습니다.
Ping 간격 고가용성 구성에서 1~600초 범위로 설정합니다.
Ping 방식 고가용성 구성에서 INSERT 또는 SELECT 중 선택합니다.
DB 스키마 & 사용자 직접 제어 그룹에 속한 DB 인스턴스의 스키마와 사용자 직접 제어 사용 여부를 변경합니다.

주의

  • 고가용성을 해제하면 Standby가 삭제되고 단일 구성으로 전환됩니다. Standby에만 존재하는 데이터나 설정이 없는지 확인한 뒤 진행하세요.
  • 장애 조치가 진행 중인 DB 인스턴스 그룹에서는 고가용성 여부를 변경할 수 없습니다.
  • 사설망에서는 Primary 이름을 변경할 수 없습니다. 또한 기존 고가용성 구성의 Standby 이름은 변경할 수 없으며, 고가용성을 새로 설정할 때만 Standby 이름을 입력할 수 있습니다.
  • 고가용성 구성에서 Primary와 Standby의 이름은 서로 달라야 합니다.

DB 스키마 & 사용자 직접 제어

RDS for MariaDB에서는 DB 스키마와 사용자를 손쉽게 관리할 수 있도록 콘솔에서 관리 기능을 제공하지만, 사용자가 직접 제어할 수 있도록 설정하는 기능도 제공합니다. 직접 제어를 사용하면 현재 생성된 모든 사용자에게 아래 권한을 부여합니다.

GRANT CREATE,DROP,LOCK TABLES,REFERENCES,EVENT,ALTER,INDEX,INSERT,SELECT,UPDATE,DELETE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EXECUTE,CREATE USER,PROCESS,RELOAD,REPLICATION SLAVE,REPLICATION CLIENT,SHOW DATABASES, CREATE TEMPORARY TABLES,TRIGGER ON *.* TO '{user_id}'@'{host}' WITH GRANT OPTION;

주의

직접 제어 사용 이후 다시 사용 안 함으로 변경하면 * 기존에 부여한 권한을 회수하지 않습니다. 이때 명령어를 사용해 DB 스키마나 사용자를 추가하면 콘솔의 데이터와 정합성이 맞지 않을 수 있습니다. * 사용자에게 부여된 권한과 상관없이 데이터베이스에 존재하는 모든 사용자는 CUSTOM 권한으로 표현됩니다.

DB 인스턴스 상세

DB 인스턴스를 선택하면 상세 정보를 볼 수 있습니다.

db-instance-detail_ko

❶ 접속 정보의 도메인을 클릭하면 IP 주소를 확인할 수 있는 팝업 창이 나타납니다. ❷ DB 보안 그룹을 클릭하면 DB 보안 규칙을 확인할 수 있는 팝업 창이 나타납니다. ❸ 파라미터 그룹을 클릭하면 파라미터를 확인할 수 있는 화면으로 이동합니다. ❹ 마우스로 드래그 앤드 드롭 하여 상세 정보 패널의 높이를 조절할 수 있습니다. ❺ 상세 정보 패널의 높이를 미리 지정된 높이로 조절할 수 있습니다.

접속 정보

DB 인스턴스 생성 시 내부 도메인을 발급합니다. 내부 도메인은 사용자 VPC 서브넷에 속한 IP 주소를 가리킵니다. 고가용성 DB 인스턴스는 장애 조치되어 Standby가 새로운 Primary로 변경되더라도 내부 도메인이 변경되지 않습니다. 따라서 특별한 이유가 없으면 응용 프로그램의 접속 정보는 반드시 내부 도메인을 사용해야 합니다.

플로팅 IP를 생성한 경우 외부 도메인을 추가로 발급합니다. 외부 도메인은 플로팅 IP의 주소를 가리킵니다. 외부 도메인 또는 플로팅 IP는 외부에서 접근할 수 있으므로 DB 보안 그룹의 규칙을 적절히 설정하여 DB 인스턴스를 보호해야 합니다.

Virtual IP

2025년 5월 점검 이후 생성한 DB 인스턴스는 VIP(virtual IP)를 지원합니다. VIP는 사용자 VPC 서브넷에 속한 IP 주소를 가리킵니다. 고가용성 DB 인스턴스에서 VIP는 항상 현재 시점의 Primary를 가리킵니다. 응용 프로그램의 접속 정보는 반드시 VIP를 직접 사용하거나 VIP를 가리키는 내부(VIP) 도메인을 사용해야 합니다.

2025년 5월 이전에 생성한 DB 인스턴스는 NHN Cloud 콘솔의 VIP 추가 메뉴를 클릭하여 VIP를 추가할 수 있습니다. VIP를 추가하면 기존 내부 도메인과 내부(VIP) 도메인이 함께 제공됩니다. 단, 장애 조치 시 VIP는 Standby를 가리키지만 내부 도메인은 경우에 따라 Standby를 가리키지 않을 수 있습니다. 따라서 VIP를 추가하면 반드시 응용 프로그램의 접속 정보가 VIP 또는 내부(VIP) 도메인을 사용하도록 수정해야 합니다.

알아두기

2025년 9월 점검 이후 일본(도쿄) 리전 및 공공 일부 프로젝트에서는 더 이상 VIP를 지원하지 않습니다. (다른 서브넷에 속한 인스턴스 또는 DB 인스턴스에서 VIP로 접속할 수 없습니다.) VIP를 지원하지 않는 환경에서는 2025년 5월 점검 이후 생성된 VIP는 삭제되지 않지만, 더 이상 콘솔에서 확인할 수 없습니다.

로그

DB 인스턴스의 로그 탭에서는 각종 로그 파일을 보거나 다운로드할 수 있습니다. 로그 파일은 아래와 같이 정해진 설정으로 로테이트됩니다. 일부 로그 파일은 파라미터 그룹에서 활성화하거나 비활성화할 수 있습니다.

항목 로테이트 설정 변경 여부 연관 파라미터
error.log 100MB 10개 고정
slow_query.log 100MB 40개 고정 slow_query_log
general_log.log 100MB 40개 고정 general_log
server_audit.log 20MB 30개 변경 가능 server_audit_logging
server_audit_file_rotations
mysql-bin.xxxxxx 5일 변경 가능 binlog_expire_logs_seconds

db-instance-detail-log_ko

❶ 로그 보기를 클릭하면 로그 파일의 내용을 확인할 수 있는 팝업 화면이 나타납니다. 최대 65,535Bytes의 로그를 확인할 수 있습니다. ❷ 가져오기를 클릭하면 DB 인스턴스의 로그 파일을 다운로드할 수 있도록 요청합니다. ❸ 다운로드가 준비되면 다운로드 버튼이 노출됩니다. 클릭하면 로그를 내려받습니다.

주의

가져오기를 클릭하면 약 5분간 로그 파일이 백업 스토리지에 업로드되며 로그 파일의 크기만큼 백업 스토리지 용량이 과금됩니다. 다운로드를 클릭하면 로그 파일의 크기만큼 인터넷 트래픽이 과금됩니다.

❹ 바이너리 로그(binary log)는 2가지 형태로 내려받을 수 있습니다. 가져오기를 클릭하면 바이너리 로그 형태를 선택할 수 있는 팝업 화면이 나타납니다.

db-instance-detail-log-bin_ko

❺ mysqlbinlog 유틸리티를 이용하여 바이너리 로그(binary log)를 SQL 파일로 변환 후 내려받으려면 선택합니다.

유지 관리

DB 인스턴스의 유지 관리 탭에서는 유지 관리 설정 및 상태를 확인하고, 유지 관리 작업을 관리할 수 있습니다.

db-instance-detail-maintenance_ko

유지 관리 정보

유지 관리 탭 상단에서 현재 DB 인스턴스의 유지 관리 설정 정보를 확인할 수 있습니다.

항목 설명
유지 관리 시작 요일 DB 인스턴스에 설정된 유지 관리 시작 요일입니다.
유지 관리 기간 DB 인스턴스에 설정된 유지 관리 시간 범위입니다.
다음 유지 관리 기간 다음에 유지 관리 작업이 실행될 예정인 일시입니다.
유지 관리 상태 현재 유지 관리 상태를 나타냅니다. 없음, 다음 적용, 적용 중, 필수, 사용 가능 중 하나로 표시됩니다.

알아두기

유지 관리 기간을 설정하지 않은 경우에도 임의로 할당된 유지 관리 기간을 확인할 수 있습니다.

준비 중인 유지 관리

준비 중인 유지 관리는 다음 유지 관리 기간에 실행될 예정인 작업 목록입니다. 사용자가 DB 인스턴스 수정, DB 엔진 버전 업그레이드 등의 작업을 수행할 때 다음 유지 관리 기간에 적용을 선택하면 이 목록에 추가됩니다.

항목 설명
설명 유지 관리 작업에 대한 설명입니다.
유형 유지 관리 작업의 유형입니다.
상태 유지 관리 작업의 현재 상태입니다.
필수 여부 필수 유지 관리 작업 여부를 나타냅니다.
등록 일시 유지 관리 작업이 등록된 일시입니다.
강제 적용 일시 필수 작업은 이 일시 이후에 자동으로 적용됩니다.

준비 중인 유지 관리 작업은 선택 후 삭제 또는 보류를 클릭하여 유지 관리 기간에서 제외할 수 있습니다. 삭제된 사용자 유지 관리 작업은 취소되며, 다시 유지 관리 기간에 적용하려면 해당 작업을 다시 수행해야 합니다. Provider 유지 관리 작업은 보류 중인 유지 관리 목록으로 이동합니다. 보류 중인 유지 관리 목록에서 다시 준비 중인 유지 관리 작업으로 이동할 수 있습니다.

보류 중인 유지 관리

보류 중인 유지 관리는 NHN Cloud에서 제공하는 Provider 유지 관리 작업 목록입니다. 파라미터 그룹 변경 사항 적용, 하이퍼바이저 점검을 위한 마이그레이션 등의 작업이 포함됩니다.

항목 설명
설명 유지 관리 작업에 대한 설명입니다.
유형 유지 관리 작업의 유형입니다.
상태 유지 관리 작업의 현재 상태입니다.
필수 여부 필수 유지 관리 작업 여부를 나타냅니다.
강제 적용 일시 필수 작업은 이 일시 이후에 자동으로 적용됩니다.

보류 중인 유지 관리 작업을 선택한 후 다음을 클릭하여 적용 시점을 선택할 수 있습니다.

즉시 적용: 선택한 유지 관리 작업을 즉시 수행합니다. 확인을 클릭하면 바로 실행됩니다. db-instance-detail-maintenance-immediately_ko

다음 유지 관리 기간에 적용: 선택한 유지 관리 작업을 다음 유지 관리 기간에 수행합니다. 확인을 클릭하면 준비 중인 유지 관리 목록으로 이동합니다. db-instance-detail-maintenance-schedule_ko

주의

필수 유지 관리 작업은 강제 적용 일시 이전까지는 적용 시점을 선택할 수 있지만, 강제 적용 일시 이후에는 자동으로 다음 유지 관리 기간에 수행됩니다.

알아두기

유지 관리 작업 적용 시 재시작이 필요한 경우 장애 조치, 백업 등의 추가 옵션을 선택할 수 있는 팝업 화면이 나타납니다. 고가용성 DB 인스턴스는 장애 조치를 이용한 재시작을 사용하여 서비스 중단 시간을 최소화할 수 있습니다.

DB 인스턴스 수정

콘솔에서 생성된 DB 인스턴스의 다양한 항목을 손쉽게 변경할 수 있습니다. 변경 요청한 항목은 순차적으로 DB 인스턴스에 적용합니다. 적용 과정에서 재시작이 필요할 경우 모든 변경을 적용한 후 DB 인스턴스를 재시작합니다. 변경 불가능한 항목과 재시작이 필요한 항목은 다음과 같습니다.

항목 변경 가능 여부 재시작 필요 여부
가용성 영역 아니오
DB 엔진 예 예
DB 인스턴스 타입 예 예
데이터 스토리지 종류 아니오
이름 예 아니오
설명 예 아니오
DB 포트 예 예
VPC 서브넷 아니오
플로팅 IP 예 아니오
파라미터 그룹 예 변경된 파라미터의 재시작 여부에 따라 결정
DB 보안 그룹 예 아니오
백업 설정 예 아니오
스토리지 자동 확장 예 아니오

고가용성 DB 인스턴스는 재시작이 필요한 항목의 변경이 있으면 안정성을 높이고 순단 시간을 줄이기 위해 장애 조치를 이용한 재시작 기능을 제공합니다.

modify-ha-popup-ko

❶ 유지 관리 기능으로 다음 유지 관리 기간에 적용 또는 즉시 적용을 선택해 DB 인스턴스 수정을 수행할 수 있습니다. ❷ 장애 조치를 이용한 재시작을 사용하지 않으면 Primary와 Standby에 변경 사항을 순차적으로 적용한 후 DB 인스턴스를 재시작합니다. 자세한 사항은 고가용성 DB 인스턴스의 수동 장애 조치 항목을 참고합니다.

DB 인스턴스 운영체제 업그레이드

DB 인스턴스 운영체제 업그레이드를 지원합니다. 운영체제 업그레이드로 보안 취약점을 해결하거나 운영체제의 EOL에 대응할 수 있습니다. 운영체제 업그레이드는 서비스 순단이 발생하기 때문에 주의가 필요합니다. 고가용성 DB 인스턴스는 장애 조치로 서비스 순단을 최소화할 수 있습니다.

현재 DB 인스턴스의 운영체제 정보는 DB 인스턴스 상세 화면에서 확인할 수 있습니다. db-instance-os-upgrade-ko.png

❶ DB 인스턴스의 운영체제 정보를 확인할 수 있습니다. ❷ 운영체제가 버전 업그레이드 대상일 경우 운영체제 버전 업그레이드 버튼이 표시됩니다.

운영체제 버전 업그레이드는 고가용성 구성인지 아닌지에 따라 다르게 동작합니다. 고가용성 인스턴스에서는 장애 조치를 이용해 운영체제 버전 업그레이드를 수행합니다. 고가용성이 아닌 경우에는 DB 인스턴스를 재시작하여 운영체제 버전 업그레이드를 수행합니다.

단일 DB 인스턴스의 운영체제 버전 업그레이드 버튼을 클릭하면 아래와 같은 팝업 화면이 나타납니다. 단일 DB 인스턴스의 운영체제 버전 업그레이드 시에도 유지 관리 기능을 사용할 수 있습니다. db-instance-os-upgrade-single-popup-ko.png

고가용성 DB 인스턴스의 운영체제 버전 업그레이드 버튼을 클릭하면 아래와 같은 팝업 화면이 나타납니다. 자세한 사항은 고가용성 DB 인스턴스의 수동 장애 조치 항목을 참고합니다. os-upgrade-ha-popup-ko.png

❶ 유지 관리 적용 방법으로 유지 관리 기능을 사용할 수 있습니다. ❷ 장애 조치를 사용하는 방법만 제공됩니다.

DB 인스턴스 삭제

더 이상 사용하지 않는 DB 인스턴스는 삭제할 수 있습니다. Primary를 삭제하면 해당 복제 그룹에 속한 Standby와 Read Replica도 모두 함께 삭제됩니다. 삭제된 DB 인스턴스는 복구할 수 없으므로 중요한 DB 인스턴스는 삭제 보호 설정을 활성화하기를 권장합니다.

백업

장애 상황에 대비하여 DB 인스턴스의 데이터베이스를 복구할 수 있도록 미리 준비할 수 있습니다. 필요할 때마다 콘솔에서 백업을 수행하거나, 주기적으로 백업이 수행되도록 설정할 수 있습니다. 자세한 사항은 백업 항목을 참고합니다.

복원

백업을 이용하여 원하는 시점으로 데이터를 복원할 수 있습니다. 복원 시에는 항상 새로운 DB 인스턴스가 생성되며, 기존 DB 인스턴스에 복원할 수 없습니다. 자세한 사항은 복원 항목을 참고합니다.

용량 확보

급격한 부하로 바이너리 로그(binary log)가 과도하게 생성되어 데이터 스토리지의 용량이 부족할 경우 콘솔의 용량 확보 기능을 이용해 바이너리 로그를 삭제할 수 있습니다. 콘솔에서 용량 확보를 선택하면 DB 인스턴스의 바이너리 로그를 선택할 수 있는 팝업 화면이 표시됩니다. 바이너리 로그를 선택한 뒤 확인을 눌러 선택한 항목 이전에 생성된 모든 바이너리 로그를 삭제합니다. 용량 확보 기능은 일시적으로 용량을 확보하는 기능입니다. 계속해서 용량이 부족하다면 서비스 부하에 맞게 바이너리 로그의 저장 기간을 설정하거나 데이터 스토리지의 크기를 확장해야 합니다.

알아두기

binlog_expire_logs_seconds 파라미터로 바이너리 로그(binary log)의 저장 기간을 설정할 수 있습니다.

주의

삭제된 바이너리 로그(binary log)에 따라 특정 시점으로 복원되지 않을 수 있습니다.

스토리지 크기 확장

DB 인스턴스의 데이터 스토리지 크기를 확장할 수 있습니다. 확장 시 DB 인스턴스의 재시작 과정 없이 즉시 적용됩니다.

스토리지 자동 확장

DB 인스턴스의 데이터 스토리지 크기를 자동으로 확장할 수 있습니다. 스토리지 자동 확장을 사용하면 데이터 스토리지의 용량이 부족할 때 자동으로 확장하여 데이터베이스의 가용성을 유지할 수 있습니다.

스토리지 자동 확장을 사용하려면 DB 인스턴스 생성 및 수정 시 스토리지 자동 확장을 활성화해야 합니다.

스토리지 자동 확장을 활성화하면 세 가지 옵션을 설정할 수 있습니다. * 스토리지 자동 확장 조건: 스토리지 사용률이 설정한 값 이상으로 5분 이상 지속될 때 자동으로 스토리지를 확장합니다. * 스토리지 자동 확장 최댓값: 스토리지 자동 확장으로 확장될 수 있는 최대 크기입니다. * 스토리지 자동 확장 쿨다운: 스토리지 자동 확장 기능이 한 번 실행된 후, 다시 기능이 활성화되기까지의 시간을 설정합니다.

스토리지 자동 확장 기능이 실행될 때의 증가량은 다음 값 중 가장 큰 값으로 설정됩니다. * 10GB * 스토리지 크기의 10% * 직전 한 시간의 데이터 스토리지 사용량 증가분 * 쿨다운(시간으로 환산)

파라미터 그룹 변경 사항 적용

DB 인스턴스에 연결된 파라미터 그룹의 설정이 변경되어도 이 변경 사항은 DB 인스턴스에 자동으로 적용되지 않습니다. DB 인스턴스에 적용된 파라미터와 연결된 파라미터 그룹의 설정이 서로 다를 경우 파라미터 변경 적용 유지 관리가 생성되고 유지 관리 상태가 변경됩니다.

다음 방법으로 여러 DB 인스턴스 또는 단일 DB 인스턴스에 파라미터 그룹의 변경 사항을 적용할 수 있습니다.

db-instance-list-parameter-ko

❶ 대상 DB 인스턴스를 선택한 후 드롭다운 메뉴에서 파라미터 그룹 변경 사항 적용 메뉴를 클릭

유지 관리 기능으로 다음 유지 관리 기간에 적용 또는 즉시 적용을 선택해 파라미터 그룹 변경 사항을 적용할 수 있습니다.

파라미터 그룹에서 재시작이 필요한 파라미터가 변경된 경우, 변경 사항을 적용하는 과정에서 DB 인스턴스가 재시작됩니다.

고가용성 DB 인스턴스는 안정성을 높이고 순단 시간을 줄이기 위해 장애 조치를 이용한 재시작 기능을 제공합니다.

db-instance-parameter-ha-ko

장애 조치를 이용한 재시작을 사용하지 않으면 Primary와 Standby에 변경 사항을 순차적으로 적용한 후 DB 인스턴스를 재시작합니다. 자세한 사항은 고가용성 DB 인스턴스의 수동 장애 조치 항목을 참고합니다.

Object Storage에 있는 백업으로 복원

외부 MariaDB 백업 파일을 NHN Cloud의 Object Storage에 업로드하여 RDS for MariaDB의 DB 인스턴스로 복원할 수 있습니다. 자세한 사항은 외부 MariaDB 백업을 이용한 복원 항목을 참고합니다.

백업 후 Object Storage로 백업 파일 내보내기

백업 후 백업 파일을 Object Storage로 내보낼 수 있습니다. 자세한 사항은 백업 내보내기 항목을 참고합니다.

Read Replica

읽기 성능을 높이기 위해 읽기 전용으로 사용할 수 있는 Read Replica를 생성할 수 있습니다. Read Replica는 하나의 Primary당 최대 5대까지 생성할 수 있습니다. Read Replica의 Read Replica는 생성할 수 없습니다.

Read Replica 생성

Read Replica를 생성하려면 복제 그룹에 속한 DB 인스턴스 중 테이블 잠금 사용 옵션으로 생성된 백업 파일 및 바이너리 로그(binary log)가 필요합니다. 백업 파일이 없는 경우 다음 순서에 따라 백업을 수행할 DB 인스턴스를 선택합니다.

❶ 자동 백업 설정한 Read Replica ❷ 자동 백업 설정한 Standby ❸ 자동 백업 설정한 Primary

조건에 맞는 DB 인스턴스가 없을 경우 Read Replica 생성 요청은 실패합니다.

주의

Primary의 데이터베이스 크기에 비례하여 Read Replica 생성 시간이 늘어날 수 있습니다. 백업이 수행되는 DB 인스턴스는 Read Replica 생성 과정에서 스토리지 I/O 성능 하락이 있을 수 있습니다.

알아두기

Read Replica 생성 과정에 필요한 바이너리 로그(binary log) 크기만큼 백업 스토리지 과금이 발생할 수 있습니다.

Read Replica를 생성하려면 콘솔에서

db-instance-replica-create-ko

❶ 원본 DB 인스턴스를 선택한 뒤 Read Replica 생성을 클릭하면

다음 설정으로 Read Replica를 생성할 수 있습니다.

변경 불가 항목

Read Replica를 생성할 때 아래 나열된 항목은 원본 DB 인스턴스의 설정을 따르기 때문에 변경할 수 없습니다.

  • DB 엔진
  • 데이터 스토리지 종류
  • 사용자 VPC 서브넷

가용성 영역

Read Replica의 가용성 영역을 선택합니다. 자세한 설명은 가용성 영역 항목을 참고합니다.

DB 인스턴스 타입

Read Replica는 Primary와 동일한 사양 또는 더 높은 사양으로 만들기를 권장합니다. 낮은 사양으로 생성 시 복제 지연이 발생할 수 있습니다.

데이터 스토리지 크기

원본 DB 인스턴스와 동일한 크기로 만들기를 권장합니다. 크기를 작게 설정할 경우, 데이터 스토리지 용량 부족으로 복제 과정이 중단될 수 있습니다.

플로팅 IP

Read Replica의 플로팅 IP 사용 여부를 선택합니다. 자세한 설명은 플로팅 IP 항목을 참고합니다.

파라미터 그룹

Read Replica의 파라미터 그룹을 선택할 때 복제 관련 설정 변경이 필요 없다면 원본 DB 인스턴스와 동일한 파라미터 그룹을 선택하기를 권장합니다. 자세한 파라미터 그룹 내용은 파라미터 그룹 항목을 참고합니다.

DB 보안 그룹

Read Replica에 적용할 DB 보안 그룹을 선택합니다. 복제에 필요한 규칙은 자동으로 적용되기 때문에 DB 보안 그룹에 별도로 복제 관련 규칙을 추가할 필요가 없습니다. 자세한 DB 보안 그룹 내용은 DB 보안 그룹 항목을 참고합니다.

백업

Read Replica의 백업 설정을 선택합니다. 자세한 백업 내용은 백업 및 복원 항목을 참고합니다.

기본 알림

기본 알림 사용 여부를 선택합니다. 자세한 설명은 기본 알림 항목을 참고합니다.

삭제 보호

삭제 보호 사용 여부를 선택합니다. 자세한 설명은 삭제 보호 항목을 참고합니다.

Read Replica 승격

Primary와의 복제 관계를 해제하고 Read Replica를 독립된 Primary로 전환하는 과정을 승격이라고 합니다. 승격된 Primary는 독립된 DB 인스턴스로서 작동합니다. 승격을 원하는 Read Replica와 Primary 사이에 복제 지연이 존재하는 경우 해당 지연이 해결될 때까지 승격이 이루어지지 않습니다. 한 번 승격된 DB 인스턴스는 이전의 복제 관계로 되돌릴 수 없습니다.

주의

Primary DB 인스턴스의 상태가 비정상일 경우에는 승격 작업을 수행할 수 없습니다.

알아두기

Read Replica가 위치한 리전과 동일한 리전의 콘솔에서 승격 작업을 수행할 수 있습니다.

Read Replica 강제 승격

Primary나 원본 리전의 상태와 관계없이 Read Replica의 현재 시점 데이터를 기반으로 강제 승격을 수행합니다. 복제 지연이 있는 경우 데이터 유실이 발생할 수 있습니다. 따라서 Read Replica를 긴급하게 서비스에 투입해야 하는 상황이 아니라면 이 기능의 사용은 권장하지 않습니다.

Read Replica의 복제 중단

Read Replica는 여러 이유로 복제가 중단될 수 있습니다. Read Replica의 상태가 복제 중단인 경우 빠르게 원인을 확인하여 정상화해야 합니다. 복제 중단 상태가 장시간 지속될 경우 복제 지연이 늘어납니다. 정상화에 필요한 바이너리 로그(binary log)가 없는 경우 Read Replica를 재구축해야 합니다. 복제가 중단된 원인은 Read Replica에서 SHOW SLAVE STATUS 명령어로 확인할 수 있습니다. Last_Errno 값이 1062인 경우 아래 프로시저(procedure)를 오류가 사라질 때까지 호출할 수 있습니다.

mariadb> CALL mysql.tcrds_repl_skip_repl_error();

Read Replica의 재구축

Read Replica의 복제 문제를 해결할 수 없는 경우 재구축으로 정상 상태로 복원할 수 있습니다. 이 과정에서 Read Replica의 모든 데이터베이스를 삭제하고, Primary 데이터베이스를 기반으로 새롭게 재구축합니다. 재구축하는 동안 Read Replica는 사용할 수 없습니다. Read Replica를 재구축하려면 복제 그룹에 속한 DB 인스턴스 중 테이블 잠금 사용 옵션으로 생성된 백업 파일 및 바이너리 로그(binary log)가 필요합니다. 백업 파일이 없는 경우 동작 및 주의 사항은 Read Replica 생성 항목을 참고합니다.

알아두기

재구축 후에도 접속 정보(도메인, IP)는 변경되지 않습니다.

DB 인스턴스 재시작

MariaDB을 재시작하거나 고가용성 DB 인스턴스를 수동으로 장애 조치하려면 DB 인스턴스를 재시작할 수 있습니다. 재시작 시간을 최소화하기 위해 서비스 부하가 낮은 시간대에 수행하기를 권장합니다. 고가용성 DB 인스턴스는 장애 조치를 이용한 재시작을 사용하지 않으면 Standby를 먼저 재시작한 뒤 Primary를 재시작합니다. 장애 조치 기능을 이용한 재시작은 수동 장애 조치 항목을 참고합니다.

DB 인스턴스 재시작을 하려면 콘솔에서

db-instance-restart-ko

❶ 재시작을 원하는 DB 인스턴스를 선택 후 드롭다운 메뉴에서 DB 인스턴스 재시작 메뉴를 클릭합니다.

DB 인스턴스 강제 재시작

DB 인스턴스의 MariaDB이 정상 동작하지 않는 경우 강제로 재시작할 수 있습니다. 강제 재시작 시 MariaDB에 SIGTERM 명령을 내려 정상 종료되기를 10분간 기다립니다. 10분 안에 MariaDB이 정상 종료되면 이후 가상 머신을 재부팅합니다. 10분 안에 정상 종료되지 않으면 가상 머신을 강제로 재부팅합니다. 가상 머신이 강제로 재부팅되면 작업 중인 일부 트랜잭션이 유실될 수 있으며, 데이터 볼륨이 손상되어 복구가 불가능해질 수 있습니다. 강제 재시작 이후에도 DB 인스턴스의 상태가 사용 가능 상태로 돌아오지 않을 수 있습니다. 해당 상황이 발생하면 고객지원으로 문의하세요.

주의

데이터가 유실되거나 데이터 볼륨이 손상될 가능성이 있으므로 해당 기능은 긴급하고 불가피한 상황 이외에는 사용을 지양해야 합니다.

알아두기

고가용성 DB 인스턴스는 강제 재시작할 수 없습니다.

DB 인스턴스 강제 재시작을 하려면 콘솔에서

db-instance-restart-force-ko

❶ 강제 재시작을 원하는 DB 인스턴스를 선택 후 드롭다운 메뉴에서 DB 인스턴스 강제 재시작 메뉴를 클릭합니다.

삭제 보호 설정 변경

삭제 보호를 활성화하면 실수로 DB 인스턴스가 삭제되지 않도록 보호할 수 있습니다. 삭제 보호를 비활성화할 때까지 해당 DB 인스턴스를 삭제할 수 없습니다. 삭제 보호 설정을 변경하려면

db-instance-deletion-protection-ko

❶ 삭제 보호 설정을 변경하려는 DB 인스턴스를 선택 후 드롭다운 메뉴에서 삭제 보호 설정 변경 메뉴를 클릭하면 팝업 창이 나타납니다.

deletion-protection-popup-ko

❷ 삭제 보호 설정을 변경한 후 확인을 클릭합니다.

고가용성 DB 인스턴스

고가용성 DB 인스턴스는 가용성과 데이터 내구성을 높이고, 장애를 허용하는 데이터베이스를 제공합니다. 고가용성 DB 인스턴스는 Primary, Standby로 구성되며 서로 다른 가용성 영역에 생성됩니다. Standby는 장애에 대비한 DB 인스턴스로 평소에는 사용할 수 없습니다. 고가용성 DB 인스턴스는 Standby에서 백업이 수행됩니다.

알아두기

고가용성 DB 인스턴스에서 MariaDB 쿼리문을 사용해 다른 DB 인스턴스 또는 외부 MariaDB의 Master로부터 강제로 복제하도록 설정하면 고가용성 및 일부 기능이 정상적으로 동작하지 않습니다.

장애 감지

Standby에는 장애를 감지하기 위한 프로세스가 있으며 주기적으로 Primary의 상태를 감지합니다. 이러한 감지 주기를 Ping 간격이라고 하며 4회 연속 상태 체크에 실패하면 장애 조치를 수행합니다. Ping 간격이 짧을수록 장애에 민감하게 반응하며, Ping 간격이 길수록 장애에 둔감하게 반응합니다. 서비스 부하에 맞게 적절한 Ping 간격을 설정하는 것이 중요합니다.

알아두기

Primary의 데이터 스토리지 사용량이 가득 차면 고가용성 감시 프로세스가 장애로 감지해 장애 조치를 수행하므로 주의해야 합니다.

자동 장애 조치

Standby에서 Primary의 상태 체크에 4회 연속 실패할 경우 Primary가 서비스를 제공하지 못한다고 판단하여 자동으로 장애 조치를 수행합니다. 스플릿 브레인이 발생하지 않도록 장애가 발생한 Primary에 할당된 모든 사용자 보안 그룹의 연결을 해제하여 외부의 접속을 차단하며, Standby가 Primary의 역할을 대신합니다. 접속을 위한 내부 도메인의 A record는 장애가 발생한 Primary에서 Standby로 변경되므로, 응용 프로그램의 변경은 필요하지 않습니다. 장애 조치가 완료되면 장애가 발생한 Primary의 종류는 Failed Over Primary로, Standby의 종류는 Primary로 변경됩니다. Failed Over Primary를 복구하거나 재구축하기 전까지 장애 조치가 수행되지 않습니다. 새 Primary는 Failed Over Primary의 모든 자동 백업을 승계합니다. 장애 조치 과정에서 Primary가 변경되면 바이너리 로그가 모두 삭제되므로 기존 백업을 이용한 시점 복원은 지원하지 않습니다. 새 Primary에서 신규로 백업이 수행된 시각부터 시점 복원을 할 수 있습니다.

알아두기

고가용성 기능은 도메인을 기반으로 하고 있기 때문에 접속을 시도하는 클라이언트가 DNS 서버에 접속할 수 없는 네트워크 환경일 경우 도메인을 통해 DB 인스턴스에 접속할 수 없고, 장애 조치 발생 시 정상적인 접속이 불가능합니다. 내부 도메인의 A record 변경이 반영되는 데 약 3초 정도 소요됩니다. 소요 시간은 접속을 시도하는 클라이언트 환경의 DNS Cache 정책에 따라 달라질 수 있습니다.

주의

Primary와 Standby 간의 바이너리 로그(binary log)의 position number 값이 100,000,000 이상 차이가 날 경우 장애 조치가 되지 않습니다. replicate-ignore-db 또는 replicate-ignore-table이 적용된 경우, 해당 DB 또는 테이블의 변경 사항은 복제되지 않으므로 장애 조치에 실패할 수 있습니다.

Failed Over Primary

장애가 발생하여 장애 조치된 Primary를 Failed Over Primary라고 합니다. Failed Over Primary의 자동 백업은 수행되지 않으며, Failed Over Primary 복구, 재구축, 분리, 삭제를 제외한 다른 모든 기능은 수행할 수 없습니다.

Failed Over Primary 복구

장애 조치 과정에서 데이터의 정합성이 깨지지 않았고, 장애가 발생한 시점부터 복구를 시도하는 시점까지 바이너리 로그(binary log)가 유실되지 않았다면 Failed Over Primary와 새 Primary를 다시 고가용성 구성으로 복구할 수 있습니다. Failed Over Primary의 데이터베이스 그대로 새 Primary와 복제 관계를 다시 설정하므로 데이터의 정합성이 깨졌거나 복구에 필요한 바이너리 로그(binary log)가 유실되었다면 복구는 실패합니다. Failed Over Primary 복구에 실패할 경우 재구축으로 다시 고가용성 기능을 활성화할 수 있습니다.

알아두기

2023년 4월 11일 이전에 장애 조치가 발생한 DB 인스턴스는 복구를 지원하지 않습니다.

Failed Over Primary를 복구하려면 콘솔에서

db-instance-failover-repair-ko

❶ 복구를 원하는 Failed Over Primary를 선택 후 드롭다운 메뉴에서 Failed Over Primary 복구 메뉴를 클릭합니다.

Failed Over Primary 재구축

Failed Over Primary 복구에 실패할 경우 재구축을 이용해 다시 고가용성 기능을 활성화할 수 있습니다. 재구축은 복구와 달리 Failed Over Primary의 데이터베이스를 모두 제거하고, 새 Primary의 데이터베이스를 토대로 재구축합니다. Failed Over Primary를 재구축하려면 복제 그룹에 속한 DB 인스턴스 중 테이블 잠금 사용 옵션으로 생성된 백업 파일 및 바이너리 로그(binary log)가 필요합니다. 백업 파일이 없는 경우 다음 순서에 따라 백업을 수행할 DB 인스턴스를 선택합니다.

❶ 자동 백업 설정한 Read Replica ❷ 자동 백업 설정한 Primary

조건에 맞는 DB 인스턴스가 없을 경우 Failed Over Primary 재구축 요청은 실패합니다.

주의

Primary의 데이터베이스 크기에 비례하여 Failed Over Primary 재구축 시간이 늘어날 수 있습니다. 백업이 수행되는 DB 인스턴스는 Failed Over Primary 재구축 과정에서 스토리지 I/O 성능 하락이 있을 수 있습니다.

알아두기

Failed Over Primary 재구축 과정에 필요한 바이너리 로그(binary log) 크기만큼 백업 스토리지 과금이 발생할 수 있습니다.

Failed Over Primary를 재구축하려면 콘솔에서

db-instance-failover-rebuild-ko

❶ 재구축을 원하는 Failed Over Primary를 선택 후 드롭다운 메뉴에서 Failed Over Primary 재구축 메뉴를 클릭합니다.

Failed Over Primary 분리

Failed Over Primary 복구에 실패하여 데이터 보정이 필요할 경우 Failed Over Primary를 분리하여 고가용성 기능을 비활성화할 수 있습니다. 분리된 Primary와 새 Primary 간의 복제 관계가 끊어지며 각각 일반 DB 인스턴스로 동작합니다. 분리된 이후에는 다시 원래 구성으로 복구가 불가능합니다.

Failed Over Primary를 분리하려면 콘솔에서

db-instance-failover-split-ko

❶ 분리를 원하는 Failed Over Primary를 선택 후 드롭다운 메뉴에서 Failed Over Primary 분리 메뉴를 클릭합니다.

수동 장애 조치

고가용성 DB 인스턴스는 재시작이 동반되는 작업을 수행하면 장애 조치를 이용한 재시작 여부를 선택할 수 있으며, 해당 작업은 아래와 같습니다.

  • DB 인스턴스 재시작
  • 재시작이 필요한 항목의 변경
  • 재시작이 필요한 파라미터의 변경을 적용
  • 하이퍼바이저 점검을 위한 DB 인스턴스 마이그레이션

장애 조치를 이용한 재시작을 하면 Standby를 먼저 재시작합니다. 이후 장애 조치로 Standby가 Primary가 되고 기존 Primary는 Standby 역할을 합니다. 이때 접속을 위한 내부 도메인의 A record는 Primary에서 Standby로 변경되므로, 응용 프로그램의 변경은 필요하지 않습니다. 새 Primary는 이전 Primary의 모든 자동 백업을 승계합니다. 장애 조치 과정에서 Primary가 변경되며 바이너리 로그(binary log)가 모두 삭제되기 때문에 기존 백업을 이용한 시점 복원은 지원하지 않습니다. 새 Primary에서 신규로 백업이 수행된 시각부터 시점 복원을 할 수 있습니다.

알아두기

고가용성 기능은 도메인을 기반으로 하고 있기 때문에 접속을 시도하는 클라이언트가 DNS 서버에 접속할 수 없는 네트워크 환경일 경우 도메인을 통해 DB 인스턴스에 접속할 수 없고, 장애 조치 발생 시 정상적인 접속이 불가능합니다. 내부 도메인의 A record 변경이 반영되는 데 약 3초 정도 소요됩니다. 소요 시간은 접속을 시도하는 클라이언트 환경의 DNS Cache 정책에 따라 달라질 수 있습니다.

주의

Standby와 복제 그룹에 포함된 Read Replica의 Seconds_Behind_Master 값이 1 이상일 경우 복제 지연이 발생한 것으로 간주하며, 이때 수동 장애 조치는 실패합니다. 부하가 적은 시간에 수동 장애 조치를 수행하기를 권장합니다. 복제 지연으로 인한 재시작 실패는 이벤트 화면에서 확인할 수 있습니다.

장애 조치를 이용한 재시작 시 다음의 항목을 추가로 선택하여 안정성을 높일 수 있습니다.

현재 시점 백업 진행

장애 조치 과정에서 바이너리 로그(binary log)가 모두 삭제되기 때문에 장애 조치를 이용한 재시작이 완료된 후 곧바로 수동 백업을 수행할 수 있습니다.

장애 조치 수동 제어

Standby에 변경 사항을 먼저 적용한 뒤 그 추이를 관찰하거나, 정확한 시간에 장애 조치를 실행하고자 할 때 콘솔에서 장애 조치 시점을 직접 제어할 수 있습니다. 장애 조치 수동 제어를 선택하면 Standby가 재시작된 후 ❶ 콘솔에 장애 조치 버튼이 표시됩니다. 이 버튼을 클릭하면 장애 조치가 실행되며, 최대 5일간 실행을 대기할 수 있습니다. 5일 이내에 장애 조치를 실행하지 않을 경우 해당 작업은 자동으로 취소됩니다.

db-instance-ha-wait-manual-failover-ko

주의

장애 조치를 대기하는 동안에는 자동 장애 조치가 되지 않습니다.

복제 지연 해소 대기

복제 지연 해소 대기 옵션을 활성화하면 Standby와 복제 그룹에 포함된 Read Replica의 복제 지연이 사라질 때까지 대기할 수 있습니다.

쓰기 부하 차단

복제 지연을 해소하는 동안 쓰기 부하를 추가로 차단할 수 있습니다. 쓰기 부하를 차단하면 장애 조치를 수행하기 바로 전에 Primary가 읽기 전용 모드로 전환되어 모든 변경 쿼리가 실패하도록 설정됩니다.

고가용성 일시 중지

일시적인 작업으로 인한 연결 중단 또는 대량의 부하가 예상되는 상황에서 일시적으로 고가용성 기능을 중지할 수 있습니다. 고가용성 기능이 일시 중지되면 장애를 감지하지 않으므로 장애 조치를 수행하지 않습니다. 고가용성 기능이 일시 중지된 상태에서 재시작이 필요한 작업을 수행해도 일시 중지된 고가용성 기능이 재개되지 않습니다. 고가용성 기능이 일시 중지되어도 데이터 복제는 정상적으로 이루어지지만 장애가 감지되지 않기 때문에 장시간 일시 중지 상태로 유지하기를 권장하지 않습니다.

Standby 재구축

네트워크의 단절, 잘못된 FEDERATED 엔진 사용, 다른 Primary로부터의 복제 설정과 같은 다양한 원인으로 Standby 복제가 중단될 수 있습니다. 복제 중단 상태의 Standby는 자동 장애 조치가 실행되지 않습니다. Standby의 복제 중단을 해결하려면 Standby를 재구축해야 합니다. Standby 재구축 시에는 Standby의 데이터베이스를 모두 제거하며, Primary의 데이터베이스를 토대로 재구축합니다. 이 과정에서 재구축에 필요한 백업 파일이 Primary 데이터베이스에 존재하지 않을 경우 Primary에서 백업이 수행되며, 백업으로 인한 성능 저하가 발생할 수 있습니다.

MariaDB Procedure

RDS for MariaDB은 사용자의 편의를 제공하기 위해 사용자 계정에서 제한되는 몇몇 기능을 수행하는 프로시저를 자체적으로 제공합니다.

tcrds_active_process

  • Processlist에서 Sleep 상태가 아닌 ACTIVE 상태의 쿼리를 조회합니다.
  • 수행 시간이 오래된 순서로 출력되며 쿼리 내용(SQL)은 100자리까지만 출력됩니다.
mariadb> CALL mysql.tcrds_active_process();

tcrds_process_kill

  • 특정 프로세스를 강제 종료합니다.
  • 종료할 프로세스 아이디는 information_schema.processlist에서 확인할 수 있으며 tcrds_active_process와 tcrds_current_lock 프로시저를 사용하여 프로세스 정보를 확인할 수 있습니다.
mariadb> CALL mysql.tcrds_process_kill(processlist_id );

tcrds_current_lock

  • 현재 락을 기다리고 있는 프로세스와 락을 점유하고 있는 프로세스 정보를 확인합니다.
  • (w) 칼럼 정보가 락을 획득하기 위해 대기하는 프로세스 정보
  • (B) 칼럼 정보가 락을 점유하고 있는 프로세스 정보
  • 락을 점유하는 프로세스를 강제로 종료하려면 (B)PROCESS 칼럼을 확인한 후, call tcrds_process_kill(process_id)를 수행합니다.
mariadb> CALL mysql.tcrds_current_lock();

tcrds_repl_changemaster (8.4 이전)

  • 복제를 이용해 외부 MariaDB DB를 NHN Cloud RDS로 가져올 때 사용합니다.
  • NHN Cloud RDS의 복제 구성은 콘솔의 복제본 생성으로 할 수 있습니다.
mariadb> CALL mysql.tcrds_repl_changemaster (master_instance_ip, master_instance_port, user_id_for_replication, password_for_replication_user, MASTER_LOG_FILE, MASTER_LOG_POS);
  • 파라미터 설명
    • master_instance_ip: 복제 대상(Master) 서버의 IP
    • master_instance_port: 복제 대상(Master) 서버의 MariaDB 포트
    • user_id_for_replication: 복제 대상(Master) 서버의 MariaDB에 접속할 복제용 계정
    • password_for_replication_user: 복제용 계정 패스워드
    • MASTER_LOG_FILE: 복제 대상(Master)의 binary log 파일명
    • MASTER_LOG_POS: 복제 대상(Master)의 binary log 포지션
ex) call mysql.tcrds_repl_changemaster('10.162.1.1',10000,'db_repl','password','mysql-bin.000001',4);

주의

복제용 계정이 복제 대상(Master) MariaDB에 생성되어 있어야 합니다.

tcrds_repl_changesource (8.4 이후)

  • 복제를 이용해 외부 MariaDB DB를 NHN Cloud RDS로 가져올 때 사용합니다.
  • NHN Cloud RDS의 복제 구성은 콘솔의 복제본 생성으로 할 수 있습니다.
mariadb> CALL mysql.tcrds_repl_changesource (master_instance_ip, master_instance_port, user_id_for_replication, password_for_replication_user, SOURCE_LOG_FILE, SOURCE_LOG_POS);
  • 파라미터 설명
    • master_instance_ip: 복제 대상(Master) 서버의 IP
    • master_instance_port: 복제 대상(Master) 서버의 MariaDB 포트
    • user_id_for_replication: 복제 대상(Master) 서버의 MariaDB에 접속할 복제용 계정
    • password_for_replication_user: 복제용 계정 패스워드
    • SOURCE_LOG_FILE: 복제 대상(Master)의 binary log 파일명
    • SOURCE_LOG_POS: 복제 대상(Master)의 binary log 포지션
예:  call mysql.tcrds_repl_changesource('10.162.1.1',10000,'db_repl','password','mysql-bin.000001',4);

주의

복제용 계정이 복제 대상(Master) MariaDB에 생성되어 있어야 합니다.

tcrds_repl_init

  • MariaDB 복제 정보를 초기화합니다.
mariadb> CALL mysql.tcrds_repl_init();

tcrds_repl_slave_stop (8.4 이전)

  • MariaDB 복제를 멈춥니다.
mariadb> CALL mysql.tcrds_repl_slave_stop();

tcrds_repl_replica_stop (8.4 이후)

  • MariaDB 복제를 멈춥니다.
mariadb> CALL mysql.tcrds_repl_replica_stop();

tcrds_repl_slave_start (8.4 이전)

  • MariaDB 복제를 시작합니다.
mariadb> CALL mysql.tcrds_repl_slave_start();

tcrds_repl_replica_start (8.4 이후)

  • MariaDB 복제를 시작합니다.
mariadb> CALL mysql.tcrds_repl_replica_start();

tcrds_repl_skip_repl_error

  • 다음과 같은 Duplicate key 오류 발생 시 tcrds_repl_skip_repl_error 프로시저를 실행하면 복제 오류를 해결할 수 있습니다.
    • 8.4 이전: SQL_SLAVE_SKIP_COUNTER=1을 수행합니다.
    • 8.4 이후: SQL_REPLICA_SKIP_COUNTER=1을 수행합니다.
  • MariaDB error code 1062: 'Duplicate entry ? for key ?'
mariadb> CALL mysql.tcrds_repl_skip_repl_error();

tcrds_repl_next_changemaster (8.4 이전)

  • Master의 다음 바이너리 로그(binary log)를 읽을 수 있도록 복제 정보를 변경합니다.
  • 다음과 같은 복제 오류 발생 시 tcrds_repl_next_changemaster 프로시저를 실행하면 복제 오류를 해결할 수 있습니다.

예: MariaDB error code 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG): Got fatal error from master when reading data from binary log

mariadb> CALL mysql.tcrds_repl_next_changemaster();

tcrds_repl_next_changesource (8.4 이후)

  • Master의 다음 바이너리 로그(binary log)를 읽을 수 있도록 복제 정보를 변경합니다.
  • 다음과 같은 복제 오류 발생 시 tcrds_repl_next_changesource 프로시저를 실행하면 복제 오류를 해결할 수 있습니다.

예: MariaDB error code 1236 (ER_SOURCE_FATAL_ERROR_READING_BINLOG): Got fatal error from source when reading data from binary log

mariadb> CALL mysql.tcrds_repl_next_changesource();

tcrds_innodb_monitor_reset

  • information_schema.INNODB_METRICS 테이블의 counter를 0으로 재설정하는 innodb_monitor_reset variables를 실행하는 프로시저입니다.
  • SET GLOBAL innodb_monitor_reset = '{counter-name|module_name|pattern|all}'; 쿼리를 실행합니다.
  • innodb_monitor_enable, innodb_monitor_disable는 RDS 파라미터로 제공합니다.
mariadb> CALL mysql.tcrds_innodb_monitor_reset('{counter-name|module_name|pattern|all}');
ex) CALL mysql.tcrds_innodb_monitor_reset('dml_reads');
CALL mysql.tcrds_innodb_monitor_reset('module_dml');

tcrds_innodb_monitor_reset_all

  • counter 값을 재설정하는 innodb_monitor_reset_all variables를 실행하는 프로시저입니다.
  • innodb_monitor_reset_all을 사용하려면 counter가 disable 상태여야 합니다.
  • SET GLOBAL innodb_monitor_reset_all = '{counter-name|module_name|pattern|all}'; 쿼리를 실행합니다.
mariadb> CALL mysql.tcrds_innodb_monitor_reset_all('{counter-name|module_name|pattern|all}');

tcrds_foreign_key_checks

  • foreign key 제약 조건을 체크하는 foreign_key_checks 변수를 제어하는 프로시저입니다.
  • SET GLOBAL foreign_key_checks ='ON|OFF'; 쿼리를 실행합니다.
mariadb> CALL mysql.tcrds_foreign_key_checks('{0|1|'OFF'|'ON'}');

데이터 마이그레이션

  • RDS는 mysqldump를 사용하여 NHN Cloud RDS의 외부로 데이터를 내보내거나 외부에서 가져올 수 있습니다.
  • mysqldump 유틸리티는 MariaDB을 설치했을 때 기본으로 제공됩니다.

mysqldump를 이용하여 내보내기

  • NHN Cloud RDS의 인스턴스를 준비하여 사용합니다.
  • 내보낼 데이터를 저장할 외부 인스턴스, 또는 로컬 클라이언트가 설치된 컴퓨터의 용량이 충분히 확보되어 있는지 확인합니다.
  • NHN Cloud의 외부로 데이터를 내보내야 할 경우 플로팅 IP를 생성하여 데이터를 내보낼 RDS 인스턴스에 연결합니다.
  • 다음 mysqldump 명령어로 외부로 데이터를 내보냅니다.

파일로 내보낼 경우

mysqldump -h{rds_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}

NHN Cloud RDS 외부의 MariaDB DB로 내보낼 경우

mysqldump -h{rds_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port}

mysqldump를 이용하여 가져오기

  • 데이터를 가져올 NHN Cloud RDS 외부의 DB를 준비합니다.
  • 가져올 NHN Cloud RDS 인스턴스의 용량이 충분한지 확인합니다.
  • 플로팅 IP를 생성하여 NHN Cloud RDS 인스턴스에 연결합니다.
  • 다음 mysqldump 명령어로 외부에서 데이터를 가져옵니다.
mysqldump -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port} --single-transaction --set-gtid-purged=off --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{rds_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port}

데이터 가져오는 도중 ERROR 1227 오류가 발생할 경우

  • ERROR 1227 오류는 mysqldump 파일의 저장된 객체(트리거, 뷰, 함수 또는 이벤트)에 DEFINER 정의가 되어 있을 때 발생합니다. 이 오류를 해결하려면 mysqldump 파일에서 DEFINER 부분을 삭제한 후 다시 적용합니다.

데이터 가져오는 도중 ERROR 1418 오류가 발생할 경우

  • ERROR 1418 오류는 mysqldump 파일의 함수 선언에 NO SQL, READS SQL DATA, DETERMINISTIC이 없으며 바이너리 로그가 활성화된 상태일 때 발생합니다.
  • 이 오류를 해결하려면 mysqldump 파일을 적용할 DB 인스턴스의 log_bin_trust_function_creators 파라미터의 값을 1로 변경해야 합니다.

복제를 이용하여 내보내기

  • 복제를 사용하여 NHN Cloud RDS의 데이터를 외부의 DB로 내보낼 수 있습니다.
  • 외부의 DB 버전은 NHN Cloud RDS의 버전과 같거나 그보다 최신 버전이어야 합니다.
  • 데이터를 내보낼 NHN Cloud RDS Primary 또는 Read Replica 인스턴스를 준비합니다.
  • 플로팅 IP를 생성하여 데이터를 내보낼 NHN Cloud RDS 인스턴스에 연결합니다.
  • 아래 명령어로 NHN Cloud RDS 인스턴스에서 데이터를 파일로 내보냅니다.
  • Primary RDS 인스턴스에서 내보낼 경우
mysqldump -h{rds_master_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
  • Read Replica RDS 인스턴스에서 내보낼 경우
mysqldump -h{rds_read_only_slave_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
  • 백업된 파일을 열어 주석에 적힌 MASTER_LOG_FILE 및 MASTER_LOG_POS를 따로 기록합니다.
  • NHN Cloud RDS 인스턴스에서 데이터를 백업할 외부 로컬 클라이언트 또는 DB가 설치된 컴퓨터의 용량이 충분한지 확인합니다.
  • 외부 DB의 my.cnf(Windows의 경우 my.ini) 파일에 다음과 같은 옵션을 추가합니다.
  • server-id는 NHN Cloud RDS 인스턴스의 파라미터 항목의 server-id와 다른 값으로 입력합니다.
...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...
  • 외부 DB를 재시작합니다.
  • 백업된 파일을 아래 명령어로 외부의 DB에 입력합니다.
mysql -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port} < {local_path_and_file_name}
  • NHN Cloud RDS 인스턴스에서 복제에 사용할 계정을 생성합니다.
  • 새롭게 복제를 설정하기에 앞서 혹시 존재할 수 있는 기존 복제 정보를 초기화하기 위해 다음 쿼리를 실행합니다. 이때, RESET SLAVE를 실행할 경우 기존 복제 정보가 초기화됩니다.
8.4 이전
STOP SLAVE;

RESET SLAVE;
8.4 이후
STOP REPLICA;

RESET REPLICA;
  • 복제에 사용할 계정 정보와 앞에서 기록해 둔 MASTER_LOG_FILE과 MASTER_LOG_POS를 사용하여 외부 DB에 아래와 같이 쿼리를 실행합니다.
8.4 이전
CHANGE MASTER TO master_host = '{rds_master_instance_floating_ip}', master_user='{user_id_for_replication}', master_password='{password_forreplication_user}', master_port ={rds_master_instance_port}, master_log_file ='{MASTER_LOG_FILE}', master_log_pos = {MASTER_LOG_POS};

START SLAVE;
8.4 이후
CHANGE REPLICATION SOURCE TO source_host = '{rds_master_instance_floating_ip}', source_user='{user_id_for_replication}', source_password='{password_forreplication_user}', source_port ={rds_master_instance_port}, source_log_file ='{SOURCE_LOG_FILE}', source_log_pos = {SOURCE_LOG_POS};

START REPLICA;
  • 외부 DB와 NHN Cloud RDS 인스턴스의 원본 데이터가 같아지면 외부 DB에 STOP SLAVE 명령으로 복제를 종료합니다.

복제를 이용하여 가져오기

  • 복제로 외부 DB를 NHN Cloud RDS로 가져올 수 있습니다.
  • NHN Cloud RDS 버전은 외부 DB 버전과 같거나 그보다 최신 버전이어야 합니다.
  • 데이터를 내보낼 외부 MariaDB 인스턴스에 연결합니다.
  • 아래 명령어로 외부 MariaDB 인스턴스에서 데이터를 백업합니다.
  • 외부 MariaDB 인스턴스(마스터)에서 가져올 경우
mysqldump -h{master_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
  • 외부 MariaDB 인스턴스(슬레이브)에서 가져올 경우
mysqldump -h{slave_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
  • 백업된 파일을 열어 주석의 MASTER_LOG_FILE 및 MASTER_LOG_POS를 따로 기록합니다.
  • NHN Cloud RDS 인스턴스에서 데이터를 백업할 클라이언트나 컴퓨터의 용량이 충분한지 확인합니다.
  • 외부 DB의 my.cnf(Windows의 경우 my.ini) 파일에 다음 옵션을 추가합니다.
  • server-id는 NHN Cloud RDS 인스턴스의 파라미터 항목의 server-id와 다른 값으로 입력합니다.
...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...
  • 외부 DB를 재시작합니다.
  • 외부 네트워크를 통해 가져오면(import) 오래 걸릴 수 있어 내부 NHN Cloud Image를 생성하고 백업 파일을 복사한 후, NHN Cloud로 가져오기를 권장합니다.
  • 백업된 파일을 다음 명령어로 NHN Cloud RDS에 입력합니다.
  • 복제 구성은 DNS를 지원하지 않으므로 IP로 변환해 실행합니다.
mysql -h{rds_master_instance_floating_ip} -u{db_id} -p{db_password} --port={db_port} < {local_path_and_file_name}
  • 외부 MariaDB 인스턴스에서 복제에 사용할 계정을 생성합니다.
8.4 이전
mariadb> CREATE USER 'user_id_for_replication'@'{external_db_host}' IDENTIFIED BY '<password_forreplication_user>';
mariadb> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'user_id_for_replication'@'{external_db_host}';
8.4 이후
mariadb> CREATE USER 'user_id_for_replication'@'{external_db_host}' IDENTIFIED BY '<password_forreplication_user>';
mariadb> GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'user_id_for_replication'@'{external_db_host}';
  • 복제에 사용할 계정 정보와 앞에서 기록해 둔 MASTER_LOG_FILE, MASTER_LOG_POS를 사용하여 NHN Cloud RDS에 다음과 같이 쿼리를 실행합니다.
8.4 이전
mariadb> call mysql.tcrds_repl_changemaster ('rds_master_instance_floating_ip',rds_master_instance_port,'user_id_for_replication','password_forreplication_user','MASTER_LOG_FILE',MASTER_LOG_POS );
8.4 이후
mariadb> call mysql.tcrds_repl_changesource ('rds_master_instance_floating_ip',rds_master_instance_port,'user_id_for_replication','password_forreplication_user','SOURCE_LOG_FILE',SOURCE_LOG_POS );
  • 복제를 시작하려면 다음 프로시저를 실행합니다.
8.4 이전
mariadb> call mysql.tcrds_repl_slave_start;
8.4 이후
mariadb> call mysql.tcrds_repl_replica_start;
  • 외부 DB와 NHN Cloud RDS 인스턴스의 원본 데이터가 같아지면 다음 명령으로 복제를 종료합니다.
mariadb> call mysql.tcrds_repl_init();

부록

부록1. 하이퍼바이저 점검을 위한 DB 인스턴스 마이그레이션 가이드

NHN Cloud는 주기적으로 DB 인스턴스의 하이퍼바이저 소프트웨어를 업데이트하여 보안과 안정성을 높이고 있습니다. 점검 대상 하이퍼바이저에서 구동 중인 DB 인스턴스는 마이그레이션으로 점검이 완료된 하이퍼바이저로 이동해야 합니다.

DB 인스턴스 마이그레이션은 NHN Cloud 콘솔에서 시작할 수 있습니다. DB 구성에 따라 특정 DB 인스턴스를 선택하여 마이그레이션 시, 연관된 DB 인스턴스(예: Read Replica 인스턴스)도 점검 대상이면 같이 마이그레이션을 수행합니다. 아래 가이드에 따라 콘솔에 있는 마이그레이션 기능을 사용하세요. 점검 대상으로 지정된 DB 인스턴스가 있는 프로젝트로 이동합니다.

1. 점검 대상 DB 인스턴스를 확인합니다.

DB 인스턴스 탭의 목록에서 점검 대상 DB 인스턴스를 확인합니다. 유지 관리에서 필수를 클릭하거나 DB 인스턴스 상세의 유지 관리 탭에서 하이퍼바이저 마이그레이션 유지 관리 작업이 있는지 확인할 수 있습니다. 하이퍼바이저 마이그레이션 유지 관리 작업의 보기를 클릭하면 하이퍼바이저 마이그레이션의 자세한 점검 내용을 확인할 수 있습니다.

2. 점검 대상 DB 인스턴스에 접속 중인 응용 프로그램을 종료해야 합니다.

DB에 연결된 서비스에 영향을 주지 않도록 적절한 조치를 취하세요. 서비스에 영향을 줄 수밖에 없을 때는 NHN Cloud 고객지원으로 문의하면 적합한 조치를 안내해 드립니다.

3. 점검 대상의 DB 인스턴스 마이그레이션을 적용할 수 있습니다.

마이그레이션을 적용할 DB 인스턴스를 선택한 후 즉시 적용을 클릭해 하이퍼바이저 마이그레이션을 바로 적용할 수 있습니다. 다음 유지 관리 기간에 적용을 클릭하면 원하는 유지 관리 기간에 하이퍼바이저 마이그레이션을 적용할 수 있습니다.

4. DB 인스턴스 마이그레이션이 끝날 때까지 대기합니다.

DB 인스턴스 상태가 변경되지 않는다면 새로 고침하세요. DB 인스턴스를 마이그레이션하는 동안에는 아무런 조작을 할 수 없습니다. DB 인스턴스 마이그레이션이 정상적으로 완료되지 않으면 자동으로 관리자에게 보고되며, NHN Cloud에서 별도로 연락드립니다.

부록2. RDS를 이용하여 Federated Storage Engine 사용 시 구성 가이드

Federated Storage Engine을 사용하는 경우 다음을 고려해야 합니다.

로컬 노드로서 RDS를 이용하는 구성의 경우

  • 리모트 노드로의 송신을 허용하는 설정이 필요합니다.
    • DB 보안 그룹에서 규칙을 추가할 수 있습니다.
    • 자세한 사항은 DB 보안 그룹 항목을 참고합니다.
  • 로컬 노드 역할의 RDS에 Read Replica를 추가한 구성으로 사용할 경우 파라미터의 replicate-ignore-table에 federated 설정된 테이블을 명시해야 합니다.
    • Read Replica를 구성할 경우 federated 테이블 또한 복제되어 Primary와 Read Replica가 리모트 노드를 함께 바라봅니다.
    • 이 경우 Primary에 수행한 데이터 입력이 federated 설정에 따라 리모트 노드에도 수행되고, Read Replica에서도 마찬가지로 동일한 입력이 수행되어 중복 키 오류 등으로 인한 복제 중단이 발생할 수 있습니다.
    • Read Replica가 federated 테이블은 복제하지 않도록 replicate-ignore-table에 설정이 필요합니다.

리모트 노드로서 RDS를 이용하는 구성의 경우

  • 로컬 노드에서의 수신을 허용하는 설정이 필요합니다.
    • DB 보안 그룹에서 규칙을 추가할 수 있습니다.
    • 자세한 사항은 DB 보안 그룹 항목을 참고합니다.

부록3. 보안 패치

NHN Cloud는 DB 인스턴스 운영체제에서 발견된 보안 취약점(CVE)을 주기적으로 관리하여, 영향받는 DB 인스턴스에 보안 패치 유지 관리 작업을 제공합니다. 보안 패치는 현재 DB 인스턴스의 취약점을 해결한 최신 보안 업데이트를 적용하는 방식으로 동작합니다. 아래 가이드에 따라 콘솔에 있는 보안 패치 기능을 사용하세요. 보안 패치 대상으로 지정된 DB 인스턴스가 있는 프로젝트로 이동합니다.

1. 보안 패치 대상 DB 인스턴스를 확인합니다.

유지 관리에서 필수 또는 사용 가능을 클릭하거나 DB 인스턴스 상세의 유지 관리 탭에서 보안 패치 유지 관리 작업이 있는지 확인할 수 있습니다.

patch-security-list-ko

❶ 보안 패치 유지 관리 보기 버튼 클릭 ❷ 현재 DB 이미지에 해당하는 보안 취약점 정보를 확인할 수 있습니다.

patch-security-detail-ko

보안 패치를 적용하면 해결할 수 있는 보안 취약점 정보를 확인할 수 있습니다.

patch-security-popup-ko

알아두기

취약점 심각도는 CRITICAL, HIGH, MEDIUM, LOW로 구분됩니다.

2. 보안 패치 대상 DB 인스턴스에 접속 중인 응용 프로그램을 확인합니다.

보안 패치 시 DB 인스턴스의 서비스 순단이 발생할 수 있습니다. 고가용성 DB 인스턴스는 장애 조치로 서비스 순단을 최소화할 수 있으며, 단일 DB 인스턴스는 재시작으로 보안 패치가 적용됩니다. DB에 연결된 서비스에 영향을 주지 않도록 적절한 조치를 취하세요.

3. 보안 패치 적용 시점을 선택합니다.

patch-security-maintenance-ko

❶ 즉시 적용을 클릭해 보안 패치를 바로 적용할 수 있습니다. ❷ 다음 유지 관리 기간에 적용을 클릭해 지정된 유지 관리 기간에 보안 패치를 적용할 수 있습니다.

고가용성 DB 인스턴스에 적용 시에는 아래 옵션을 함께 선택할 수 있습니다.

  • 사전 백업 실행: 보안 패치 수행 전 백업을 자동으로 실행합니다.
  • 장애 조치 방식 선택: 온라인 장애 조치, 수동 장애 조치 사용 여부를 선택합니다.
  • 복제 지연 대기: 복제 지연이 해소될 때까지 대기한 후 보안 패치를 수행합니다.
  • Read Only 모드: 보안 패치 수행 중 Read Only 모드를 사용합니다.

4. 보안 패치가 완료될 때까지 대기합니다.

DB 인스턴스 상태가 변경되지 않는다면 새로 고침하세요.

patch-security-running-ko

DB 인스턴스에 보안 패치가 적용되는 동안에는 아무런 조작을 할 수 없습니다. 보안 패치가 정상적으로 완료되지 않으면 자동으로 재시도되며, 반복적으로 실패할 경우 관리자에게 보고되어 NHN Cloud에서 별도로 연락드립니다.

목차
TOP