메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

Amazon Aurora MySQL 모범 사례

이 주제에서는 Amazon Aurora MySQL DB 클러스터 사용 또는 이 클러스터로의 데이터 마이그레이션과 관련된 모범 사례와 옵션에 대해 설명합니다.

연결되어 있는 DB 인스턴스 확인

다음 예에서처럼 innodb_read_only 전역 변수를 확인하여 Aurora MySQL DB 클러스터 내에서 연결된 DB 인스턴스를 확인할 수 있습니다.

Copy
SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';

Aurora 복제본에 연결된 경우 innodb_read_only 변수가 ON으로 설정되며 기본 인스턴스에 연결된 경우 OFF로 설정됩니다.

이러한 기능은 애플리케이션 코드에 논리를 추가하여 작업의 균형을 조정하거나 쓰기 작업에 올바른 연결이 사용되고 있는지 확인하려는 경우에 유용할 수 있습니다.

T2 인스턴스 사용

db.t2.small 또는 db.t2.medium DB 인스턴스 클래스를 사용하는 Amazon Aurora MySQL 인스턴스는 늘어난 시간 동안에는 높은 워크로드를 지원하지 않는 애플리케이션에 가장 적합합니다. T2 인스턴스는 중간 정도의 기본 성능을 발휘하면서 워크로드의 필요에 따라 성능을 크게 높이는 버스트 기능을 제공하도록 설계되었습니다. 이러한 인스턴스는 CPU의 최대 성능을 자주 또는 일관적으로 사용하지 않지만 가끔 순간적인 버스트가 필요한 워크로드에 적합합니다. db.t2.smalldb.t2.medium DB 인스턴스 클래스는 개발 및 테스트 서버 또는 기타 비 프로덕션 서버에 가장 적합합니다. T2 인스턴스에 대한 세부 정보는 T2 인스턴스를 참조하십시오.

Aurora MySQL DB 클러스터의 기본 인스턴스 또는 Aurora Replicas에 T2 인스턴스를 사용하는 경우에는 다음 사항을 권장합니다.

  • DB 클러스터에서 T2 인스턴스를 DB 인스턴스 클래스로 사용하는 경우에는 DB 클러스터의 모든 인스턴스에서 동일한 DB 인스턴스 클래스를 사용하는 것이 좋습니다. 예를 들어 db.t2.medium을 기본 인스턴스로 사용한다면 Aurora Replicas에도 db.t2.medium을 사용하는 것이 좋습니다.

  • CPU 크레딧 잔고(CPUCreditBalance)를 모니터링하여 지속 가능한 수준에 있는지 확인합니다. 즉 CPU 크레딧이 사용되고 있는 속도와 동일한 속도로 축적되고 있는지 확인합니다.

    한 인스턴스에 CPU 크레딧을 소진하면 사용 가능한 CPU의 즉각적인 하락과 그 인스턴스에 대한 읽기 및 쓰기 지연 시간의 증가가 표시됩니다. 이로 인해 그 인스턴스의 전반적인 성능이 크게 떨어집니다.

    CPU 크레딧 잔고가 지속 가능한 수준에 있지 않다면 DB 인스턴스를 수정하여 지원되는 R3 DB 인스턴스 클래스 중 하나를 사용하도록 하는 것이 좋습니다(컴퓨팅 확장).

    측정치 모니터링에 대한 자세한 내용은 Amazon Aurora DB 클러스터 모니터링 단원을 참조하십시오.

  • Aurora MySQL DB 클러스터의 기본 인스턴스와 Aurora Replicas 사이의 복제 지연(AuroraReplicaLag)을 모니터링합니다.

    Aurora Replica가 기본 인스턴스 이전에 CPU 크레딧이 바닥나면 기본 인스턴스 지연 시간으로 인해 Aurora Replica가 다시 시작하는 일이 빈번해집니다. 이런 일은 애플리케이션이 Aurora MySQL DB 클러스터의 Aurora Replicas 간에 분산된 고부하 읽기 작업을 유지하고, 이와 동시에 기본 인스턴스가 최소 부하의 쓰기 작업을 유지하는 시나리오에서 흔하게 발생합니다.

    복제 지연이 지속적으로 증가하는 경우에는 DB 클러스터의 Aurora Replicas에 대한 CPU 크레딧 잔고가 소진되지 않도록 해야 합니다.

    CPU 크레딧 잔고가 지속 가능한 수준에 있지 않다면 DB 인스턴스를 수정하여 지원되는 R3 DB 인스턴스 클래스 중 하나를 사용하도록 하는 것이 좋습니다(컴퓨팅 확장).

  • 바이너리 로깅이 활성화된 DB 클러스터에 대해서는 트랜잭션당 삽입의 수를 100만 개 이하로 유지해야 합니다.

    DB 클러스터에 대한 DB 클러스터 파라미터 그룹에서 binlog_format 파라미터가 OFF가 아닌 값으로 설정된 경우, DB 클러스터는 삽입할 행이 100만 개 이상 포함된 대규모 트랜잭션을 수신하면 메모리 부족 문제를 겪을 수 있습니다. 여유 메모리(FreeableMemory) 측정치를 모니터링하여 DB 클러스터에 사용 가능 메모리가 부족한지 확인한 다음, 쓰기 작업(VolumeWriteIOPS) 측정치를 점검하여 기본 인스턴스가 고부하의 쓰기 작업을 수신 중인지 확인할 수 있습니다. 그렇다면 애플리케이션을 업데이트하여 트랜잭션 내 삽입의 양을 100만 개 미만으로 제한하거나 인스턴스를 수정하여 지원되는 R3 DB 인스턴스 클래스 중 하나를 사용하도록 하는 것이 좋습니다(컴퓨팅 확장).

