연결되어 있는 DB 인스턴스 확인 Aurora MySQL 성능 및 크기 조정에 대한 모범 사례 Aurora MySQL 고가용성을 위한 모범 사례 Aurora MySQL 대한 권장 사항

Amazon Aurora MySQL 모범 사례

이 주제에서는 Amazon Aurora MySQL DB 클러스터 사용 또는 이 클러스터로의 데이터 마이그레이션과 관련된 모범 사례와 옵션에 대해 설명합니다. 이 항목의 정보는 Amazon Aurora DB 클러스터 관리에서 찾을 수 있는 몇 가지 지침과 절차를 요약하고 반복합니다.

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

Aurora MySQL DB 클러스터에 어떤 DB 인스턴스가 연결되었는지 판별하려면 다음 예제와 같이 innodb_read_only 전역 변수를 점검하십시오.


SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';

리더 DB 인스턴스에 연결된 경우 innodb_read_only 변수는 ON(으)로 설정됩니다. 라이터 DB 인스턴스(예: 프로비저닝된 클러스터의 기본 인스턴스)에 연결되어 있는 경우 이 설정은 OFF입니다.

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

Aurora MySQL 성능 및 크기 조정에 대한 모범 사례

Aurora MySQL 클러스터의 성능과 확장성을 개선하기 위해 적용할 수 있는 모범 사례는 다음과 같습니다.

주제

개발 및 테스트에 T 인스턴스 클래스 사용
비동기식 키 프리페치를 사용하여 Aurora MySQL 인덱싱된 조인 쿼리 최적화
해시 조인을 사용하여 대규모 Aurora MySQL 조인 쿼리 최적화
Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정
타임스탬프 작업 최적화

개발 및 테스트에 T 인스턴스 클래스 사용

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

Aurora 클러스터가 40TB보다 큰 경우 T 인스턴스 클래스를 사용하지 마세요. 데이터베이스에 많은 양의 데이터가 있는 경우 스키마 개체를 관리하기 위한 메모리 오버헤드가 T 인스턴스의 용량을 초과할 수 있습니다.

MySQL 성능 스키마를 Amazon Aurora MySQL T 인스턴스에서 활성화하지 마세요. 성능 스키마가 활성화된 경우 인스턴스의 메모리가 부족할 수 있습니다.

작은 정보

데이터베이스가 때로는 유휴 상태이지만 상당한 워크로드가 있을 때도 있는 경우 T 인스턴스의 대안으로 Aurora Serverless v2를 사용할 수 있습니다. Aurora Serverless v2를 사용하는 경우, 용량 범위를 정의하면 Aurora가 현재 워크로드에 따라 데이터베이스를 자동으로 확장 또는 축소합니다. 자세한 내용은 Aurora Serverless v2 사용하기 단원을 참조하세요. Aurora Serverless v2에서 사용할 수 있는 데이터베이스 엔진 버전은 Aurora Serverless v2 요구 사항 및 제한 사항 섹션을 참조하세요.

T 인스턴스를 Aurora MySQL DB 클러스터의 DB 인스턴스로 사용할 때는 다음을 권장합니다.

DB 클러스터 내의 모든 인스턴스에 동일한 DB 인스턴스 클래스를 사용합니다. 예를 들어 라이터 인스턴스에 db.t2.medium을(를) 사용하는 경우 리더 인스턴스에 대해서도 db.t2.medium을(를) 사용하는 것이 좋습니다.
메모리 관련 구성 설정을 조정하지 마세요(예: innodb_buffer_pool_size). Aurora 는 T 인스턴스의 메모리 버퍼에 대해 고도로 조정된 기본값 집합을 사용합니다. 이러한 특수 기본값은 메모리가 제한된 인스턴스에서 Aurora 를 실행하는 데 필요합니다. T 인스턴스에서 메모리 관련 설정을 변경하면 버퍼 크기를 늘리려는 경우에도 메모리 부족 조건이 발생할 가능성이 훨씬 큽니다.
CPU 크레딧 잔고(CPUCreditBalance)를 모니터링하여 지속 가능한 수준에 있는지 확인합니다. 즉 CPU 크레딧이 사용되고 있는 속도와 동일한 속도로 축적되고 있는지 확인합니다.

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

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

지표 모니터링에 대한 자세한 정보는 Amazon RDS 콘솔에서 지표 보기 단원을 참조하십시오.
라이터 인스턴스와 리더 인스턴스 간의 복제본 지연(AuroraReplicaLag)을 모니터링합니다.

