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

Amazon RDS MySQL에 대해 알려진 문제 및 제한

Amazon RDS MySQL 사용 시 알려진 문제 및 제한은 다음과 같습니다.

일관되지 않은 InnoDB 버퍼 풀 크기

MySQL 5.7에는 현재 InnoDB 버퍼 풀 크기가 관리되지 않는 버그가 있습니다. MySQL 5.7에서 innodb_buffer_pool_size 파라미터 값을 InnoDB 버퍼 풀 크기를 너무 많이 늘려 너무 많은 메모리를 소모하도록 하는 큰 값으로 조정할 수 있습니다. 이에 따라 MySQL 데이터베이스 엔진이 실행을 중단하거나 MySQL 데이터베이스 엔진이 시작하지 못할 수 있습니다. 이 문제는 사용 가능한 메모리가 적은 DB 인스턴스 클래스 문제보다 더 일반적으로 발생합니다.

이 문제를 해결하려면 innodb_buffer_pool_size 파라미터 값을 innodb_buffer_pool_instances 파라미터 값과 innodb_buffer_pool_chunk_size 파라미터 값의 곱의 배수로 설정해야 합니다. 예를 들어, 다음 예에서와 같이 innodb_buffer_pool_size 파라미터 값을 innodb_buffer_pool_instancesinnodb_buffer_pool_chunk_size 파라미터 값의 곱의 8배로 설정할 수 있습니다.

Copy
innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

MySQL 5.7 버그에 대한 자세한 내용은 MySQL 문서의 https://bugs.mysql.com/bug.php?id=79379을(를) 참조하십시오.

MySQL 버전 5.5.40 비동기식 I/O 비활성화

2014년 4월 23일 이전에 생성된 다음 2014년 10월 17일 이후 MySQL 버전 5.5.40으로 업그레이드된 MySQL DB 인스턴스를 보유하고 있는 경우 I/O 성능 감소를 확인하게 될 수도 있습니다. 이러한 성능 감소는 해당 DB 파라미터 그룹이 innodb_use_native_aio 파라미터를 활성화했음에도 innodb_use_native_aio 파라미터를 비활성화하는 오류로 인해 발생할 수 있습니다.

이 오류를 해결하려면 버전 5.5.40에서 실행되는 MySQL DB 인스턴스를 이러한 동작을 수정해 주는 버전 5.5.40a로 업그레이드하는 것이 좋습니다. 마이너 버전 업그레이드에 대한 자세한 내용은 MySQL DB 엔진 업그레이드을(를) 참조하십시오.

MySQL 비동기식 I/O에 대한 자세한 내용은 MySQL 설명서의 Linux에서의 비동기식 I/O을(를) 참조하십시오.

인덱스 병합 최적화가 잘못된 결과를 반환

인덱스 병합 최적화를 사용하는 쿼리는 MySQL 5.5.37에서 도입한 MySQL 쿼리 최적화 프로그램의 버그로 인해 잘못된 결과를 반환할 수도 있습니다. 복수의 인덱스가 있는 테이블에 대한 쿼리를 생성할 때 최적화 프로그램은 복수의 인덱스에 기반하여 행의 범위를 검사하지만 결과를 올바르게 병합하지는 않습니다. 쿼리 최적화 프로그램 버그에 대한 자세한 내용은 MySQL 버그 데이터베이스의 http://bugs.mysql.com/bug.php?id=72745http://bugs.mysql.com/bug.php?id=68194을(를) 참조하십시오.

예를 들면, 검색 인수가 인덱싱된 열을 참조하는 2개의 인덱스가 있는 테이블에 대한 쿼리를 고려합니다.

Copy
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

이 경우 검색 엔진이 두 인덱스를 모두 검색합니다. 그러나 버그로 인해 병합 결과가 정확하지 않습니다.

이 문제를 해결하려면 다음 중 한 가지 방법을 시도하면 됩니다.

  • MySQL DB 인스턴스용 DB 파라미터 그룹에서 optimizer_switch 파라미터를 index_merge=off로 설정합니다. DB 파라미터 그룹 파라미터 설정에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

  • MySQL DB 인스턴스를 MySQL 버전 5.6 또는 5.7로 업그레이드합니다. 자세한 내용은 MySQL DB 스냅샷 업그레이드 단원을 참조하십시오.

  • 인스턴스를 업그레이드하거나 optimizer_switch 파라미터를 변경할 수 없는 경우, 쿼리에 대한 인덱스를 명시적으로 확인하여 버그를 해결할 수 있습니다. 예:

    Copy
    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

자세한 내용은 인덱스 병합 최적화을(를) 참조하십시오.

로그 파일 크기

MySQL 버전 5.6.20 이상의 경우 다시 실행 로그에 기록된 BLOB에 대한 크기 제한이 있습니다. 이러한 제안을 감안하려면 MySQL DB 인스턴스에 대한 innodb_log_file_size 파라미터가 테이블에서 발견된 BLOB 데이터의 최대 크기 및 동일한 테이블에서의 다른 가변 길이 필드(VARCHAR, VARBINARY, TEXT)의 길이 보다 10배 커야 합니다. 파라미터 값 설정 방법에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오. 다시 실행 로그 BLOB 크기 제한에 대한 자세한 내용은 MySQL 5.6.20의 변경 내용을(를) 참조하십시오.

Amazon RDS DB 인스턴스에 대한 MySQL 파라미터 예외