AWS Lambda 함수 호출

트리거나 클라이언트 코드와 같은 여러 소스에서 호출할 수 있는 저장 프로시저의 mysql.lambda_async 프로시저에 대한 호출을 래핑하는 것이 좋습니다. 이를 통해 임피던스 불일치 문제를 방지하고 데이터베이스 프로그래머가 Lambda 함수를 보다 쉽게 호출할 수 있습니다.

Amazon Aurora에서 Lambda 함수를 호출하는 방법에 대한 자세한 내용은 Amazon Aurora MySQL DB 클러스터에서 Lambda 함수 호출 단원을 참조하십시오.

다음 예에는 Lambda 함수, Lambda 함수를 호출하는 저장 프로시저, 저장 프로시저를 실행하고 Lambda 함수를 호출하기 위한 호출이 나와 있습니다.

Lambda 함수

Copy
import boto3 ses = boto3.client('ses') def SES_send_email(event, context): return ses.send_email( Source=event['email_from'], Destination={ 'ToAddresses': [ event['email_to'], ] }, Message={ 'Subject': { 'Data': event['email_subject'] }, 'Body': { 'Text': { 'Data': event['email_body'] } } } )

저장 프로시저

Copy
DROP PROCEDURE IF EXISTS SES_send_email; DELIMITER ;; CREATE PROCEDURE SES_send_email(IN email_from VARCHAR(255), IN email_to VARCHAR(255), IN subject VARCHAR(255), IN body TEXT) LANGUAGE SQL BEGIN CALL mysql.lambda_async( 'arn:aws:lambda:us-west-2:123456789012:function:SES_send_email', CONCAT('{"email_to" : "', email_to, '", "email_from" : "', email_from, '", "email_subject" : "', subject, '", "email_body" : "', body, '"}') ); END ;; DELIMITER ;

저장 프로시저를 호출하여 Lambda 함수 호출

Copy
mysql> call SES_send_email('example_to@amazon.com', 'example_from@amazon.com', 'Email subject', 'Email content');