라이터 인스턴스보다 먼저 리더 인스턴스에 CPU 크레딧이 부족하면 결과 지연으로 인해 리더 인스턴스가 자주 다시 시작될 수 있습니다. 애플리케이션에 리더 인스턴스의 많은 양의 읽기 작업이 분산되어 있는 동시에 라이터 인스턴스의 쓰기 작업의 양이 최소한일 때 일반적으로 나타나는 결과입니다.

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

CPU 크레딧 잔고가 지속 가능한 수준에 있지 않다면 DB 인스턴스를 수정하여 지원되는 R DB 인스턴스 클래스 중 하나를 사용하도록 하는 것이 좋습니다(컴퓨팅 확장).
바이너리 로깅이 활성화된 DB 클러스터에 대해서는 트랜잭션당 삽입의 수를 100만 개 이하로 유지해야 합니다.

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

비동기식 키 프리페치를 사용하여 Aurora MySQL 인덱싱된 조인 쿼리 최적화

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

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

AKP는 Aurora MySQL 버전 2.10 이상 및 버전 3에서 사용할 수 있습니다. Aurora MySQL 버전에 대한 자세한 내용은 Amazon Aurora MySQL에 대한 데이터베이스 엔진 업데이트 단원을 참조하십시오.

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

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

batched_key_access를 on으로 설정합니다. 이 값은 BKA 조인 알고리즘의 사용을 제어합니다. 기본적으로 이 값은 off로 설정됩니다.
mrr_cost_based를 off으로 설정합니다. 이 값은 비용 기반 MRR 기능의 사용을 제어합니다. 기본적으로 이 값은 on로 설정됩니다.

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



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 기능을 다시 활성화할 수 있습니다.



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

batched_key_access 및 mrr_cost_based 옵티마이저 스위치에 대한 자세한 정보는 MySQL 설명서에서 Switchable Optimizations를 참조하십시오.

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

쿼리의 AKP 기능 사용 여부를 확인할 수 있습니다. 이렇게 하려면 쿼리를 실행하기 전에 EXPLAIN 문을 사용하여 쿼리를 프로파일링하면 됩니다. EXPLAIN 문이 지정한 쿼리에 사용할 실행 계획에 대한 정보를 제공합니다.

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

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

EXPLAIN을 사용하여 AKP를 이용할 수 있는 쿼리의 실행 계획을 확인하는 예는 다음과 같습니다.



mysql> explain 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 설명서의 확장된 EXPLAIN 출력 형식을 참조하세요.

해시 조인을 사용하여 대규모 Aurora MySQL 조인 쿼리 최적화

동등 조인을 사용하여 많은 양의 데이터를 조인해야 하는 경우 해시 조인을 통해 쿼리 성능을 향상시킬 수 있습니다. Aurora MySQL의 해시 조인을 활성화할 수 있습니다.

해시 조인 열은 복잡한 표현식이 될 수 있습니다. 해시 조인 열에서 다음과 같은 방식으로 데이터 유형을 비교할 수 있습니다.

int, bigint, numeric 및 bit 등과 같은 정확한 숫자 데이터 형식 범주의 모든 항목을 비교할 수 있습니다.
float 및 double과 같은 대략적인 숫자 데이터 형식 범주의 모든 항목을 비교할 수 있습니다.
문자열 유형에 동일한 문자 세트와 콜레이션이 있는 경우 문자열 유형간에 항목을 비교할 수 있습니다.
유형이 동일한 경우 날짜 및 타임스탬프 데이터 형식으로 항목을 비교할 수 있습니다.

참고

다른 범주의 데이터 유형은 비교할 수 없습니다.

Aurora MySQL의 해시 조인에는 다음의 제한 사항이 적용됩니다.

왼쪽 오른쪽 외부 조인은 Aurora MySQL 버전 2에서는 지원되지 않지만, 버전 3에서는 지원됩니다.
하위 쿼리가 구체화되지 않는 한 하위 쿼리와 같은 Semijoin은 지원되지 않습니다.
다중 테이블의 업데이트 또는 삭제는 지원되지 않습니다.

참고
단일 테이블의 업데이트 또는 삭제는 지원되지 않습니다.
BLOB 및 공간 데이터 유형 열은 해시 조인의 조인 열일 수 없습니다.

해시 조인 활성화

해시 조인 활성화 방법:

Aurora MySQL 버전 2 - DB 파라미터 또는 DB 클러스터 파라미터 aurora_disable_hash_join을 0으로 설정합니다. aurora_disable_hash_join을 비활성화하면 optimizer_switch의 값이 hash_join=on이 됩니다.
Aurora MySQL 버전 3 - MySQL 서버 파라미터 optimizer_switch를 block_nested_loop=on으로 설정합니다.