일부 MySQL 파라미터의 경우 Amazon RDS DB 인스턴스와 함께 사용할 때 특별히 고려해야 할 사항이 있습니다.

lower_case_table_names

Amazon RDS는 대/소문자 구분 파일 시스템을 사용하므로 lower_case_table_names 서버 파라미터의 값을 2("이름은 지정된 대로 저장되지만 소문자로 비교됨")로 설정하는 것은 지원하지 않습니다. Amazon RDS DB 인스턴스에 지원되는 값은 기본값인 0("이름은 지정된 대로 저장되며 비교는 대/소문자로 구분하여 진행됨) 또는 1("이름은 소문자로 저장되며 비교는 대/소문자를 구분하지 않고 진행됨")입니다.

lower_case_table_names 파라미터는 DB 인스턴스를 생성하기 전에 사용자 지정 DB 파라미터 그룹의 일부로 설정해야 합니다. 지정 시간 복구 백업과 읽기 복제본 DB 인스턴스와 불일치를 유발할 수 있으므로 기존 데이터베이스 인스턴스에 대한 lower_case_table_names 파라미터를 변경하는 것을 피해야 합니다.

읽기 전용 복제본은 마스터 DB 인스턴스로 항상 동일한 lower_case_table_names 파라미터 값을 사용해야 합니다.

long_query_time

마이크로초 해상도(microsecond resolution)로 느린 쿼리를 MySQL의 느린 쿼리 로그에 기록할 수 있도록long_query_time 파라미터를 부동 소수점 값으로 설정합니다. 100밀리초에 해당하는 0.1초와 같은 값을 설정하여 1초 이내의 시간이 걸리는 느린 트랜젝션을 디버깅할 때 도움을 받을 수 있습니다.

MySQL 파일 크기 제한

Amazon RDS MySQL DB 인스턴스의 경우 최대 프로비저닝 스토리지 제한으로 인해 InnoDB 테이블당 파일 테이블스페이스를 사용하여 각 테이블의 크기가 최대 6TB로 제한됩니다. 또한 이 제한은 시스템 테이블스페이스를 최대 6TB의 크기로 제한합니다. Amazon RDS MySQL DB 인스턴스에서는 테이블이 각각 자체 테이블스페이스에 들어 있는 InnoDB 테이블당 파일 테이블스페이스가 기본적으로 설정됩니다.

참고

2014년 4월 이전에 생성된 MySQL DB 인스턴스는 파일과 테이블 크기 제한이 2TB입니다. 마찬가지로 DB 인스턴스의 생성 시기와 상관없이 2014년 4월 이전에 생성된 DB 스냅샷에서 생성한 DB 인스턴스나 읽기 복제 역시 파일 크기가 2TB로 제한됩니다.

애플리케이션에 따라 InnoDB 테이블당 파일 테이블스페이스 사용에 대한 장점과 단점은 서로 다릅니다. 애플리케이션에 가장 적합한 접근 방식을 확인하려면 MySQL 문서의 InnoDB 테이블당 파일 모드을(를) 참조하십시오.

테이블을 최대 파일 크기로 늘리도록 허용하는 것은 권장하지 않습니다. 일반적으로 모범 사례는 성능 및 복구 시간을 향상할 수 있도록 데이터를 더 작은 테이블로 분할하는 것입니다.

라지 테이블을 여러 개의 스몰 테이블로 분할하는 데 사용할 수 있는 한 가지 옵션으로 파티셔닝이 있습니다. 파티셔닝을 수행하면 사용자가 지정하는 규칙에 따라 라지 테이블의 일부가 개별 파일로 배포됩니다. 예를 들어, 트랜잭션을 날짜별로 저장하는 경우 파티셔닝을 사용하여 이전 트랜잭션을 개별 파일로 배포하는 파티셔닝 규칙을 생성할 수 있습니다. 이렇게 하면 애플리케이션에서 즉시 사용할 필요가 없는 이전 트랜잭션 데이터를 주기적으로 보관할 수 있습니다. 자세한 내용은 MySQL 문서의 https://dev.mysql.com/doc/refman/5.6/en/partitioning.html을(를) 참조하십시오.

테이블의 파일 크기를 확인하는 방법

  • 다음 SQL 명령을 사용하여 크기가 너무 커서 파티셔닝을 수행해야 하는 테이블이 있는지 확인합니다.

    Copy
    SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');

InnoDB 테이블당 파일 테이블스페이스를 활성화하는 방법

  • InnoDB 테이블당 파일 테이블스페이스를 활성화하려면 DB 인스턴스에 대한 파라미터 그룹에서 innodb_file_per_table 파라미터를 1로 설정합니다.

InnoDB 테이블당 파일 테이블스페이스를 비활성화하는 방법

  • InnoDB 테이블당 파일 테이블스페이스를 비활성화하려면 DB 인스턴스에 대한 파라미터 그룹에서 innodb_file_per_table 파라미터를 0으로 설정합니다.

파라미터 그룹 업데이트에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

InnoDB 테이블당 파일 테이블스페이스를 활성화하거나 비활성화한 경우 ALTER TABLE 명령을 실행하여 아래의 예와 같이 테이블을 전역 테이블스페이스에서 자체 테이블스페이스로 이동하거나 자체 테이블스페이스에서 전역 테이블스페이스로 이동할 수 있습니다.

Copy
ALTER TABLE table_name ENGINE=InnoDB;