Amazon Aurora의 비동기식 키 미리 가져오기 작업

Amazon Aurora는 비동기식 키 미리 가져오기(AKP) 기능을 사용하여 여러 인덱스 사이에 테이블을 조인하는 쿼리 성능을 높일 수 있습니다. 이 기능은 JOIN 쿼리에서 Batched Key Access(BKA) 조인 알고리즘과 Multi-Range Read(MRR) 최적화 기능을 사용해야 하는 쿼리를 실행하면서 필요한 행을 예측하여 성능을 높이는 효과가 있습니다. BKA 및 MRR에 대한 자세한 내용은 MySQL 설명서에서 Block Nested-Loop and Batched Key Access JoinsMulti-Range Read Optimization을 참조하십시오.

쿼리가 AKP 기능을 이용하기 위해서는 BKA와 MRR이 모두 필요합니다. 일반적으로 JOIN 절이 보조 인덱스를 사용하지만 기본 인덱스의 열도 일부 필요할 때 이러한 쿼리가 발생합니다. 예를 들어 JOIN 절이 작은 용량의 외부 테이블과 큰 용량의 내부 테이블 사이에서 인덱스 값을 기준으로 한 등가 조인을 나타내고, 테이블 용량이 커질수록 인덱스 선택의 폭이 매우 제한적일 때 AKP를 사용할 수 있습니다. AKP는 JOIN 절을 평가하는 동안 BKA 및 MRR과 함께 보조-기본 인덱스 조회를 실행합니다. 동시에 쿼리를 실행하는 데 필요한 행까지 식별합니다. 그런 다음 쿼리를 실행하기에 앞서 백그라운드 스레드를 사용하여 식별된 행이 포함된 페이지를 메모리에 비동기식으로 로드합니다.

비동기식 키 미리 가져오기(AKP) 활성화

AKP 기능은 MySQL 서버 변수인 aurora_use_key_prefetch를 ON으로 설정하여 활성화할 수 있습니다. 기본적으로 이 값은 ON으로 설정됩니다. 하지만 먼저 BKA 조인 알고리즘을 활성화하고 비용 기반 MRR 기능을 비활성화해야만 AKP를 활성화할 수 있습니다. 이를 위해서는 optimizer_switch MySQL 서버 변수의 값을 다음과 같이 설정해야 합니다.

  • batched_key_access를 ON으로 설정합니다.

    이 값은 BKA 조인 알고리즘의 사용을 제어합니다. 기본적으로 이 값은 OFF로 설정됩니다.

  • mrr_cost_based를 OFF로 설정합니다.

    이 값은 비용 기반 MRR 기능의 사용을 제어합니다. 기본적으로 이 값은 ON으로 설정됩니다.

현재는 세션 수준에서만 위의 두 값을 설정할 수 있습니다. 다음은 SET 문에서 위의 두 값을 설정하여 현재 세션에 AKP를 활성화하는 방법을 설명한 예제입니다.

Copy
mysql> set @@session.aurora_use_key_prefetch=on; mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

마찬가지로 다음 예제와 같이 SET 문을 사용하여 AKP와 BKA 조인 알고리즘을 비활성화한 후 현재 세션에 비용 기반 MRR 기능을 다시 활성화할 수 있습니다.

Copy
mysql> set @@session.aurora_use_key_prefetch=off; mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

batched_key_accessmrr_cost_based 옵티마이저 스위치에 대한 자세한 내용은 MySQL 설명서에서 Switchable Optimizations를 참조하십시오.

비동기식 키 미리 가져오기를 위한 쿼리 최적화

쿼리의 AKP 기능 사용 여부를 확인할 수 있습니다. 방법은 쿼리를 실행하기 전에 EXPLAIN 문에서 EXTENDED 키워드를 사용하여 쿼리를 프로파일링하는 것입니다. 그러면 EXPLAIN 문이 지정한 쿼리에 사용할 실행 계획에 대한 정보를 제공합니다.