해시 조인은 Aurora MySQL 버전 3에서 기본적으로 활성화되어 있으며 Aurora MySQL 버전 2에서 기본적으로 비활성화되어 있습니다. 다음은 Aurora MySQL 버전 3에서 해시 조인을 활성화하는 방법을 설명한 예입니다. 먼저 select @@optimizer_switch 문을 발행하여 다른 설정이 SET 파라미터 문자열에 있는지 확인합니다. optimizer_switch 파라미터에서 설정 하나를 업데이트하면 다른 설정을 지우거나 수정하지 못합니다.


mysql> SET optimizer_switch='block_nested_loop=on';

참고

Aurora MySQL 버전 3의 경우 해시 조인 지원은 모든 부 버전에서 사용할 수 있으며 기본적으로 켜져 있습니다.

Aurora MySQL 버전 2의 경우 모든 마이너 버전에 해시 조인이 지원됩니다. Aurora MySQL 2 버전에서 해시 조인 기능은 항상 aurora_disable_hash_join 값에 의해 제어됩니다.

이 설정을 사용하면 옵티마이저는 비용, 쿼리 특성 및 리소스 가용성을 기반으로 해시 조인을 사용하도록 선택합니다. 비용 견적이 정확하지 않으면 옵티마이저가 해시 조인을 선택하게 할 수 있습니다. 그렇게 하려면 MySQL 서버 변수 hash_join_cost_based를 off으로 설정합니다. 다음은 옵티마이저가 해시 조인을 선택하도록 하는 방법을 설명한 예제입니다.



mysql> SET optimizer_switch='hash_join_cost_based=off';

참고

이 설정은 비용 기반 옵티마이저의 결정보다 우선합니다. 이 설정은 테스트 및 개발에 유용할 수 있지만, 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.

해시 조인에 대한 쿼리 최적화

쿼리가 해시 조인을 활용할 수 있는지 확인하려면 EXPLAIN 문을 사용하여 쿼리를 먼저 프로파일링하십시오. EXPLAIN 문이 지정한 쿼리에 사용할 실행 계획에 대한 정보를 제공합니다.

Extra 문 출력에서 EXPLAIN 열은 실행 계획에 추가되는 정보에 대한 설명입니다. 해시 조인이 쿼리에 사용할 테이블에 적용되는 경우 이 열에 다음과 비슷한 값이 포함됩니다.

Using where; Using join buffer (Hash Join Outer table table1_name)
Using where; Using join buffer (Hash Join Inner table table2_name)

다음은 EXPLAIN을 사용하여 해시 조인 쿼리의 실행 계획을 확인하는 예제입니다.



mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

출력에서 Hash Join Inner table은 해시 테이블을 작성하는 데 사용하는 테이블이며 Hash Join Outer table은 해시 테이블을 프로브하는 데 사용하는 테이블입니다.

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

Aurora MySQL 2.08 이상에서는 SQL 힌트를 사용하여 쿼리에서 해시 조인을 사용하는지 여부와 조인의 빌드 및 프로브 측에 사용할 테이블에 영향을 줄 수 있습니다. 세부 정보는 Aurora MySQL 힌트을 참조하세요.

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

MySQL DB 인스턴스에서 Amazon Aurora를 사용하여 Amazon Aurora의 읽기 조정 기능을 활용하고 MySQL DB 인스턴스에 대한 읽기 작업을 확장할 수 있습니다. Aurora을 사용하여 MySQL DB 인스턴스에 대한 읽기 조정을 수행하려면 Aurora MySQL DB 클러스터를 생성한 후 이 클러스터를 MySQL DB 인스턴스의 읽기 전용 복제본으로 설정합니다. 그런 다음 Aurora MySQL 클러스터에 연결하여 읽기 쿼리를 처리합니다. 이러한 설정은 RDS for MySQL DB 인스턴스 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스에 적용됩니다. 자세한 내용은 Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정 단원을 참조하십시오.

타임스탬프 작업 최적화

시스템 변수 time_zone의 값이 SYSTEM으로 설정되면 시간대 계산이 필요한 각 MySQL 함수 호출이 시스템 라이브러리를 호출합니다. 이러한 TIMESTAMP 값을 거의 동시에 반환하거나 변경하는 SQL 문을 실행하면 지연 시간, 잠금 경합 및 CPU 사용량이 증가할 수 있습니다. 자세한 내용은 MySQL 설명서의 time_zone을 참조하세요.