EXPLAIN 문 출력에서 Extra 열은 실행 계획에 추가되는 정보에 대한 설명입니다. AKP 기능이 쿼리에 사용할 테이블에 적용되는 경우 이 열에 다음 값 중 하나가 포함됩니다.

  • Using Key Prefetching

  • Using join buffer (Batched Key Access with Key Prefetching)

다음은 EXPLAIN 문에 EXTENDED 키워드를 사용하여 AKP를 이용할 수 있는 쿼리의 실행 계획을 확인하는 예제입니다.

mysql> explain extended select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

확장된 EXPLAIN 출력 형식에 대한 자세한 내용은 MySQL 제품 설명서에서 Extended EXPLAIN Output Format을 참조하십시오.

Amazon Aurora MySQL에서 다중 스레드 복제 슬레이브 사용

Aurora MySQL DB 클러스터를 복제 슬레이브로 사용하는 경우 Aurora는 기본적으로 단일 스레드 복제를 사용합니다. Amazon Aurora가 다중 스레드 복제를 금지하지는 않지만 Aurora MySQL는 다중 스레드 복제와 관련된 여러 문제점을 MySQL로부터 물려받았습니다. 프로덕션 환경에서는 다중 스레드 복제를 사용하지 않는 것이 좋습니다. 다중 스레드 복제를 사용할 경우 모든 사용을 철저히 테스트할 것을 권장합니다.

Amazon Aurora에서 복제 사용에 대한 자세한 내용은 Amazon Aurora를 사용한 복제 섹션을 참조하십시오.

Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정

MySQL DB 인스턴스에서 Amazon Aurora를 사용하여 Amazon Aurora의 읽기 조정 기능을 활용하고 MySQL DB 인스턴스에 대한 읽기 워크로드를 확장할 수 있습니다. Aurora를 사용하여 MySQL DB 인스턴스에 대한 읽기 조정을 수행하려면 Amazon Aurora MySQL DB 클러스터를 생성한 후 이 클러스터를 MySQL DB 인스턴스의 복제 슬레이브로 설정합니다. 이러한 설정은 Amazon RDS MySQL DB 인스턴스 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스에 적용됩니다.

Amazon Aurora DB 클러스터 생성에 대한 자세한 내용은 Amazon Aurora DB 클러스터 생성 단원을 참조하십시오.

MySQL DB 인스턴스와 Amazon Aurora DB 클러스터 간의 복제를 설정할 때는 다음 지침을 따라야 합니다.

  • Amazon Aurora MySQL DB 클러스터를 참조할 때 Amazon Aurora DB 클러스터 엔드포인트 주소를 사용합니다. 장애 조치가 발생하는 경우 Aurora MySQL DB 클러스터용 기본 인스턴스로 승격되는 Aurora 복제본에서 DB 클러스터 엔드포인트 주소가 계속 사용됩니다.

  • binlog가 Aurora 복제본에 적용되었음을 확인할 때까지는 마스터 인스턴스에서 binlog를 유지 관리합니다. 이렇게 유지 관리해야 오류 발생 시 마스터 인스턴스를 복원할 수 있습니다.

중요

자체 관리형 복제를 사용하는 경우, 발생할 수 있는 복제 문제를 직접 모니터링하고 해결해야 합니다. 자세한 내용은 Read Replica 사이의 지연 문제 진단 및 해결 단원을 참조하십시오.

참고

Amazon Aurora MySQL DB 클러스터에서 복제를 시작하는 데 필요한 권한이 제한되고 Amazon RDS 마스터 사용자를 사용할 수 없습니다. 이 때문에 Amazon RDS mysql.rds_set_external_mastermysql.rds_start_replication 명령을 사용하여 Amazon Aurora MySQL DB 클러스터와 MySQL DB 인스턴스 간의 복제를 설정해야 합니다.

외부 마스터 인스턴스와 Amazon RDS 상의 MySQL DB 인스턴스 사이에서 복제 시작

  1. 원본 MySQL DB 인스턴스를 읽기 전용으로 설정합니다.

    Copy
    mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON;
  2. 원본 MySQL DB 인스턴스에서 SHOW MASTER STATUS 명령을 실행하여 binlog 위치를 확인합니다. 다음 예와 비슷한 출력 결과를 얻을 것입니다.

    Copy
    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
  3. mysqldump를 사용하여 외부 MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터베이스를 복사합니다. 매우 큰 데이터베이스의 경우, 가동 중지 시간을 단축하여 Amazon RDS MySQL MariaDB DB 인스턴스로 데이터 가져오기에서 이 절차를 사용하고 싶을 것입니다.

    Linux, OS X, Unix의 경우:

    Copy
    mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ –u <local_user> \ -p <local_password> | mysql \ --host aurora_cluster_endpoint_address \ –-port 3306 \ –u <RDS_user_name> \ –p <RDS_password>

    Windows의 경우:

    Copy
    mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ –u <local_user> ^ -p <local_password> | mysql ^ --host aurora_cluster_endpoint_address ^ –-port 3306 ^ –u <RDS_user_name> ^ –p <RDS_password>

    참고

    -p 옵션과 입력한 암호 사이에 공백이 없어야 합니다.

    mysql 명령의 ‐‐host, ‐‐user (-u), ‐‐port–p 옵션을 사용하여 Aurora DB 클러스터에 연결하는 데 사용할 호스트 이름, 사용자 이름, 포트 및 암호를 지정합니다. 호스트 이름은 Amazon Aurora DB 클러스터 엔드포인트의 DNS 이름으로, 예를 들면 mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com입니다. Amazon RDS Management Console의 클러스터 세부 정보에서 엔드포인트 값을 찾을 수 있습니다.

  4. 다시 원본 MySQL DB 인스턴스를 쓰기 가능한 상태로 설정합니다.

    Copy
    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    복제와 함께 사용할 백업을 만드는 자세한 정보는 MySQL 문서의 Backing Up a Master or Slave by Making It Read Only를 참조하십시오.

  5. Amazon RDS Management Console에서 원본 MySQL 데이터베이스를 호스팅하는 서버의 IP 주소를 Amazon Aurora DB 클러스터용 VPC 보안 그룹에 추가합니다. VPC 보안 그룹 수정에 관한 자세한 내용은 Amazon Virtual Private Cloud User Guide에서 Security Groups for Your VPC를 참조하십시오.

    Amazon Aurora DB 클러스터의 IP 주소에서의 연결을 허용하도록 로컬 네트워크를 구성하여 원본 MySQL 인스턴스와 통신할 수 있도록 해야 할 수도 있습니다. Amazon Aurora DB 클러스터의 IP 주소를 찾으려면 host 명령을 사용합니다.

    Copy
    host <aurora_endpoint_address>

    호스트 이름은 Amazon Aurora DB 클러스터 엔드포인트의 DNS 이름입니다.

  6. 선택한 클라이언트를 사용하여 외부 MySQL 인스턴스에 연결하고 복제에 사용될 MySQL 사용자를 만듭니다. 이 계정은 오직 복제용으로만 사용되며 보안 향상을 위해 사용자의 도메인으로 제한되어야 합니다. 다음은 그 한 예입니다.

    Copy
    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  7. 외부 MySQL 인스턴스의 경우 복제 사용자에게 REPLICATION CLIENTREPLICATION SLAVE 권한을 부여합니다. 예를 들어 도메인의 'repl_user' 사용자를 위해 모든 데이터베이스에서 REPLICATION CLIENTREPLICATION SLAVE 권한을 부여하려면 다음 명령을 실행합니다.

    Copy
    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  8. 복제를 설정하기 전에 복제 슬레이브가 될 Aurora MySQL DB 클러스터의 스냅샷을 수동으로 생성합니다. 복제 슬레이브인 DB 클러스터와 복제를 다시 설정해야 할 경우, MySQL DB 인스턴스를 새로운 Aurora MySQL DB 클러스터로 가져오는 대신 이 스냅샷에서 Aurora MySQL DB 클러스터를 복원할 수 있습니다.

  9. Amazon Aurora DB 클러스터를 복제본으로 만듭니다. 마스터 사용자로 Amazon Aurora DB 클러스터에 연결하고 mysql.rds_set_external_master 명령을 사용하여 원본 MySQL 데이터베이스를 복제 마스터로 식별합니다. 2단계에서 결정한 마스터 로그 파일 이름과 마스터 로그 위치를 사용합니다. 다음은 그 한 예입니다.

    Copy
    CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
  10. Amazon Aurora DB 클러스터에서 mysql.rds_start_replication 명령을 실행하여 복제를 시작합니다.

    Copy
    CALL mysql.rds_start_replication;