이러한 동작을 방지하려면 time_zone DB 클러스터 파라미터의 값을 UTC로 변경하는 것이 좋습니다. 자세한 내용은 DB 클러스터 파라미터 그룹의 파라미터 수정 단원을 참조하십시오.

time_zone 파라미터는 동적이지만(데이터베이스 서버를 다시 시작할 필요가 없음), 새 값은 최신 연결에만 사용됩니다. 모든 연결이 새 time_zone 값을 사용하도록 업데이트하려면 DB 클러스터 파라미터를 업데이트한 후 애플리케이션 연결을 해제했다가 다시 연결하는 것이 좋습니다.

Aurora MySQL 고가용성을 위한 모범 사례

Aurora MySQL 클러스터의 유효성을 개선하기 위해 적용할 수 있는 모범 사례는 다음과 같습니다.

주제

MySQL 데이터베이스에서 Amazon Aurora를 재해 복구용으로 사용
감소된 중단 시간으로 MySQL에서 Amazon Aurora MySQL로 마이그레이션
Aurora MySQL DB 인스턴스의 성능 저하, 자동 재시작 및 장애 조치 방지

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

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

중요

MySQL DB 인스턴스와 Amazon Aurora MySQL DB 클러스터 간의 복제를 설정할 때 필요할 경우 정상 상태를 유지하고 수리하는지 확인하도록 복제를 모니터링해야 합니다.

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

재해 복구 모델에 대한 자세한 내용은 Amazon Aurora MySQL 클러스터에 가장 적합한 재해 복구 옵션을 선택하는 방법을 참조하세요.

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

라이브 애플리케이션을 지원하는 MySQL 데이터베이스에서 Amazon Aurora MySQL DB 클러스터로 데이터를 가져올 때 마이그레이션하는 동안 서비스가 중단되는 시간을 줄일 수 있습니다. 그렇게 하려면 Amazon Relational Database Service 사용 설명서의 가동 중지 시간을 단축하여 MySQL 또는 MariaDB DB 인스턴스로 데이터 가져오기에 나온 절차를 따르세요. 이 절차는 대규모 데이터베이스로 작업하는 경우에 특히 유용합니다. 이 프로시저를 사용하여 네트워크에서 AWS로 전달되는 데이터의 양을 최소화하여 가져오기 비용을 줄일 수 있습니다.

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

Aurora MySQL DB 인스턴스의 성능 저하, 자동 재시작 및 장애 조치 방지

워크로드가 많거나 워크로드가 DB 인스턴스의 할당된 리소스 이상으로 급증하는 경우 애플리케이션과 Aurora 데이터베이스를 실행하는 데 사용되는 리소스가 소진될 수 있습니다. CPU 사용률, 메모리 사용량, 사용된 데이터베이스 연결 수와 같은 데이터베이스 인스턴스에 대한 지표를 얻으려면 Amazon CloudWatch, 성능 개선 도우미 및 향상된 모니터링에서 제공하는 지표를 참조할 수 있습니다. DB 인스턴스 모니터링에 대한 자세한 내용은 Amazon Aurora 클러스터에서 지표 모니터링 섹션을 참조하세요.

워크로드가 사용 중인 리소스를 소진하면 DB 인스턴스가 느려지거나, 다시 시작되거나, 다른 DB 인스턴스로 장애 조치될 수 있습니다. 이를 방지하려면 리소스 사용률을 모니터링하고, DB 인스턴스에서 실행되는 워크로드를 검사하고, 필요한 경우 최적화하세요. 최적화가 인스턴스 지표를 개선하지 못하고 리소스 소진을 완화할 수 없다면 한도에 도달하기 전에 DB 인스턴스를 스케일 업하는 것을 고려해 보세요. 사용 가능한 DB 인스턴스 클래스 및 사양에 대한 자세한 내용은 Aurora DB 인스턴스 클래스 섹션을 참조하세요.

Aurora MySQL 대한 권장 사항

다음 기능은 MySQL 호환성을 위해 Aurora MySQL에서 사용할 수 있습니다. 그러나 Aurora 환경에서는 성능, 확장성, 안정성 또는 호환성 문제가 있습니다. 따라서 이러한 기능을 사용할 때 정해진 가이드라인을 따르는 것이 좋습니다. 예를 들어 프로덕션 Aurora 배포에는 특정 기능을 사용하지 않는 것이 좋습니다.

Aurora MySQL 버전 3에서 멀티스레드 복제 사용

기본적으로 Aurora은 Aurora MySQL DB 클러스터가 이진 로그 복제의 읽기 전용 복제본으로 사용될 때 단일 스레드 복제를 사용합니다.

Aurora MySQL은 다중 스레드 복제를 금지하지 않지만 이 기능은 Aurora MySQL 버전 3에서만 지원됩니다.

Aurora MySQL 버전 2는 MySQL에서 다중 스레드 복제와 관련된 여러 문제를 물려받았습니다. 해당 버전의 경우 프로덕션 환경에서 다중 스레드 복제를 사용하지 않는 것이 좋습니다.

다중 스레드 복제를 사용할 경우 모든 사용을 철저히 테스트할 것을 권장합니다.

Amazon Aurora에서의 복제에 대한 자세한 정보는 Amazon Aurora를 사용한 복제 단원을 참조하십시오. Aurora MySQL 버전 3의 멀티스레드 복제에 대한 자세한 내용은 다중 스레드 binlog 복제(Aurora MySQL 버전 3) 섹션을 참조하세요.

네이티브 MySQL 함수로 AWS Lambda 함수 호출

네이티브 MySQL 함수 lambda_sync 및 lambda_async를 사용하여 Lambda 함수를 호출하는 것이 좋습니다.

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

Amazon Aurora에서 Lambda 함수 호출에 대한 자세한 정보는 Amazon Aurora MySQL DB 클러스터에서 Lambda 함수 호출 단원을 참조하십시오.

Amazon Aurora MySQL에서 XA 트랜잭션 방지

XA가 PREPARED 상태인 경우 복구 시간이 길어질 수 있으므로 Aurora MySQL에서 XA(eXtended Architecture) 트랜잭션을 사용하지 않는 것이 좋습니다. Aurora MySQL에서 XA 트랜잭션을 사용해야 하는 경우 다음 모범 사례를 따르십시오.

XA 트랜잭션을 PREPARED 상태로 열어두지 마십시오.
XA 트랜잭션을 가능한 작게 유지하십시오.

MySQL에서 XA 트랜잭션 사용에 대한 자세한 정보는 MySQL 설명서의 XA TRANSACTIONS를 참조하십시오.

DML 문 동안 외래 키 켜기 유지

foreign_key_checks 변수가 0(off)으로 설정되어 있을 때는 데이터 정의 언어(DDL) 문을 실행하지 않는 것이 좋습니다.

외래 키의 일시적 위반이 필요한 행을 삽입하거나 업데이트해야 하는 경우, 다음 단계에 따르십시오.

foreign_key_checks를 0으로 설정합니다.
데이터 조작 언어(DML)를 변경합니다.
완료된 변경이 외래 키 제약 조건을 위반하지 않아야 합니다.
foreign_key_checks를 1(on)로 설정합니다.

또한 외래 키 제약 조건에 대한 다음과 같은 다른 모범 사례에 따르십시오.

클라이언트 애플리케이션이 init_connect 변수의 일부로 foreign_key_checks 변수를 0으로 설정하지 않아야 합니다.
mysqldump와 같은 논리적 백업으로부터 복원이 실패하거나 불완전할 경우, 같은 세션에서 다른 작업을 시작하기 전에 foreign_key_checks가 1로 설정되어 있는지 확인합니다. 논리적 백업은 시작할 때 foreign_key_checks를 0으로 설정합니다.

로그 버퍼를 플러시하는 빈도 구성

MySQL Community Edition에서 트랜잭션의 내구성을 높이려면 InnoDB 로그 버퍼를 내구성 있는 스토리지로 플러시해야 합니다. innodb_flush_log_at_trx_commit 파라미터를 사용하여 로그 버퍼가 디스크로 플러시되는 빈도를 구성합니다.

innodb_flush_log_at_trx_commit 파라미터를 기본값인 1로 설정하면 트랜잭션이 커밋될 때마다 로그 버퍼가 플러시됩니다. 이 설정은 데이터베이스 ACID 준수 상태를 유지하는 데 도움이 됩니다. 기본 설정인 1을 그대로 유지하는 것이 좋습니다.

innodb_flush_log_at_trx_commit을 기본값이 아닌 값으로 변경하면 데이터 조작 언어(DML) 지연 시간을 줄이는 데 도움이 되지만 로그 레코드의 내구성은 저하될 수 있습니다. 이러한 내구성 결여로 인해 데이터베이스 ACID 규정을 준수하지 못하게 됩니다. 서버 재시작 시 데이터 손실 위험을 예방하기 위해 데이터베이스를 ACID 규정을 준수하는 것이 좋습니다. 이 파라미터에 대한 자세한 내용은 MySQL 설명서에서 innodb_flush_log_at_trx_commit을 참조하세요.