원본 MySQL DB 인스턴스와 Amazon Aurora DB 클러스터 간의 복제를 설정한 후에는 Aurora 복제본을 Amazon Aurora DB 클러스터에 추가할 수 있습니다. 그러고 나면 Aurora 복제본에 연결하여 데이터에 대한 읽기 조정을 수행할 수 있습니다. Aurora 복제본 생성에 대한 자세한 내용은 콘솔을 사용한 Aurora 복제본 생성 단원을 참조하십시오.

MySQL 데이터베이스에서 Amazon Aurora를 재해 복구용으로 사용

MySQL DB 인스턴스에서 Amazon Aurora를 사용하여 재해 복구용 오프사이트 백업을 생성할 수 있습니다. MySQL DB 인스턴스의 재해 복구용으로 Aurora를 사용하려면 Amazon Aurora DB 클러스터를 생성한 후 이 클러스터를 MySQL DB 인스턴스의 복제 슬레이브로 설정합니다. 이러한 설정은 Amazon RDS MySQL DB 인스턴스 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스에 적용됩니다.

중요

MySQL DB 인스턴스와 Amazon Aurora MySQL DB 클러스터 간의 복제를 설정할 경우 Amazon RDS를 통해 복제가 관리되지 않습니다. 복제를 모니터링하여 상태가 정상으로 유지되는지 확인하고 필요할 경우 복구해야 합니다.

Amazon Aurora MySQL DB 클러스터를 생성하고 이 클러스터를 MySQL DB 인스턴스의 복제 슬레이브로 설정하는 방법에 대한 자세한 내용은 Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정의 절차를 따르십시오.

감소된 중단 시간으로 MySQL에서 Amazon Aurora MySQL로 마이그레이션

라이브 애플리케이션을 지원하는 MySQL 데이터베이스에서 Amazon Aurora MySQL DB 클러스터로 데이터를 가져오는 경우 가동 중지 시간을 단축하여 Amazon RDS MySQL MariaDB DB 인스턴스로 데이터 가져오기에 설명된 절차를 사용하여 데이터를 Aurora MySQL로 마이그레이션하기 위해 데이터 서비스를 중단하는 시간을 줄일 수 있습니다. 네트워크를 통해 AWS로 전달되는 데이터의 양을 최소화하여 가져오기 비용을 줄일 수 있기 때문에, 매우 큰 데이터베이스로 작업하는 경우 이 절차가 특히 도움이 될 수 있습니다.

이 절차에는 데이터베이스 데이터의 복사본을 Amazon EC2 인스턴스로 전송하고 데이터를 새 Amazon RDS MySQL DB 인스턴스로 가져오는 작업을 수행하는 단계가 나열되어 있습니다. Amazon Aurora가 MySQL과 호환되므로 Amazon Aurora DB 클러스터를 대상 Amazon RDS MySQL DB 인스턴스로 대신 사용할 수 있습니다.

관련 주제