Aurora MySQL에서는 다시 실행 로그 처리가 스토리지 계층으로 오프로드되므로 DB 인스턴스에서 로그 파일을 플러시하지 않습니다. 쓰기가 실행되면 라이터 DB 인스턴스에서 Aurora 클러스터 볼륨으로 직접 다시 실행 로그가 전송됩니다. 네트워크를 통과하는 유일한 쓰기는 다시 실행 로그 레코드입니다. 데이터베이스 계층에서 작성되는 페이지는 없습니다.

기본적으로 트랜잭션을 커밋하는 각 스레드는 Aurora 클러스터 볼륨의 확인을 기다립니다. 이 확인은 이 레코드와 모든 이전 다시 실행 로그 레코드가 기록되어 쿼럼을 얻었음을 나타냅니다. 로그 레코드를 유지하고 쿼럼을 얻으면 자동 커밋이든 명시적 커밋이든 관계없이 트랜잭션의 내구성이 확보됩니다. Aurora 스토리지 아키텍처에 대한 자세한 내용은 Amazon Aurora 스토리지에 관한 이해를 돕는 문서를 참조하세요.

Aurora MySQL은 MySQL Community Edition처럼 로그를 데이터 파일로 플러시하지 않습니다. 하지만 innodb_flush_log_at_trx_commit 파라미터를 사용하여 다시 실행 로그 레코드를 Aurora 클러스터 볼륨에 쓸 때 내구성 제약을 완화할 수 있습니다.

Aurora MySQL 버전 2의 경우:

innodb_flush_log_at_trx_commit = 0 또는 2 - 데이터베이스는 다시 실행 로그 레코드가 Aurora 클러스터 볼륨에 기록된다는 확인을 기다리지 않습니다.
innodb_flush_log_at_trx_commit = 1 - 데이터베이스는 다시 실행 로그 레코드가 Aurora 클러스터 볼륨에 기록된다는 확인을 기다립니다.

Aurora MySQL 버전 3의 경우:

innodb_flush_log_at_trx_commit = 0 - 데이터베이스는 다시 실행 로그 레코드가 Aurora 클러스터 볼륨에 기록된다는 확인을 기다리지 않습니다.
innodb_flush_log_at_trx_commit = 1 또는 2 - 데이터베이스는 다시 실행 로그 레코드가 Aurora 클러스터 볼륨에 기록된다는 확인을 기다립니다.

따라서 Aurora MySQL 버전 2에서 값을 0 또는 2로 설정했을 때와 동일한 기본값이 아닌 동작이 작동하려면 Aurora MySQL 버전 3에서 파라미터를 0으로 설정하세요.

이러한 설정은 클라이언트에 대한 DML 지연 시간을 줄일 수 있지만 장애 조치 또는 재시작 시 데이터가 손실될 수도 있습니다. 따라서 innodb_flush_log_at_trx_commit 파라미터를 기본값 1로 유지하는 것이 좋습니다.

MySQL Community Edition과 Aurora MySQL 모두에서 데이터 손실이 발생할 수 있지만 아키텍처가 다르기 때문에 데이터베이스마다 동작이 다릅니다. 이러한 아키텍처 차이로 인해 데이터 손실 정도가 달라질 수 있습니다. 데이터베이스가 ACID 규정을 준수하도록 하려면 innodb_flush_log_at_trx_commit을 항상 1로 설정하세요.

참고

Aurora MySQL 버전 3에서는 innodb_flush_log_at_trx_commit을 1이 아닌 값으로 변경하려면 먼저 innodb_trx_commit_allow_data_loss의 값을 1로 변경해야 합니다. 이렇게 하면 데이터 손실의 위험을 인정하는 것으로 간주됩니다.

Aurora MySQL 교착 상태 최소화 및 문제 해결

고유한 보조 인덱스 또는 외래 키에 대한 제약 조건 위반이 정기적으로 발생하는 워크로드를 실행하는 사용자가 동일한 데이터 페이지의 레코드를 동시에 수정할 경우, 교착 상태가 증가하고 잠금 대기 시간 초과가 발생할 수 있습니다. 이러한 교착 상태 및 시간 초과는 MySQL Community Edition 버그 수정으로 인한 것입니다.

이 수정 사항은 MySQL Community Edition 버전 5.7.26 이상에 포함되었으며 Aurora MySQL 버전 2.10.3 이상에 백포트되었습니다. 이 수정 사항은 InnoDB 테이블의 레코드 변경 사항에 대해 이러한 유형의 데이터 조작 언어(DML) 작업에 대한 추가 잠금을 구현하여 직렬화 기능을 적용하는 데 필요합니다. 이 문제는 이전 MySQL Community Edition 버그 수정으로 인해 발생한 교착 상태 문제를 조사하는 과정에서 발견되었습니다.

이 수정 사항으로 InnoDB 스토리지 엔진의 튜플(행) 업데이트의 부분 롤백에 대한 내부 처리가 변경되었습니다. 외래 키 또는 고유한 보조 인덱스에서 제약 조건 위반을 생성하는 작업은 부분 롤백을 초래합니다. 여기에는 동시 INSERT...ON DUPLICATE KEY UPDATE, REPLACE INTO,, INSERT IGNORE 문(upserts)이 포함되며 이에 국한되지 않습니다.

이 컨텍스트에서 부분 롤백은 애플리케이션 레벨 트랜잭션의 롤백을 의미하지 않으며, 제약 조건 위반이 발생할 때 클러스터링된 인덱스에 대한 변경 사항의 내부 InnoDB 롤백을 의미합니다. 예를 들어 upsert 작업 중에 중복된 키 값이 발견된 경우를 가정해 보겠습니다.

일반적인 삽입 작업에서 InnoDB는 각 인덱스에 대해 클러스터링된 보조 인덱스 항목을 원자적으로 생성합니다. InnoDB가 upsert 작업 중에 고유한 보조 인덱스에서 중복 값을 감지하면 클러스터링된 인덱스에 삽입된 항목을 되돌리고(부분 롤백), 기존 중복 행에 업데이트를 적용해야 합니다. 이 내부 부분 롤백 단계에서 InnoDB는 작업의 일부로 간주되는 각 레코드를 잠가야 합니다. 이 수정 사항은 부분 롤백 후 추가 잠금을 도입하여 트랜잭션 직렬화 기능을 보장합니다.

InnoDB 교착 상태 최소화

다음과 같은 접근 방식을 사용하여 데이터베이스 인스턴스의 교착 상태 빈도를 줄일 수 있습니다. 더 많은 예제는 MySQL 설명서에서 찾을 수 있습니다.

교착 상태가 발생할 가능성을 줄이려면 관련 변경 사항을 적용한 후 즉시 트랜잭션을 커밋하세요. 이렇게 하려면 큰 트랜잭션(커밋 간 다중 행 업데이트)을 작은 트랜잭션으로 나누면 됩니다. 행을 일괄적으로 삽입할 경우 특히 앞서 언급한 upsert 작업을 사용할 때는 배치 삽입 크기를 줄이세요.

발생 가능한 부분 롤백 수를 줄이려면 다음 방법 중 일부를 시도해 봅니다.
1. 배치 삽입 작업을 한 번에 한 행씩 삽입하는 방식으로 바꿉니다. 이렇게 하면 충돌이 발생할 수 있는 트랜잭션으로 인한 잠금 유지 시간을 줄일 수 있습니다.
2. REPLACE INTO를 사용하는 대신 SQL 문을 다음과 같은 다중 문 트랜잭션으로 다시 작성합니다.
```
BEGIN;
DELETE conflicting rows;
INSERT new rows;
COMMIT;
```
3. INSERT...ON DUPLICATE KEY UPDATE를 사용하는 대신 SQL 문을 다음과 같은 다중 문 트랜잭션으로 다시 작성합니다.
```
BEGIN;
SELECT rows that conflict on secondary indexes;
UPDATE conflicting rows;
INSERT new rows;
COMMIT;
```
잠금을 유지할 가능성이 있는 활성 또는 유휴 상태의 장기 실행 트랜잭션을 방지합니다. 여기에는 커밋되지 않은 트랜잭션으로 장기간 열려 있을 가능성이 있는 대화형 MySQL 클라이언트 세션이 포함됩니다. 트랜잭션 크기 또는 배치 크기를 최적화할 경우 동시성, 중복 수, 테이블 구조와 같은 여러 요인에 따라 미치는 영향이 달라질 수 있습니다. 모든 변경 사항은 워크로드를 기반으로 구현하고 테스트해야 합니다.
상황에 따라 두 트랜잭션이 하나 또는 여러 테이블에서 서로 다른 순서로 동일한 데이터 세트에 액세스하려고 할 경우 교착 상태가 발생할 수 있습니다. 이를 방지하려면 같은 순서로 데이터에 액세스하도록 트랜잭션을 수정하여 액세스를 직렬화합니다. 예를 들어, 완료할 트랜잭션 대기열을 생성합니다. 이런 접근 방식은 여러 트랜잭션이 동시에 발생할 때 교착 상태를 방지하는 데 도움이 될 수 있습니다.
신중하게 선택한 인덱스를 테이블에 추가하면 선택성이 향상되고 행에 액세스할 필요가 줄어들기 때문에 잠금 횟수도 감소합니다.
격차 잠금이 발생할 경우 세션 또는 트랜잭션에 맞게 트랜잭션 격리 수준을 READ COMMITTED로 수정하여 이를 방지할 수 있습니다. InnoDB 격리 수준 및 해당 동작에 대한 자세한 내용은 MySQL 설명서의 트랜 잭션 격리 수준을 참조하세요.

참고

교착 상태가 발생할 가능성을 줄이기 위한 예방 조치를 취할 수는 있지만, 교착 상태는 예상된 데이터베이스 동작이며 계속 발생할 수 있습니다. 애플리케이션에는 교착 상태가 발생했을 때 이를 처리하는 데 필요한 로직이 있어야 합니다. 예를 들어, 애플리케이션에서 재시도 및 백오프 로직을 구현합니다. 문제의 근본 원인을 해결하는 것이 가장 좋지만 교착 상태가 발생할 경우 애플리케이션에는 대기 후 다시 시도할 수 있는 옵션이 있습니다.

InnoDB 교착 상태 모니터링

애플리케이션 트랜잭션이 순환 대기를 야기하는 방식으로 테이블 수준 및 행 수준 잠금을 시도할 경우 MySQL에서 교착 상태가 발생할 수 있습니다. InnoDB 스토리지 엔진은 해당 조건을 즉시 감지하고 트랜잭션 중 하나를 자동으로 롤백하기 때문에 InnoDB 교착 상태가 가끔 발생하는 건 문제가 되지 않습니다. 단, 교착 상태가 자주 발생할 경우에는 애플리케이션을 검토 및 수정하여 성능 문제를 완화하고 교착 상태를 방지하는 것이 좋습니다. 교착 상태 감지가 켜져 있으면(기본값) InnoDB는 트랜잭션 교착 상태를 자동으로 감지하고 하나 이상의 트랜잭션을 롤백하여 교착 상태를 해제합니다. InnoDB는 롤백할 작은 트랜잭션을 선택하려는 시도를 합니다. 이때 트랜잭션의 크기는 삽입되거나, 업데이트되거나, 삭제된 행 수에 따라 결정됩니다.

SHOW ENGINE 문 - SHOW ENGINE INNODB STATUS \G 문에는 마지막 재시작 이후 데이터베이스에서 발생한 가장 최근의 교착 상태에 대한 세부 정보가 포함됩니다.
MySQL 오류 로그 - SHOW ENGINE 문의 출력이 부적절하여 교착 상태가 자주 발생할 경우 innodb_print_all_deadlocks DB 클러스터 파라미터를 켤 수 있습니다.

이 파라미터를 켜면 InnoDB 사용자 트랜잭션의 모든 교착 상태에 대한 정보가 Aurora MySQL 오류 로그에 기록됩니다.
Amazon CloudWatch 지표 - 또한 CloudWatch 지표 Deadlocks를 사용하여 교착 상태를 사전에 모니터링하는 것이 좋습니다. 자세한 내용은 Amazon Aurora에 대한 인스턴스 수준 지표 단원을 참조하십시오.
Amazon CloudWatch Logs - Amazon CloudWatch Logs를 통해 지표를 보고, 로그 데이터를 분석하고, 실시간 경보를 생성할 수 있습니다. 자세한 내용은 Amazon CloudWatch를 사용하여 Amazon Aurora MySQL 및 Amazon RDS for MySQL의 오류를 모니터링하고 Amazon SNS를 사용하여 알림 보내기를 참조하세요.

innodb_print_all_deadlocks를 켠 상태로 CloudWatch Logs Logs를 사용하면 교착 상태 횟수가 지정된 임계값을 초과할 때 알려주는 경보를 구성할 수 있습니다. 임계값을 정의하려면 추세를 관찰하고 정상 워크로드를 기준으로 한 값을 사용하는 것이 좋습니다.
성능 개선 도우미 - 성능 개선 도우미를 사용하면 innodb_deadlocks 및 innodb_lock_wait_timeout 지표를 모니터링할 수 있습니다. 이러한 지표에 대한 자세한 내용은 기본이 아닌 Aurora MySQL용 카운터 섹션을 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Aurora MySQL 랩 모드

Aurora MySQL 성능 문제 해결