# Amazon Aurora MySQL 참조
이 참조에는 Aurora MySQL 파라미터, 상태 변수 및 일반 SQL 확장 또는 커뮤니티 MySQL 데이터베이스 엔진과의 차이점에 대한 정보가 포함되어 있습니다.
**Topics**
+ [Aurora MySQL 구성 파라미터](AuroraMySQL.Reference.ParameterGroups.md)
+ [Aurora MySQL 글로벌 상태 변수](AuroraMySQL.Reference.GlobalStatusVars.md)
+ [Aurora MySQL 대기 이벤트](AuroraMySQL.Reference.Waitevents.md)
+ [Aurora MySQL 스레드 상태](AuroraMySQL.Reference.thread-states.md)
+ [Aurora MySQL 격리 수준](AuroraMySQL.Reference.IsolationLevels.md)
+ [Aurora MySQL 힌트](AuroraMySQL.Reference.Hints.md)
+ [Aurora MySQL 저장 프로시저 참조](AuroraMySQL.Reference.StoredProcs.md)
+ [Aurora MySQL 전용 information\$1schema 테이블](AuroraMySQL.Reference.ISTables.md)
# Aurora MySQL 구성 파라미터
Amazon Aurora MySQL DB 클러스터는 다른 Amazon RDS DB 인스턴스와 마찬가지로 DB 파라미터 그룹의 파라미터를 사용하여 관리합니다. Amazon Aurora는 DB 클러스터가 다수의 DB 인스턴스로 구성되는 다른 DB 엔진들과 다릅니다. 결과적으로 Aurora MySQL DB 클러스를 관리하기 위해 사용하는 파라미터 중 일부는 전체 클러스터에 적용됩니다. 다른 파라미터는 DB 클러스터의 특정 DB 인스턴스에만 적용됩니다.
클러스터 수준 파라미터를 관리하려면 DB 클러스터 파라미터 그룹을 사용합니다. 인스턴스 수준 파라미터를 관리하려면 DB 파라미터 그룹을 사용합니다. Aurora MySQL DB 클러스터의 각 DB 인스턴스는 MySQL 데이터베이스 엔진과 호환됩니다. 그러나 MySQL 데이터베이스 엔진 파라미터 중 일부는 클러스터 수준에서 적용하며 이러한 파라미터는 DB 클러스터 파라미터그룹을 사용하여 관리합니다. Aurora DB 클러스터에 있는 인스턴스의 DB 파라미터 그룹에서는 클러스터 수준 파라미터를 찾을 수 없습니다. 클러스터 수준 파라미터의 목록은 이 단원 후반부에 나옵니다.
클러스터 수준 파라미터와 인스턴스 수준 파라미터는 모두 AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용하여 관리할 수 있습니다. 클러스터 수준 파라미터와 인스턴스 수준 파라미터를 관리하기 위한 명령은 서로 다릅니다. 예를 들어 [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) CLI 명령을 사용해 DB 클러스터 파라미터 그룹에서 클러스터 수준 파라미터를 관리할 수 있습니다. [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) CLI 명령을 사용해 DB 클러스터 내 DB 인스턴스의 DB 파라미터 그룹에서 인스턴스 수준 파라미터를 관리할 수 있습니다.
클러스터 수준 파라미터와 인스턴스 수준 파라미터는 모두 콘솔에서 확인하거나 CLI 또는 RDS API를 사용해 확인할 수 있습니다. 예를 들어 [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) AWS CLI 명령을 사용해 DB 클러스터 파라미터 그룹에서 클러스터 수준 파라미터를 확인할 수 있습니다. [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) CLI 명령을 사용해 DB 클러스터 내 DB 인스턴스의 DB 파라미터 그룹에서 인스턴스 수준 파라미터를 확인할 수 있습니다.
**참고**
각 [기본 파라미터 그룹](USER_WorkingWithParamGroups.md)에는 파라미터 그룹에 있는 모든 파라미터의 기본값이 포함됩니다. 파라미터에 이 값의 “엔진 기본값”이 있는 경우, 실제 기본값은 버전별 MySQL 또는 PostgreSQL 설명서를 참조하세요.
달리 명시되지 않는 한, 다음 표에 나열된 파라미터는 Aurora MySQL 버전 2 및 3에 유효합니다.
DB 파라미터 그룹에 대한 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오. Aurora Serverless v1 클러스터에 대한 규칙 및 제한 사항은 [Aurora Serverless v1 파라미터 그룹](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups) 단원을 참조하십시오.
**Topics**
+ [클러스터 수준 파라미터](#AuroraMySQL.Reference.Parameters.Cluster)
+ [인스턴스 수준 파라미터](#AuroraMySQL.Reference.Parameters.Instance)
+ [Aurora MySQL에 적용되지 않는 MySQL 파라미터](#AuroraMySQL.Reference.Parameters.Inapplicable)
## 클러스터 수준 파라미터
다음 표에는 전체 Aurora MySQL DB 클러스터에 적용되는 모든 파라미터가 나와 있습니다.
| 파라미터 이름 | 수정 가능 | 참고 |
| --- | --- | --- |
| `aurora_binlog_read_buffer_size` | 예 | 이진 로그(binlog) 복제를 사용하는 클러스터에만 영향을 줍니다. binlog 복제에 대한 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 단원을 참조하세요. Aurora MySQL 버전 3에서 제거되었습니다. |
| `aurora_binlog_replication_max_yield_seconds` | 예 | 이진 로그(binlog) 복제를 사용하는 클러스터에만 영향을 줍니다. binlog 복제에 대한 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 단원을 참조하십시오. |
| `aurora_binlog_replication_sec_index_parallel_workers` | 예 | 보조 인덱스가 두 개 이상인 대규모 테이블의 트랜잭션을 복제할 때 보조 인덱스 변경 사항을 적용하는 데 사용할 수 있는 총 병렬 스레드 수를 설정합니다. 기본적으로 파라미터는 `0`(비활성화됨)로 설정됩니다. 이 파라미터는 Aurora MySQL 버전 306 이상에서 사용할 수 있습니다. 자세한 내용은 [Aurora MySQL의 이진수 로그 복제 최적화](binlog-optimization.md) 단원을 참조하십시오. |
| `aurora_binlog_use_large_read_buffer` | 예 | 이진 로그(binlog) 복제를 사용하는 클러스터에만 영향을 줍니다. binlog 복제에 대한 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 단원을 참조하세요. Aurora MySQL 버전 3에서 제거되었습니다. |
| `aurora_disable_hash_join` | 예 | Aurora MySQL 버전 2.09 이상에서 해시 조인 최적화를 비활성화하려면 이 파라미터를 `ON`으로 설정하세요. 버전 3에는 지원되지 않습니다. 자세한 내용은 [Amazon Aurora MySQL용 병렬 쿼리](aurora-mysql-parallel-query.md) 단원을 참조하십시오. |
| `aurora_enable_replica_log_compression` | 예 | 자세한 내용은 [Amazon Aurora MySQL 복제를 위한 성능 고려 사항](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance) 섹션을 참조하세요. Aurora Global Database의 일부로 포함된 클러스터에는 적용되지 않습니다. Aurora MySQL 버전 3에서 제거되었습니다. |
| `aurora_enable_repl_bin_log_filtering` | 예 | 자세한 내용은 [Amazon Aurora MySQL 복제를 위한 성능 고려 사항](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance) 섹션을 참조하세요. Aurora Global Database의 일부로 포함된 클러스터에는 적용되지 않습니다. Aurora MySQL 버전 3에서 제거되었습니다. |
| `aurora_enable_staggered_replica_restart` | 예 | 이 설정은 Aurora MySQL 버전 3에서 사용할 수 있지만 사용되지는 않습니다. |
| `aurora_enable_zdr` | 예 | 이 설정은 Aurora MySQL 2.10 이상에서 기본적으로 켜집니다. 자세한 내용은 [Amazon Aurora MySQL의 제로 다운타임 다시 시작(ZDR)](AuroraMySQL.Replication.Availability.md) 섹션을 참조하세요. |
| `aurora_enhanced_binlog` | 예 | Aurora MySQL 버전 3.03.1 이상에서 향상된 binlog를 켜려면 이 파라미터의 값을 1로 설정하세요. 자세한 내용은 [Aurora MySQL에 대해 향상된 binlog 설정](AuroraMySQL.Enhanced.binlog.md) 단원을 참조하십시오. |
| `aurora_jemalloc_background_thread` | 예 | 이 파라미터를 사용하여 백그라운드 스레드가 메모리 유지 관리 작업을 수행할 수 있도록 합니다. 허용되는 값은 `0`(비활성화) 및 `1`(활성화)입니다. 기본값은 `0`입니다. 이 파라미터는 Aurora MySQL 버전 3.05 이상에 적용됩니다. |
| `aurora_jemalloc_dirty_decay_ms` | 예 | 이 파라미터를 사용하여 비워진 메모리를 일정 시간(밀리초) 동안 유지할 수 있습니다. 메모리를 유지하면 더 빠르게 재사용할 수 있습니다. 허용 값은 `0`\$1`18446744073709551615`입니다. 기본값(`0`)은 모든 메모리를 사용 가능한 메모리로 운영 체제에 반환합니다. 이 파라미터는 Aurora MySQL 버전 3.05 이상에 적용됩니다. |
| `aurora_jemalloc_tcache_enabled` | 예 | 이 파라미터를 사용하면 메모리 아레나를 우회하여 스레드 로컬 캐시에서 작은 메모리 요청(최대 32KiB)을 처리할 수 있습니다. 허용되는 값은 `0`(비활성화) 및 `1`(활성화)입니다. 기본값은 `1`입니다. 이 파라미터는 Aurora MySQL 버전 3.05 이상에 적용됩니다. |
| `aurora_load_from_s3_role` | 예 | 자세한 내용은 [Amazon S3 버킷의 텍스트 파일에서 Amazon Aurora MySQL DB 클러스터로 데이터 로드](AuroraMySQL.Integrating.LoadFromS3.md) 단원을 참조하십시오. 현재 Aurora MySQL 버전 3에서는 사용할 수 없습니다. `aws_default_s3_role`를 사용합니다. |
| `aurora_mask_password_hashes_type` | 예 | 이 설정은 Aurora MySQL 2.11 이상에서는 기본적으로 켜집니다. 이 설정을 사용하면 느린 쿼리 로그 및 감사 로그에서 Aurora MySQL 암호 해시를 마스킹할 수 있습니다. 허용되는 값은 `0` 및 `1`(기본값)입니다. `1`로 설정하면 암호가 ``으로 기록됩니다. `0`으로 설정하면 암호가 해시(`#`) 값으로 기록됩니다. |
| `aurora_select_into_s3_role` | 예 | 자세한 내용은 [Amazon Aurora MySQL DB 클러스터에서 Amazon S3 버킷의 텍스트 파일로 데이터 저장](AuroraMySQL.Integrating.SaveIntoS3.md) 단원을 참조하십시오. 현재 Aurora MySQL 버전 3에서는 사용할 수 없습니다. `aws_default_s3_role`를 사용합니다. |
| `authentication_kerberos_caseins_cmp` | 예 | `authentication_kerberos` 플러그인의 대소문자를 구분하지 않는 사용자 이름 비교를 제어합니다. 대소문자를 구분하지 않고 비교하려면 `true`로 설정합니다. 기본적으로 대소문자를 구분하는 비교가 사용됩니다(`false`). 자세한 내용은 [Aurora MySQL에 Kerberos 인증 사용](aurora-mysql-kerberos.md) 단원을 참조하십시오. 이 파라미터는 Aurora MySQL 버전 3.03 이상에서 사용할 수 있습니다. |
| `auto_increment_increment` | 예 | |
| `auto_increment_offset` | 예 | |
| `aws_default_lambda_role` | 예 | 자세한 내용은 [Amazon Aurora MySQL DB 클러스터에서 Lambda 함수 호출](AuroraMySQL.Integrating.Lambda.md) 섹션을 참조하세요. |
| `aws_default_s3_role` | 예 | DB 클러스터에서 `LOAD DATA FROM S3`, `LOAD XML FROM S3` 또는 `SELECT INTO OUTFILE S3` 문을 호출하는 데 사용됩니다. Aurora MySQL 버전 2에서 이 파라미터에 지정된 IAM 역할은 적절한 문에 대해 `aurora_load_from_s3_role` 또는 `aurora_select_into_s3_role`에 IAM 역할이 지정되지 않은 경우에 사용됩니다. Aurora MySQL 버전 3에서는 이 파라미터에 지정된 IAM 역할이 항상 사용됩니다. 자세한 내용은 [IAM 역할을 Amazon Aurora MySQL DB 클러스터와 연결](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md) 단원을 참조하십시오. |
| `binlog_backup` | 예 | Aurora MySQL 버전 3.03.1 이상에서 향상된 binlog를 켜려면 이 파라미터의 값을 0으로 설정하세요. 향상된 binlog를 사용하는 경우에만 이 파라미터를 해제할 수 있습니다. 자세한 내용은 [Aurora MySQL에 대해 향상된 binlog 설정](AuroraMySQL.Enhanced.binlog.md) 단원을 참조하십시오. |
| `binlog_checksum` | 예 | 이 파라미터가 설정되지 않은 경우 AWS CLI 및 RDS API는 `None`의 값을 보고합니다. 이 경우 Aurora MySQL에서는 엔진 기본값 (`CRC32`) 을 사용합니다. 이 설정은 체크섬을 비활성화하는 `NONE`의 명시적 설정과 다릅니다. |
| `binlog-do-db` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_format` | 예 | 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 단원을 참조하십시오. |
| `binlog_group_commit_sync_delay` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_group_commit_sync_no_delay_count` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog-ignore-db` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_replication_globaldb` | 예 | Aurora MySQL 버전 3.03.1 이상에서 향상된 binlog를 켜려면 이 파라미터의 값을 0으로 설정하세요. 향상된 binlog를 사용하는 경우에만 이 파라미터를 해제할 수 있습니다. 자세한 내용은 [Aurora MySQL에 대해 향상된 binlog 설정](AuroraMySQL.Enhanced.binlog.md) 단원을 참조하십시오. |
| `binlog_row_image` | 아니요 | |
| `binlog_row_metadata` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_row_value_options` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_rows_query_log_events` | 예 | |
| `binlog_transaction_compression` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_transaction_compression_level_zstd` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_transaction_dependency_history_size` | 예 | 이 파라미터는 메모리에 보관되고 지정된 행을 마지막으로 수정한 트랜잭션을 조회하는 데 사용되는 행 해시 수의 상한을 설정합니다. 해시 수가 이 상한에 도달하면 기록이 삭제됩니다. 이 파라미터는 Aurora MySQL 버전 2.12 이상 및 버전 3에 적용됩니다. |
| `binlog_transaction_dependency_tracking` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `character-set-client-handshake` | 예 | |
| `character_set_client` | 예 | |
| `character_set_connection` | 예 | |
| `character_set_database` | 예 | |
| `character_set_filesystem` | 예 | |
| `character_set_results` | 예 | |
| `character_set_server` | 예 | |
| `collation_connection` | 예 | |
| `collation_server` | 예 | |
| `completion_type` | 예 | |
| `default_storage_engine` | 아니요 | Aurora MySQL 클러스터는 모든 데이터에 InnoDB 스토리지 엔진을 사용합니다. |
| `enforce_gtid_consistency` | 가끔 | Aurora MySQL 버전 2 이상에서 수정 가능. |
| `event_scheduler` | 예 | 이벤트 스케줄러의 상태를 나타냅니다. Aurora MySQL 버전 3에서는 클러스터 수준에서만 수정할 수 있습니다. |
| `gtid-mode` | 가끔 | Aurora MySQL 버전 2 이상에서 수정 가능. |
| `information_schema_stats_expiry` | 예 | MySQL 데이터베이스 서버가 스토리지 엔진에서 데이터를 가져와 캐시에 있는 데이터를 교체하는 데 걸리는 시간(초)입니다. 허용 값은 `0`\$1`31536000`입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `init_connect` | 예 | 연결된 각 클라이언트에 대해 서버에서 실행할 명령입니다. 연결 실패를 방지하려면 설정에 큰따옴표(“)를 사용해야 합니다. 예를 들면 다음과 같습니다. SET optimizer_switch="hash_join=off"
Aurora MySQL 버전 3에서는 `CONNECTION_ADMIN` 권한이 있는 사용자에게 이 파라미터가 적용되지 않습니다. Aurora 마스터 사용자도 마찬가지입니다. 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 단원을 참조하십시오. |
| `innodb_adaptive_hash_index` | 예 | 이 파라미터는 Aurora MySQL 버전 2와 3의 DB 클러스터 수준에서 수정할 수 있습니다. Adaptive Hash Index는 리더 DB 인스턴스에서 지원되지 않습니다. |
| `innodb_aurora_instant_alter_column_allowed` | 예 | `INSTANT` 알고리즘이 글로벌 수준의 `ALTER COLUMN` 작업에 사용할 수 있는지를 제어합니다. 허용되는 값은 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 자세한 내용은 MySQL 설명서의 [열 작업](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) 섹션을 참조하세요. 이 파라미터는 Aurora MySQL 버전 3.05 이상에 적용됩니다. |
| `innodb_autoinc_lock_mode` | 예 | |
| `innodb_checksums` | 아니요 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `innodb_cmp_per_index_enabled` | 예 | |
| `innodb_commit_concurrency` | 예 | |
| `innodb_data_home_dir` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `innodb_deadlock_detect` | 예 | 이 옵션은 Aurora MySQL 버전 2.11 이상 및 버전 3에서 고착 감지를 비활성화하는 데 사용됩니다. 동시성이 높은 시스템에서 수많은 스레드가 동일한 잠금을 기다릴 때 고착 감지로 인해 속도가 느려질 수 있습니다. 이 파라미터에 대한 자세한 내용은 MySQL 설명서를 참조하세요. |
| `innodb_default_row_format` | 예 | 이 파라미터는 InnoDB 테이블(사용자가 만든 InnoDB 임시 테이블 포함)의 기본 행 형식을 정의합니다. Aurora MySQL 버전 2와 3에 적용됩니다. 값은 `DYNAMIC`, `COMPACT` 또는 `REDUNDANT.`일 수 있습니다. |
| `innodb_file_per_table` | 예 | 이 파라미터는 테이블 스토리지가 구성되는 방식에 영향을 미칩니다. 자세한 내용은 [스토리지 조정](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling) 단원을 참조하십시오. |
| `innodb_flush_log_at_trx_commit` | 예 | 기본값인 `1`을 그대로 사용하는 것이 좋습니다. Aurora MySQL 버전 3에서 이 파라미터를 `1`이 아닌 값으로 설정하려면 먼저 `innodb_trx_commit_allow_data_loss`의 값을 `1`로 변경해야 합니다. 자세한 내용은 [로그 버퍼를 플러시하는 빈도 구성](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush) 단원을 참조하십시오. |
| `innodb_ft_max_token_size` | 예 | |
| `innodb_ft_min_token_size` | 예 | |
| `innodb_ft_num_word_optimize` | 예 | |
| `innodb_ft_sort_pll_degree` | 예 | |
| `innodb_online_alter_log_max_size` | 예 | |
| `innodb_optimize_fulltext_only` | 예 | |
| `innodb_page_size` | 아니요 | |
| `innodb_print_all_deadlocks` | 예 | 이 파라미터를 켜져 있으면 모든 InnoDB 교착 상태에 대한 정보가 Aurora MySQL 오류 로그에 기록됩니다. 자세한 내용은 [Aurora MySQL 교착 상태 최소화 및 문제 해결](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks) 단원을 참조하십시오. |
| `innodb_purge_batch_size` | 예 | |
| `innodb_purge_threads` | 예 | |
| `innodb_rollback_on_timeout` | 예 | |
| `innodb_rollback_segments` | 예 | |
| `innodb_spin_wait_delay` | 예 | |
| `innodb_strict_mode` | 예 | |
| `innodb_support_xa` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `innodb_sync_array_size` | 예 | |
| `innodb_sync_spin_loops` | 예 | |
| `innodb_stats_include_delete_marked` | 예 | 이 파라미터를 활성화하면 InnoDB는 영구 최적화 프로그램 통계를 계산할 때 삭제 표시된 레코드를 포함합니다. 이 파라미터는 Aurora MySQL 버전 2.12 이상 및 버전 3에 적용됩니다. |
| `innodb_table_locks` | 예 | |
| `innodb_trx_commit_allow_data_loss` | 예 | Aurora MySQL 버전 3에서 `innodb_flush_log_at_trx_commit` 값을 변경할 수 있도록 이 파라미터를 `1`로 설정합니다. `innodb_trx_commit_allow_data_loss`의 기본값은 `0`입니다. 자세한 내용은 [로그 버퍼를 플러시하는 빈도 구성](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush) 단원을 참조하십시오. |
| `innodb_undo_directory` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `internal_tmp_disk_storage_engine` | 예 | 내부 임시 테이블에 사용되는 인메모리 스토리지 엔진을 제어합니다. 허용되는 값은 `INNODB` 및 `MYISAM`입니다. 이 파라미터는 Aurora MySQL 버전 2에 적용됩니다. |
| `internal_tmp_mem_storage_engine` | 예 | 내부 임시 테이블에 사용되는 인메모리 스토리지 엔진을 제어합니다. 허용되는 값은 `MEMORY` 및 `TempTable`입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `key_buffer_size` | 예 | MyISAM 테이블의 키 캐시입니다. 자세한 내용은 [keycache->cache\$1lock 뮤텍스 관련 설명](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock)을 참조하세요. |
| `lc_time_names` | 예 | |
| `log_error_suppression_list` | 예 | MySQL 오류 로그에서 로깅되지 않은 오류 코드 목록을 지정합니다. 이렇게 하면 중요하지 않은 특정 오류 조건을 무시하여 오류 로그를 깔끔하게 유지할 수 있습니다. 자세한 내용은 MySQL 설명서의 [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list)를 참조하세요. 이 파라미터는 Aurora MySQL 버전 3.03 이상에 적용됩니다. |
| `low_priority_updates` | 예 | `INSERT`, `UPDATE`, `DELETE` 및 `LOCK TABLE WRITE` 작업은 보류 중인 `SELECT` 작업이 없을 때까지 대기합니다. 이 파라미터는 테이블 수준 잠금(MyISAM, MEMORY, MERGE)만 사용하는 스토리지 엔진에만 영향을 줍니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `lower_case_table_names` | 예(Aurora MySQL 버전 2) 클러스터 생성 시에만(Aurora MySQL 버전 3) | Aurora MySQL 버전 2.10 이상 2.x 버전에서는 이 설정을 변경하고 작성자 인스턴스를 재부팅한 후 모든 리더 인스턴스를 재부팅해야 합니다. 자세한 내용은 [읽기 가용성을 포함하여 Aurora 클러스터 재부팅](aurora-mysql-survivable-replicas.md) 섹션을 참조하세요. Aurora MySQL 버전 3에서 이 파라미터의 값은 클러스터가 생성될 때 영구적으로 설정됩니다. 이 옵션에 기본값이 아닌 값을 사용하는 경우 업그레이드하기 전에 Aurora MySQL 버전 3 사용자 지정 파라미터를 설정하고 버전 3 클러스터를 생성하는 스냅샷 복원 작업 중에 파라미터 그룹을 지정합니다. Aurora MySQL 기반 Aurora Global Database 사용 시 `lower_case_table_names` 파라미터가 활성화 되어 있는 경우 Aurora MySQL 버전 2에서 버전 3으로 현재 위치 업그레이드를 수행할 수 없습니다. 사용할 수 있는 메서드에 대한 자세한 내용은 [메이저 버전 업그레이드](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major) 섹션을 참조하세요. |
| `master-info-repository` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `master_verify_checksum` | 예 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `source_verify_checksum`을 사용합니다. |
| `max_delayed_threads` | 예 | `INSERT DELAYED` 명령문을 처리할 최대 스레드 수를 설정합니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `max_error_count` | 예 | 표시용으로 저장할 오류, 경고 및 참고 메시지의 최대 수입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `max_execution_time` | 예 | `SELECT` 문의 실행 제한 시간(밀리초)입니다. 값은 `0`\$1`18446744073709551615`가 될 수 있습니다. `0`으로 설정하면 제한 시간이 없습니다. 자세한 내용은 MySQL 설명서의 [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time)을 참조하세요. |
| `min_examined_row_limit` | 예 | 이 파라미터를 사용하면 지정한 개수보다 적은 수의 행을 검사하는 쿼리가 로깅되지 않도록 할 수 있습니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `partial_revokes` | 아니요 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `preload_buffer_size` | 예 | 인덱스를 미리 로드할 때 할당되는 버퍼의 크기입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `query_cache_type` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `read_only` | 예 | 이 파라미터를 켜면 서버는 복제본 스레드에서 수행한 업데이트를 제외한 어떤 업데이트도 허용하지 않습니다. Aurora MySQL 버전 2에 유효한 값은 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Aurora MySQL 버전 3에 유효한 값은 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Aurora MySQL 버전 3에서는 `CONNECTION_ADMIN` 권한이 있는 사용자에게 이 파라미터가 적용되지 않습니다. Aurora 마스터 사용자도 마찬가지입니다. 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 단원을 참조하십시오. |
| `relay-log-space-limit` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replica_parallel_type` | 예 | 이 파라미터를 사용하면 이미 준비 단계에 있는 모든 커밋되지 않은 스레드의 복제본에서 일관성을 침해하지 않고 병렬 실행을 수행할 수 있습니다. Aurora MySQL 버전 3에 적용됩니다. Aurora MySQL 버전 3.03.\$1 이하에서는 기본값이 DATABASE입니다. Aurora MySQL 버전 3.04 이상에서는 기본값이 LOGICAL\$1CLOCK입니다. |
| `replica_preserve_commit_order` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replica_transaction_retries` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replica_type_conversions` | 예 | 이 파라미터는 복제본에 사용되는 유형 변환을 결정합니다. 허용되는 값은 `ALL_LOSSY`, `ALL_NON_LOSSY`, `ALL_SIGNED`, `ALL_UNSIGNED`입니다. 자세한 내용은 MySQL 설명서의 [소스 및 복제본에서 서로 다른 테이블 정의를 사용하는 복제](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html)를 참조하세요. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replicate-do-db` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replicate-do-table` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replicate-ignore-db` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replicate-ignore-table` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replicate-wild-do-table` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `replicate-wild-ignore-table` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `require_secure_transport` | 예 | 이 파라미터는 Aurora MySQL 버전 2와 3에 적용됩니다. 자세한 내용은 [Aurora MySQL DB 클러스터에 대한 TLS 연결](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL) 단원을 참조하십시오. |
| `rpl_read_size` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `server_audit_cw_upload` | 아니요 | 이 파라미터는 Aurora MySQL에서 더 이상 사용되지 않습니다. `server_audit_logs_upload`를 사용합니다. 자세한 내용은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 단원을 참조하십시오. |
| `server_audit_events` | 예 | 자세한 내용은 [Amazon Aurora MySQL DB 클러스터에서 고급 감사 사용](AuroraMySQL.Auditing.md) 단원을 참조하십시오. |
| `server_audit_excl_users` | 예 | 자세한 내용은 [Amazon Aurora MySQL DB 클러스터에서 고급 감사 사용](AuroraMySQL.Auditing.md) 단원을 참조하십시오. |
| `server_audit_incl_users` | 예 | 자세한 내용은 [Amazon Aurora MySQL DB 클러스터에서 고급 감사 사용](AuroraMySQL.Auditing.md) 단원을 참조하십시오. |
| `server_audit_logging` | 예 | 로그를 Amazon CloudWatch Logs에 업로드하는 방법에 관한 지침은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 단원을 참조하십시오. |
| `server_audit_logs_upload` | 예 | 고급 감사를 활성화하고 이 파라미터를 `1`로 설정하여 CloudWatch Logs에 감사 로그를 게시할 수 있습니다. `server_audit_logs_upload` 파라미터의 기본 값은 `0`입니다. 자세한 내용은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 단원을 참조하십시오. |
| `server_id` | 아니요 | |
| `skip-character-set-client-handshake` | 예 | |
| `skip_name_resolve` | 아니요 | |
| `slave-skip-errors` | 예 | MySQL 5.7 호환성을 갖춘 Aurora MySQL 버전 2 클러스터에만 적용됩니다. |
| `source_verify_checksum` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `sync_frm` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `thread_cache_size` | 예 | 캐시할 스레드 수입니다. 이 파라미터는 Aurora MySQL 버전 2와 3에 적용됩니다. |
| `time_zone` | 예 | 기본적으로 Aurora DB 클러스터의 시간대는 협정 세계시(UTC)입니다. 대신 DB 클러스터의 인스턴스 시간대를 애플리케이션의 현지 시간대로 설정할 수 있습니다. 자세한 내용은 [Amazon Aurora DB 클러스터의 현지 시간대](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone) 단원을 참조하십시오. |
| `tls_version` | 예 | 자세한 내용은 [Aurora MySQL에 지원되는 TLS 버전](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version) 섹션을 참조하세요. |
## 인스턴스 수준 파라미터
다음 표에는 Aurora MySQL DB 클러스터의 특정 DB 클러스터에 적용되는 모든 파라미터가 나와 있습니다.
| 파라미터 이름 | 수정 가능 | 참고 |
| --- | --- | --- |
| `activate_all_roles_on_login` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `allow-suspicious-udfs` | 아니요 | |
| `aurora_disable_hash_join` | 예 | Aurora MySQL 버전 2.09 이상에서 해시 조인 최적화를 비활성화하려면 이 파라미터를 `ON`으로 설정하세요. 버전 3에는 지원되지 않습니다. 자세한 내용은 [Amazon Aurora MySQL용 병렬 쿼리](aurora-mysql-parallel-query.md) 단원을 참조하십시오. |
| `aurora_lab_mode` | 예 | 자세한 내용은 [Amazon Aurora MySQL 랩 모드](AuroraMySQL.Updates.LabMode.md) 단원을 참조하십시오. Aurora MySQL 버전 3에서 제거되었습니다. |
| `aurora_oom_response` | 예 | 이 파라미터는 Aurora MySQL 버전 2 및 3에서 지원됩니다. 자세한 내용은 [Aurora MySQL 데이터베이스의 메모리 부족 문제 해결](AuroraMySQLOOM.md) 단원을 참조하십시오. |
| `aurora_parallel_query` | 예 | Aurora MySQL 버전 2.09 이상에서 병렬 쿼리를 켜려면 `ON`으로 설정합니다. 이전 `aurora_pq` 파라미터는 이러한 버전에서 사용되지 않습니다. 자세한 내용은 [Amazon Aurora MySQL용 병렬 쿼리](aurora-mysql-parallel-query.md) 섹션을 참조하세요. |
| `aurora_pq` | 예 | 2.09 이전 Aurora MySQL 버전에서 특정 DB 인스턴스에 대한 병렬 쿼리를 해제하려면 `OFF`로 설정합니다. 버전 2.09 이상에서는 `aurora_parallel_query`를 사용하여 병렬 쿼리를 설정하거나 해제합니다. 자세한 내용은 [Amazon Aurora MySQL용 병렬 쿼리](aurora-mysql-parallel-query.md) 단원을 참조하십시오. |
| `aurora_read_replica_read_committed` | 예 | Aurora 복제본에 대해 `READ COMMITTED` 격리 수준을 활성화하고 격리 동작을 변경하여 장기 실행 쿼리 중 삭제 지연 시간을 줄입니다. 이 설정은 동작 변경과 이러한 변경이 쿼리 결과에 미치는 영향을 이해한 경우에만 활성화하십시오. 예를 들어 이 설정에서는 MySQL 기본값보다 덜 엄격한 격리를 사용합니다. 이 설정이 활성화된 경우 쿼리 실행 중 Aurora에서 테이블 데이터를 재편하므로 장기 실행 쿼리에서는 동일 행의 사본을 두 개 이상 반환할 수 있습니다. 자세한 내용은 [Aurora MySQL 격리 수준](AuroraMySQL.Reference.IsolationLevels.md) 단원을 참조하십시오. |
| `aurora_tmptable_enable_per_table_limit` | 예 | `tmp_table_size` 파라미터가 Aurora MySQL 버전 3.04 이상의 `TempTable` 스토리지 엔진에서 생성된 인 메모리 임시 테이블의 최대 크기를 제어하는지를 결정합니다. 자세한 내용은 [내부 인 메모리 임시 테이블의 크기 제한](ams3-temptable-behavior.md#ams3-temptable-behavior-limit) 단원을 참조하십시오. |
| `aurora_use_vector_instructions` | 예 | 이 파라미터가 활성화되면 Aurora MySQL은 최신 CPU에서 제공하는 최적화된 벡터 처리 명령을 사용하여 I/O 집약적인 워크로드의 성능을 개선합니다. 이 설정은 Aurora MySQL 3.05 이상에서는 기본적으로 활성화됩니다. |
| `autocommit` | 예 | |
| `automatic_sp_privileges` | 예 | |
| `back_log` | 예 | |
| `basedir` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `binlog_cache_size` | 예 | |
| `binlog_max_flush_queue_time` | 예 | |
| `binlog_order_commits` | 예 | |
| `binlog_stmt_cache_size` | 예 | |
| `binlog_transaction_compression` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `binlog_transaction_compression_level_zstd` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `bulk_insert_buffer_size` | 예 | |
| `concurrent_insert` | 예 | |
| `connect_timeout` | 예 | |
| `core-file` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `datadir` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `default_authentication_plugin` | 아니요 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `default_time_zone` | 아니요 | |
| `default_tmp_storage_engine` | 예 | 임시 테이블의 기본 스토리지 엔진입니다. |
| `default_week_format` | 예 | |
| `delay_key_write` | 예 | |
| `delayed_insert_limit` | 예 | |
| `delayed_insert_timeout` | 예 | |
| `delayed_queue_size` | 예 | |
| `div_precision_increment` | 예 | |
| `end_markers_in_json` | 예 | |
| `eq_range_index_dive_limit` | 예 | |
| `event_scheduler` | 가끔 | 이벤트 스케줄러의 상태를 나타냅니다. Aurora MySQL 버전 3에서는 클러스터 수준에서만 수정할 수 있습니다. |
| `explicit_defaults_for_timestamp` | 예 | |
| `flush` | 아니요 | |
| `flush_time` | 예 | |
| `ft_boolean_syntax` | 아니요 | |
| `ft_max_word_len` | 예 | |
| `ft_min_word_len` | 예 | |
| `ft_query_expansion_limit` | 예 | |
| `ft_stopword_file` | 예 | |
| `general_log` | 예 | 로그를 CloudWatch Logs에 업로드하는 것에 관한 지침은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 단원을 참조하십시오. |
| `general_log_file` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `group_concat_max_len` | 예 | |
| `host_cache_size` | 예 | |
| `init_connect` | 예 | 연결된 각 클라이언트에 대해 서버에서 실행할 명령입니다. 연결 실패를 방지하려면 설정에 큰따옴표(“)를 사용해야 합니다. 예를 들면 다음과 같습니다. SET optimizer_switch="hash_join=off"
Aurora MySQL 버전 3에서는 Aurora 마스터 사용자를 비롯하여 `CONNECTION_ADMIN` 권한이 있는 사용자에게 이 파라미터가 적용되지 않습니다. 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 단원을 참조하십시오. |
| `innodb_adaptive_hash_index` | 예 | 이 파라미터는 Aurora MySQL 버전 2의 DB 인스턴스 수준에서 수정할 수 있습니다. Aurora MySQL 버전 3에서는 DB 클러스터 수준에서만 수정할 수 있습니다. Adaptive Hash Index는 리더 DB 인스턴스에서 지원되지 않습니다. |
| `innodb_adaptive_max_sleep_delay` | 예 | Aurora에 대해 `innodb_thread_concurrency`는 항상 0이므로 이 파라미터를 수정해도 효과가 없습니다. |
| `innodb_aurora_max_partitions_for_range` | 예 | 영구 통계를 사용할 수 없는 경우 이 파라미터를 사용하여 파티션으로 분할된 테이블의 행 수 추정 성능을 개선할 수 있습니다. 0\$18,192 범위의 값으로 설정할 수 있으며, 이 값에 따라 행 수를 추정하는 동안 검사할 파티션 수가 결정됩니다. 기본값은 0이며, 이 값은 기본 MySQL 동작과 일치하게 모든 파티션을 사용하여 추정합니다. 이 파라미터는 Aurora MySQL 버전 3.03.1 이상에서 사용할 수 있습니다. |
| `innodb_autoextend_increment` | 예 | |
| `innodb_buffer_pool_dump_at_shutdown` | 아니요 | |
| `innodb_buffer_pool_dump_now` | 아니요 | |
| `innodb_buffer_pool_filename` | 아니요 | |
| `innodb_buffer_pool_load_abort` | 아니요 | |
| `innodb_buffer_pool_load_at_startup` | 아니요 | |
| `innodb_buffer_pool_load_now` | 아니요 | |
| `innodb_buffer_pool_size` | 예 | 기본값은 공식으로 표시됩니다. 수식에서 `DBInstanceClassMemory` 값을 계산하는 방법에 대한 자세한 내용은 [DB 파라미터 수식 변수](USER_ParamValuesRef.md#USER_FormulaVariables) 섹션을 참조하세요. |
| `innodb_change_buffer_max_size` | 아니요 | Aurora MySQL은 InnoDB 변경 버퍼를 전혀 사용하지 않습니다. |
| `innodb_compression_failure_threshold_pct` | 예 | |
| `innodb_compression_level` | 예 | |
| `innodb_compression_pad_pct_max` | 예 | |
| `innodb_concurrency_tickets` | 예 | Aurora에 대해 `innodb_thread_concurrency`는 항상 0이므로 이 파라미터를 수정해도 효과가 없습니다. |
| `innodb_deadlock_detect` | 예 | 이 옵션은 Aurora MySQL 버전 2.11 이상 및 버전 3에서 고착 감지를 비활성화하는 데 사용됩니다. 동시성이 높은 시스템에서 수많은 스레드가 동일한 잠금을 기다릴 때 고착 감지로 인해 속도가 느려질 수 있습니다. 이 파라미터에 대한 자세한 내용은 MySQL 설명서를 참조하세요. |
| `innodb_file_format` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `innodb_flushing_avg_loops` | 아니요 | |
| `innodb_force_load_corrupted` | 아니요 | |
| `innodb_ft_aux_table` | 예 | |
| `innodb_ft_cache_size` | 예 | |
| `innodb_ft_enable_stopword` | 예 | |
| `innodb_ft_server_stopword_table` | 예 | |
| `innodb_ft_user_stopword_table` | 예 | |
| `innodb_large_prefix` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `innodb_lock_wait_timeout` | 예 | |
| `innodb_log_compressed_pages` | 아니요 | |
| `innodb_lru_scan_depth` | 예 | |
| `innodb_max_purge_lag` | 예 | |
| `innodb_max_purge_lag_delay` | 예 | |
| `innodb_monitor_disable` | 예 | |
| `innodb_monitor_enable` | 예 | |
| `innodb_monitor_reset` | 예 | |
| `innodb_monitor_reset_all` | 예 | |
| `innodb_old_blocks_pct` | 예 | |
| `innodb_old_blocks_time` | 예 | |
| `innodb_open_files` | 예 | |
| `innodb_print_all_deadlocks` | 예 | 이 파라미터를 켜져 있으면 모든 InnoDB 교착 상태에 대한 정보가 Aurora MySQL 오류 로그에 기록됩니다. 자세한 내용은 [Aurora MySQL 교착 상태 최소화 및 문제 해결](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks) 단원을 참조하십시오. |
| `innodb_random_read_ahead` | 예 | |
| `innodb_read_ahead_threshold` | 예 | |
| `innodb_read_io_threads` | 아니요 | |
| `innodb_read_only` | 아니요 | Aurora MySQL은 클러스터 유형을 기반으로 읽기 전용 및 읽기-쓰기 상태의 DB 인스턴스를 관리합니다. 예를 들어 프로비저닝된 클러스터에는 읽기-쓰기 DB 인스턴스(*기본 인스턴스*) 하나가 있으며, 클러스터에 있는 기타 인스턴스는 읽기 전용(Aurora 복제본)입니다. |
| `innodb_replication_delay` | 예 | |
| `innodb_sort_buffer_size` | 예 | |
| `innodb_stats_auto_recalc` | 예 | |
| `innodb_stats_method` | 예 | |
| `innodb_stats_on_metadata` | 예 | |
| `innodb_stats_persistent` | 예 | |
| `innodb_stats_persistent_sample_pages` | 예 | |
| `innodb_stats_transient_sample_pages` | 예 | |
| `innodb_thread_concurrency` | 아니요 | |
| `innodb_thread_sleep_delay` | 예 | Aurora에 대해 `innodb_thread_concurrency`는 항상 0이므로 이 파라미터를 수정해도 효과가 없습니다. |
| `interactive_timeout` | 예 | Aurora는 `interactive_timeout` 및 `wait_timeout`의 최소값을 평가합니다. 그런 다음, 해당 최소값을 시간 초과로 사용하여 대화형 및 비대화형 모든 유휴 세션을 종료합니다. |
| `internal_tmp_disk_storage_engine` | 예 | 내부 임시 테이블에 사용되는 인메모리 스토리지 엔진을 제어합니다. 허용되는 값은 `INNODB` 및 `MYISAM`입니다. 이 파라미터는 Aurora MySQL 버전 2에 적용됩니다. |
| `internal_tmp_mem_storage_engine` | 예 | 내부 임시 테이블에 사용되는 인메모리 스토리지 엔진을 제어합니다. 허용되는 값은 `MEMORY` 및 `TempTable`입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `join_buffer_size` | 예 | |
| `keep_files_on_create` | 예 | |
| `key_buffer_size` | 예 | MyISAM 테이블의 키 캐시입니다. 자세한 내용은 [keycache->cache\$1lock 뮤텍스 관련 설명](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock)을 참조하세요. |
| `key_cache_age_threshold` | 예 | |
| `key_cache_block_size` | 예 | |
| `key_cache_division_limit` | 예 | |
| `local_infile` | 예 | |
| `lock_wait_timeout` | 예 | |
| `log-bin` | 아니요 | `binlog_format`을 `STATEMENT`, `MIXED` 또는 `ROW`로 설정하면 `log-bin`이 자동으로 `ON`으로 설정됩니다. `binlog_format`을 `OFF`로 설정하면 `log-bin`이 자동으로 `OFF`로 설정됩니다. 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요. |
| `log_bin_trust_function_creators` | 예 | |
| `log_bin_use_v1_row_events` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `log_error` | 아니요 | |
| `log_error_suppression_list` | 예 | MySQL 오류 로그에서 로깅되지 않은 오류 코드 목록을 지정합니다. 이렇게 하면 중요하지 않은 특정 오류 조건을 무시하여 오류 로그를 깔끔하게 유지할 수 있습니다. 자세한 내용은 MySQL 설명서의 [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list)를 참조하세요. 이 파라미터는 Aurora MySQL 버전 3.03 이상에 적용됩니다. |
| `log_output` | 예 | |
| `log_queries_not_using_indexes` | 예 | |
| `log_slave_updates` | 아니요 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `log_replica_updates`을 사용합니다. |
| `log_replica_updates` | 아니요 | Aurora MySQL 버전 3 |
| `log_throttle_queries_not_using_indexes` | 예 | |
| `log_warnings` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `long_query_time` | 예 | |
| `low_priority_updates` | 예 | `INSERT`, `UPDATE`, `DELETE` 및 `LOCK TABLE WRITE` 작업은 보류 중인 `SELECT` 작업이 없을 때까지 대기합니다. 이 파라미터는 테이블 수준 잠금(MyISAM, MEMORY, MERGE)만 사용하는 스토리지 엔진에만 영향을 줍니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `max_allowed_packet` | 예 | |
| `max_binlog_cache_size` | 예 | |
| `max_binlog_size` | 아니요 | |
| `max_binlog_stmt_cache_size` | 예 | |
| `max_connect_errors` | 예 | |
| `max_connections` | 예 | 기본값은 공식으로 표시됩니다. 수식에서 `DBInstanceClassMemory` 값을 계산하는 방법에 대한 자세한 내용은 [DB 파라미터 수식 변수](USER_ParamValuesRef.md#USER_FormulaVariables) 섹션을 참조하세요. 인스턴스 클래스에 따른 기본값은 [Aurora MySQL DB 인스턴스에 대한 최대 연결](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections) 섹션을 참조하세요. |
| `max_delayed_threads` | 예 | `INSERT DELAYED` 명령문을 처리할 최대 스레드 수를 설정합니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `max_error_count` | 예 | 표시용으로 저장할 오류, 경고 및 참고 메시지의 최대 수입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `max_execution_time` | 예 | `SELECT` 문의 실행 제한 시간(밀리초)입니다. 값은 `0`\$1`18446744073709551615`가 될 수 있습니다. `0`으로 설정하면 제한 시간이 없습니다. 자세한 내용은 MySQL 설명서의 [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time)을 참조하세요. |
| `max_heap_table_size` | 예 | |
| `max_insert_delayed_threads` | 예 | |
| `max_join_size` | 예 | |
| `max_length_for_sort_data` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `max_prepared_stmt_count` | 예 | |
| `max_seeks_for_key` | 예 | |
| `max_sort_length` | 예 | |
| `max_sp_recursion_depth` | 예 | |
| `max_tmp_tables` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `max_user_connections` | 예 | |
| `max_write_lock_count` | 예 | |
| `metadata_locks_cache_size` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `min_examined_row_limit` | 예 | 이 파라미터를 사용하면 지정한 개수보다 적은 수의 행을 검사하는 쿼리가 로깅되지 않도록 할 수 있습니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `myisam_data_pointer_size` | 예 | |
| `myisam_max_sort_file_size` | 예 | |
| `myisam_mmap_size` | 예 | |
| `myisam_sort_buffer_size` | 예 | |
| `myisam_stats_method` | 예 | |
| `myisam_use_mmap` | 예 | |
| `net_buffer_length` | 예 | |
| `net_read_timeout` | 예 | |
| `net_retry_count` | 예 | |
| `net_write_timeout` | 예 | |
| `old-style-user-limits` | 예 | |
| `old_passwords` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `optimizer_prune_level` | 예 | |
| `optimizer_search_depth` | 예 | |
| `optimizer_switch` | 예 | 이 스위치를 사용하는 Aurora MySQL 기능에 대한 자세한 내용은 [Amazon Aurora MySQL 모범 사례](AuroraMySQL.BestPractices.md) 단원을 참조하십시오. |
| `optimizer_trace` | 예 | |
| `optimizer_trace_features` | 예 | |
| `optimizer_trace_limit` | 예 | |
| `optimizer_trace_max_mem_size` | 예 | |
| `optimizer_trace_offset` | 예 | |
| `performance-schema-consumer-events-waits-current` | 예 | |
| `performance-schema-instrument` | 예 | |
| `performance_schema` | 예 | |
| `performance_schema_accounts_size` | 예 | |
| `performance_schema_consumer_global_instrumentation` | 예 | |
| `performance_schema_consumer_thread_instrumentation` | 예 | |
| `performance_schema_consumer_events_stages_current` | 예 | |
| `performance_schema_consumer_events_stages_history` | 예 | |
| `performance_schema_consumer_events_stages_history_long` | 예 | |
| `performance_schema_consumer_events_statements_current` | 예 | |
| `performance_schema_consumer_events_statements_history` | 예 | |
| `performance_schema_consumer_events_statements_history_long` | 예 | |
| `performance_schema_consumer_events_waits_history` | 예 | |
| `performance_schema_consumer_events_waits_history_long` | 예 | |
| `performance_schema_consumer_statements_digest` | 예 | |
| `performance_schema_digests_size` | 예 | |
| `performance_schema_events_stages_history_long_size` | 예 | |
| `performance_schema_events_stages_history_size` | 예 | |
| `performance_schema_events_statements_history_long_size` | 예 | |
| `performance_schema_events_statements_history_size` | 예 | |
| `performance_schema_events_transactions_history_long_size` | 예 | |
| `performance_schema_events_transactions_history_size` | 예 | |
| `performance_schema_events_waits_history_long_size` | 예 | |
| `performance_schema_events_waits_history_size` | 예 | |
| `performance_schema_hosts_size` | 예 | |
| `performance_schema_max_cond_classes` | 예 | |
| `performance_schema_max_cond_instances` | 예 | |
| `performance_schema_max_digest_length` | 예 | |
| `performance_schema_max_file_classes` | 예 | |
| `performance_schema_max_file_handles` | 예 | |
| `performance_schema_max_file_instances` | 예 | |
| `performance_schema_max_index_stat` | 예 | |
| `performance_schema_max_memory_classes` | 예 | |
| `performance_schema_max_metadata_locks` | 예 | |
| `performance_schema_max_mutex_classes` | 예 | |
| `performance_schema_max_mutex_instances` | 예 | |
| `performance_schema_max_prepared_statements_instances` | 예 | |
| `performance_schema_max_program_instances` | 예 | |
| `performance_schema_max_rwlock_classes` | 예 | |
| `performance_schema_max_rwlock_instances` | 예 | |
| `performance_schema_max_socket_classes` | 예 | |
| `performance_schema_max_socket_instances` | 예 | |
| `performance_schema_max_sql_text_length` | 예 | |
| `performance_schema_max_stage_classes` | 예 | |
| `performance_schema_max_statement_classes` | 예 | |
| `performance_schema_max_statement_stack` | 예 | |
| `performance_schema_max_table_handles` | 예 | |
| `performance_schema_max_table_instances` | 예 | |
| `performance_schema_max_table_lock_stat` | 예 | |
| `performance_schema_max_thread_classes` | 예 | |
| `performance_schema_max_thread_instances` | 예 | |
| `performance_schema_session_connect_attrs_size` | 예 | |
| `performance_schema_setup_actors_size` | 예 | |
| `performance_schema_setup_objects_size` | 예 | |
| `performance_schema_show_processlist` | 예 | 이 파라미터는 어떤 SHOW PROCESSLIST 구현을 사용할지를 결정합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)이 파라미터는 Aurora MySQL 버전 2.12 이상 및 버전 3에 적용됩니다. |
| `performance_schema_users_size` | 예 | |
| `pid_file` | 아니요 | |
| `plugin_dir` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `port` | 아니요 | Aurora MySQL은 연결 속성을 관리하여 클러스터에 속한 모든 DB 인스턴스에 일관된 설정을 적용합니다. |
| `preload_buffer_size` | 예 | 인덱스를 미리 로드할 때 할당되는 버퍼의 크기입니다. 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `profiling_history_size` | 예 | |
| `query_alloc_block_size` | 예 | |
| `query_cache_limit` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `query_cache_min_res_unit` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `query_cache_size` | 예 | 기본값은 공식으로 표시됩니다. 수식에서 `DBInstanceClassMemory` 값을 계산하는 방법에 대한 자세한 내용은 [DB 파라미터 수식 변수](USER_ParamValuesRef.md#USER_FormulaVariables) 섹션을 참조하세요. Aurora MySQL 버전 3에서 제거되었습니다. |
| `query_cache_type` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `query_cache_wlock_invalidate` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `query_prealloc_size` | 예 | |
| `range_alloc_block_size` | 예 | |
| `read_buffer_size` | 예 | |
| `read_only` | 예 | 이 파라미터를 켜면 서버는 복제본 스레드에서 수행한 업데이트를 제외한 어떤 업데이트도 허용하지 않습니다. Aurora MySQL 버전 2에 유효한 값은 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 장애 조치 시 `read_only` 파라미터가 새 라이터 인스턴스에 적용되도록 하려면 Aurora MySQL 버전 2의 DB 클러스터 파라미터 그룹을 사용하는 것이 좋습니다. Aurora MySQL은 모든 리더에 대해 `innodb_read_only`를 `1`로 설정하므로 리더 인스턴스는 항상 읽기 전용입니다. 따라서 `read_only`는 리더 인스턴스에서 중복됩니다. Aurora MySQL 버전 3에서 인스턴스 수준에서 제거되었습니다. |
| `read_rnd_buffer_size` | 예 | |
| `relay-log` | 아니요 | |
| `relay_log_info_repository` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `relay_log_recovery` | 아니요 | |
| `replica_checkpoint_group` | 예 | Aurora MySQL 버전 3 |
| `replica_checkpoint_period` | 예 | Aurora MySQL 버전 3 |
| `replica_parallel_workers` | 예 | Aurora MySQL 버전 3 |
| `replica_pending_jobs_size_max` | 예 | Aurora MySQL 버전 3 |
| `replica_skip_errors` | 예 | Aurora MySQL 버전 3 |
| `replica_sql_verify_checksum` | 예 | Aurora MySQL 버전 3 |
| `safe-user-create` | 예 | |
| `secure_auth` | 예 | 이 파라미터는 Aurora MySQL 버전 2에서 항상 활성화되어 있습니다. 비활성화하려고 하면 오류가 발생합니다. Aurora MySQL 버전 3에서 제거되었습니다. |
| `secure_file_priv` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `show_create_table_verbosity` | 예 | 이 변수를 활성화하면 기본 형식인지와 상관없이 [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html)이 `ROW_FORMAT`을 표시합니다. 이 파라미터는 Aurora MySQL 버전 2.12 이상 및 버전 3에 적용됩니다. |
| `skip-slave-start` | 아니요 | |
| `skip_external_locking` | 아니요 | |
| `skip_show_database` | 예 | |
| `slave_checkpoint_group` | 예 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `replica_checkpoint_group`을 사용합니다. |
| `slave_checkpoint_period` | 예 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `replica_checkpoint_period`을 사용합니다. |
| `slave_parallel_workers` | 예 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `replica_parallel_workers`을 사용합니다. |
| `slave_pending_jobs_size_max` | 예 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `replica_pending_jobs_size_max`을 사용합니다. |
| `slave_sql_verify_checksum` | 예 | Aurora MySQL 버전 2 Aurora MySQL 버전 3에서 `replica_sql_verify_checksum`을 사용합니다. |
| `slow_launch_time` | 예 | |
| `slow_query_log` | 예 | 로그를 CloudWatch Logs에 업로드하는 것에 관한 지침은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 단원을 참조하십시오. |
| `slow_query_log_file` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `socket` | 아니요 | |
| `sort_buffer_size` | 예 | |
| `sql_mode` | 예 | |
| `sql_select_limit` | 예 | |
| `stored_program_cache` | 예 | |
| `sync_binlog` | 아니요 | |
| `sync_master_info` | 예 | |
| `sync_source_info` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. |
| `sync_relay_log` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `sync_relay_log_info` | 예 | |
| `sysdate-is-now` | 예 | |
| `table_cache_element_entry_ttl` | 아니요 | |
| `table_definition_cache` | 예 | 기본값은 공식으로 표시됩니다. 수식에서 `DBInstanceClassMemory` 값을 계산하는 방법에 대한 자세한 내용은 [DB 파라미터 수식 변수](USER_ParamValuesRef.md#USER_FormulaVariables) 섹션을 참조하세요. |
| `table_open_cache` | 예 | 기본값은 공식으로 표시됩니다. 수식에서 `DBInstanceClassMemory` 값을 계산하는 방법에 대한 자세한 내용은 [DB 파라미터 수식 변수](USER_ParamValuesRef.md#USER_FormulaVariables) 섹션을 참조하세요. |
| `table_open_cache_instances` | 예 | |
| `temp-pool` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. |
| `temptable_max_mmap` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. 세부 정보는 [Aurora MySQL 버전 3의 새로운 임시 테이블 동작](ams3-temptable-behavior.md)을 참조하세요. |
| `temptable_max_ram` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. 세부 정보는 [Aurora MySQL 버전 3의 새로운 임시 테이블 동작](ams3-temptable-behavior.md)을 참조하세요. |
| `temptable_use_mmap` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. 세부 정보는 [Aurora MySQL 버전 3의 새로운 임시 테이블 동작](ams3-temptable-behavior.md)을 참조하세요. |
| `thread_cache_size` | 예 | 캐시할 스레드 수입니다. 이 파라미터는 Aurora MySQL 버전 2와 3에 적용됩니다. |
| `thread_handling` | 아니요 | |
| `thread_stack` | 예 | |
| `timed_mutexes` | 예 | |
| `tmp_table_size` | 예 | Aurora MySQL 버전 3의 `MEMORY` 스토리지 엔진이 생성한 내부 인 메모리 임시 테이블의 최대 크기를 정의합니다. Aurora MySQL 버전 3.04 이상에서는 `aurora_tmptable_enable_per_table_limit`이 `ON`일 때 `TempTable` 스토리지 엔진이 생성한 내부 인 메모리 임시 테이블의 최대 크기를 정의합니다. 자세한 내용은 [내부 인 메모리 임시 테이블의 크기 제한](ams3-temptable-behavior.md#ams3-temptable-behavior-limit) 단원을 참조하십시오. |
| `tmpdir` | 아니요 | Aurora MySQL은 관리형 인스턴스를 사용하므로 사용자가 직접 파일 시스템에 액세스하지 않습니다. |
| `transaction_alloc_block_size` | 예 | |
| `transaction_isolation` | 예 | 이 파라미터는 Aurora MySQL 버전 3에 적용됩니다. `tx_isolation`을 대체합니다. |
| `transaction_prealloc_size` | 예 | |
| `tx_isolation` | 예 | Aurora MySQL 버전 3에서 제거되었습니다. `transaction_isolation`으로 대체됩니다. |
| `updatable_views_with_limit` | 예 | |
| `validate-password` | 아니요 | |
| `validate_password_dictionary_file` | 아니요 | |
| `validate_password_length` | 아니요 | |
| `validate_password_mixed_case_count` | 아니요 | |
| `validate_password_number_count` | 아니요 | |
| `validate_password_policy` | 아니요 | |
| `validate_password_special_char_count` | 아니요 | |
| `wait_timeout` | 예 | Aurora는 `interactive_timeout` 및 `wait_timeout`의 최소값을 평가합니다. 그런 다음, 해당 최소값을 시간 초과로 사용하여 대화형 및 비대화형 모든 유휴 세션을 종료합니다. |
## Aurora MySQL에 적용되지 않는 MySQL 파라미터
Aurora MySQL과 MySQL 간의 아키텍처 차이 때문에 일부 MySQL 파라미터는 Aurora MySQL에 적용되지 않습니다.
다음 MySQL 파라미터는 Aurora MySQL에 적용되지 않습니다. 단, 이 목록이 전부는 아닙니다.
+ `activate_all_roles_on_login` - 이 파라미터는 Aurora MySQL 버전 2에 적용되지 않습니다. Aurora MySQL 버전 3에서 사용할 수 있습니다.
+ `big_tables`
+ `bind_address`
+ `character_sets_dir`
+ `innodb_adaptive_flushing`
+ `innodb_adaptive_flushing_lwm`
+ `innodb_buffer_pool_chunk_size`
+ `innodb_buffer_pool_instances`
+ `innodb_change_buffering`
+ `innodb_checksum_algorithm`
+ `innodb_data_file_path`
+ `innodb_dedicated_server`
+ `innodb_doublewrite`
+ `innodb_flush_log_at_timeout` - 이 파라미터는 Aurora MySQL에 적용되지 않습니다. 자세한 내용은 [로그 버퍼를 플러시하는 빈도 구성](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush) 단원을 참조하십시오.
+ `innodb_flush_method`
+ `innodb_flush_neighbors`
+ `innodb_io_capacity`
+ `innodb_io_capacity_max`
+ `innodb_log_buffer_size`
+ `innodb_log_file_size`
+ `innodb_log_files_in_group`
+ `innodb_log_spin_cpu_abs_lwm`
+ `innodb_log_spin_cpu_pct_hwm`
+ `innodb_log_writer_threads`
+ `innodb_max_dirty_pages_pct`
+ `innodb_numa_interleave`
+ `innodb_page_size`
+ `innodb_redo_log_capacity`
+ `innodb_redo_log_encrypt`
+ `innodb_undo_log_encrypt`
+ `innodb_undo_log_truncate`
+ `innodb_undo_logs`
+ `innodb_undo_tablespaces`
+ `innodb_use_native_aio`
+ `innodb_write_io_threads`
# Aurora MySQL 글로벌 상태 변수
Aurora MySQL에는 커뮤니티 MySQL의 상태 변수와 Aurora에 고유한 변수가 포함되어 있습니다. 이러한 변수를 검사하여 데이터베이스 엔진 내에서 어떤 일이 일어나고 있는지 알아볼 수 있습니다. 커뮤니티 MySQL의 상태 변수에 대한 자세한 내용은 커뮤니티 MySQL 8.0 설명서의 [서버 상태 변수](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html)를 참조하세요.
다음과 같은 명령문을 사용하여 Aurora MySQL 글로벌 상태 변수의 현재 값을 찾을 수 있습니다.
```
show global status like '%aurora%';
```
**참고**
DB 엔진이 재부팅되면 전역 상태 변수가 지워집니다.
다음 테이블에는 Aurora MySQL이 사용하는 글로벌 상태 변수가 설명되어 있습니다.
| 이름 | 설명 |
| --- | --- |
| `AuroraDb_commits` | 마지막 재시작 이후 총 커밋 수입니다. |
| `AuroraDb_commit_latency` | 마지막 재시작 이후 집계된 커밋 지연 시간입니다. |
| `AuroraDb_ddl_stmt_duration` | 마지막 재시작 이후 집계된 DDL 지연 시간입니다. |
| `AuroraDb_select_stmt_duration` | 마지막 재시작 이후 집계된 `SELECT` 명령문 지연 시간입니다. |
| `AuroraDb_insert_stmt_duration` | 마지막 재시작 이후 집계된 `INSERT` 명령문 지연 시간입니다. |
| `AuroraDb_update_stmt_duration` | 마지막 재시작 이후 집계된 `UPDATE` 명령문 지연 시간입니다. |
| `AuroraDb_delete_stmt_duration` | 마지막 재시작 이후 집계된 `DELETE` 명령문 지연 시간입니다. |
| `Aurora_binlog_io_cache_allocated` | Binlog I/O 캐시에 할당된 바이트 수입니다. |
| `Aurora_binlog_io_cache_read_requests` | Binlog I/O 캐시에 전송된 읽기 요청 수입니다. |
| `Aurora_binlog_io_cache_reads` | Binlog I/O 캐시에서 제공된 읽기 요청 수입니다. |
| `Aurora_enhanced_binlog` | 이 DB 인스턴스에 대해 향상된 binlog를 활성화했는지 아니면 비활성화했는지를 나타냅니다. 자세한 내용은 [Aurora MySQL에 대해 향상된 binlog 설정](AuroraMySQL.Enhanced.binlog.md) 섹션을 참조하세요. |
| `Aurora_external_connection_count` | DB 인스턴스에 대한 데이터베이스 연결 수입니다. 데이터베이스 상태 확인에 사용되는 RDS 서비스 연결은 제외됩니다. |
| `Aurora_fast_insert_cache_hits` | 캐싱된 커서가 성공적으로 검색 및 확인되면 증가하는 카운터입니다. 고속 삽입 캐시에 대한 자세한 내용은 [Amazon Aurora MySQL 성능 개선 사항](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance) 섹션을 참조하세요. |
| `Aurora_fast_insert_cache_misses` | 캐싱된 커서가 더 이상 유효하지 않고 Aurora가 정상적인 인덱스 순회를 수행하면 증가하는 카운터입니다. 고속 삽입 캐시에 대한 자세한 내용은 [Amazon Aurora MySQL 성능 개선 사항](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance) 섹션을 참조하세요. |
| `Aurora_fts_cache_memory_used` | InnoDB 전체 텍스트 검색 시스템이 사용 중인 메모리 양(바이트)입니다. 이 변수는 Aurora MySQL 버전 3.07 이상에 적용됩니다. |
| `Aurora_fwd_master_dml_stmt_count` | 이 라이터 DB 인스턴스로 전달된 총 DML 명령문 수입니다. 이 변수는 Aurora MySQL 버전 2에 적용됩니다. |
| `Aurora_fwd_master_dml_stmt_duration` | 이 라이터 DB 인스턴스로 전달된 DML 명령문의 총 기간입니다. 이 변수는 Aurora MySQL 버전 2에 적용됩니다. |
| `Aurora_fwd_master_errors_rpc_timeout` | 전달된 연결이 라이터에서 설정되지 못한 횟수입니다. |
| `Aurora_fwd_master_errors_session_limit` | 전달된 쿼리 중 라이터의 `session full`로 인해 거부된 쿼리 수입니다. |
| `Aurora_fwd_master_errors_session_timeout` | 라이터의 시간 초과로 인해 전달 세션이 종료된 횟수입니다. |
| `Aurora_fwd_master_open_sessions` | 라이터 DB 인스턴스에 있는 전달된 세션 수입니다. 이 변수는 Aurora MySQL 버전 2에 적용됩니다. |
| `Aurora_fwd_master_select_stmt_count` | 이 라이터 DB 인스턴스로 전달된 총 `SELECT` 명령문 수입니다. 이 변수는 Aurora MySQL 버전 2에 적용됩니다. |
| `Aurora_fwd_master_select_stmt_duration` | 이 라이터 DB 인스턴스로 전달된 `SELECT` 명령문의 총 기간입니다. 이 변수는 Aurora MySQL 버전 2에 적용됩니다. |
| `Aurora_fwd_writer_dml_stmt_count` | 이 라이터 DB 인스턴스로 전달된 총 DML 명령문 수입니다. 이 변수는 Aurora MySQL 버전 3에 적용됩니다. |
| `Aurora_fwd_writer_dml_stmt_duration` | 이 라이터 DB 인스턴스로 전달된 DML 명령문의 총 기간입니다. 이 변수는 Aurora MySQL 버전 3에 적용됩니다. |
| `Aurora_fwd_writer_errors_rpc_timeout` | 전달된 연결이 라이터에서 설정되지 못한 횟수입니다. |
| `Aurora_fwd_writer_errors_session_limit` | 전달된 쿼리 중 라이터의 `session full`로 인해 거부된 쿼리 수입니다. |
| `Aurora_fwd_writer_errors_session_timeout` | 라이터의 시간 초과로 인해 전달 세션이 종료된 횟수입니다. |
| `Aurora_fwd_writer_open_sessions` | 라이터 DB 인스턴스에 있는 전달된 세션 수입니다. 이 변수는 Aurora MySQL 버전 3에 적용됩니다. |
| `Aurora_fwd_writer_select_stmt_count` | 이 라이터 DB 인스턴스로 전달된 총 `SELECT` 명령문 수입니다. 이 변수는 Aurora MySQL 버전 3에 적용됩니다. |
| `Aurora_fwd_writer_select_stmt_duration` | 이 라이터 DB 인스턴스로 전달된 `SELECT` 명령문의 총 기간입니다. 이 변수는 Aurora MySQL 버전 3에 적용됩니다. |
| `Aurora_lockmgr_buffer_pool_memory_used` | Aurora MySQL 잠금 관리자가 사용하는 버퍼 풀 메모리의 양(바이트)입니다. |
| `Aurora_lockmgr_memory_used` | Aurora MySQL 잠금 관리자가 사용하는 메모리의 양(바이트)입니다. |
| `Aurora_ml_actual_request_cnt` | DB 인스턴스 사용자가 실행하는 모든 쿼리에 걸쳐 Aurora MySQL이 Aurora 기계 학습 서비스에 전송하는 총 요청 수입니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `Aurora_ml_actual_response_cnt` | DB 인스턴스 사용자가 실행하는 모든 쿼리에 걸쳐 Aurora MySQL이 Aurora 기계 학습 서비스에서 수신하는 총 응답 횟수입니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `Aurora_ml_cache_hit_cnt` | DB 인스턴스 사용자가 실행하는 모든 쿼리에 걸쳐 Aurora MySQL이 Aurora 기계 학습 서비스에서 수신하는 총 내부 캐시 히트 횟수입니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `Aurora_ml_logical_request_cnt` | 마지막 상태 재설정 이후 DB 인스턴스가 Aurora 기계 학습 서비스로 전송되어야 한다고 평가한 논리적 요청의 수입니다. 배치 사용 여부에 따라 이 값은 `Aurora_ml_actual_request_cnt`보다 높을 수 있습니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `Aurora_ml_logical_response_cnt` | DB 인스턴스 사용자가 실행하는 모든 쿼리에 걸쳐 Aurora MySQL이 Aurora 기계 학습 서비스에서 수신하는 총 응답 횟수입니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `Aurora_ml_retry_request_cnt` | 마지막 상태 재설정 이후 DB 인스턴스가 Aurora 기계 학습 서비스로 전송한 재시도 요청의 수입니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `Aurora_ml_single_request_cnt` | DB 인스턴스 사용자가 실행하는 모든 쿼리에 걸쳐 비일괄 모드로 평가되는 Aurora 기계 학습 함수의 총 개수입니다. 자세한 내용은 [Aurora MySQL과 함께 Amazon Aurora 기계 학습 사용](mysql-ml.md) 섹션을 참조하세요. |
| `aurora_oom_avoidance_recovery_state` | 이 DB 인스턴스에 대해 Aurora 메모리 부족(OOM) 회피 복구가 `ACTIVE` 상태인지 `INACTIVE` 상태인지를 나타냅니다. 이 변수는 Aurora MySQL 버전 3.06.0 이상에 적용됩니다. |
| `aurora_oom_reserved_mem_enter_kb` | Aurora의 OOM 처리 메커니즘에서 `RESERVED` 상태로 진입하는 임계값을 나타냅니다. 서버의 사용 가능한 메모리가 이 임계값 아래로 떨어지면`aurora_oom_status`가 `RESERVED`로 변경되어 서버의 메모리 사용량이 임계 수준에 가까워지고 있음을 나타냅니다. 이 변수는 Aurora MySQL 버전 3.06.0 이상에 적용됩니다. |
| `aurora_oom_reserved_mem_exit_kb` | Aurora의 OOM 처리 메커니즘에서 `RESERVED` 상태를 종료하는 임계값을 나타냅니다. 서버의 사용 가능한 메모리가 이 임계값 이상으로 올라가면 `aurora_oom_status`는 `NORMAL`로 되돌아가 서버가 충분한 메모리 리소스를 갖춘 보다 안정적인 상태로 돌아갔음을 나타냅니다. 이 변수는 Aurora MySQL 버전 3.06.0 이상에 적용됩니다. |
| `aurora_oom_status` | 이 DB 인스턴스의 현재 OOM 상태를 나타냅니다. 값이 `NORMAL`인 경우 메모리 리소스가 충분함을 나타냅니다. 값이 `RESERVED`로 변경되면 서버의 사용 가능한 메모리가 부족함을 나타냅니다. `aurora_oom_response` 파라미터 구성에 따라 조치가 취해집니다. 자세한 내용은 [Aurora MySQL 데이터베이스의 메모리 부족 문제 해결](AuroraMySQLOOM.md) 섹션을 참조하세요. 이 변수는 Aurora MySQL 버전 3.06.0 이상에 적용됩니다. |
| `Aurora_pq_bytes_returned` | 병렬 쿼리 동안 헤드 노드에 전송된 튜플 데이터 구조를 위한 바이트 수입니다. `Aurora_pq_pages_pushed_down`과 비교하기 위해 16,384로 나눕니다. |
| `Aurora_pq_max_concurrent_requests` | 이 Aurora DB 인스턴스에서 동시에 실행될 수 있는 병렬 쿼리 세션의 최대 수입니다. 이 수는 AWS DB 인스턴스 클래스에 따라 결정되는 고정된 수입니다. |
| `Aurora_pq_pages_pushed_down` | 병렬 쿼리가 헤드 노드로 네트워크 전송을 회피한 데이터 페이지의 수입니다(각각 16 KiB의 고정 크기). |
| `Aurora_pq_request_attempted` | 요청된 병렬 쿼리 세션의 수입니다. 이 값은 하위 쿼리 및 조인과 같은 SQL 구조에 따라, 쿼리 당 두 개 이상의 세션을 나타낼 수 있습니다. |
| `Aurora_pq_request_executed` | 병렬 쿼리 세션의 수가 성공적으로 실행됩니다. |
| `Aurora_pq_request_failed` | 클라이언트에 오류를 반환한 병렬 쿼리 세션의 수입니다. 일부 경우에 병렬 쿼리를 위한 요청이 실패할 수도 있습니다(예를 들어, 스토리지 계층의 문제로 인해). 이러한 경우에는 실패한 쿼리 부분이 비병렬 쿼리 메커니즘을 사용하여 다시 시도됩니다. 다시 시도된 쿼리 또한 실패하는 경우, 오류가 클라이언트에 반환되고 이 카운터가 증가합니다. |
| `Aurora_pq_request_in_progress` | 병렬 쿼리 세션의 수가 현재 진행 중입니다. 이 수는 전체 Aurora DB 클러스터가 아니라 연결되어 있는 특정 Aurora DB 인스턴스에 적용됩니다. DB 인스턴스가 동시성 한도에 근접했는지 확인하려면, 이 값을 `Aurora_pq_max_concurrent_requests`와 비교합니다. |
| `Aurora_pq_request_not_chosen` | 병렬 쿼리가 쿼리를 충족시키기 위해 선택되지 않은 횟수입니다. 이 값은 여러 개의 다른 더 세분화된 카운터의 합계입니다. 쿼리가 실제로 수행되지 않더라도 `EXPLAIN` 문을 통해 이 카운터가 증가할 수 있습니다. |
| `Aurora_pq_request_not_chosen_below_min_rows` | 테이블에 있는 행의 수로 인해 병렬 쿼리가 선택되지 않은 횟수입니다. 쿼리가 실제로 수행되지 않더라도 `EXPLAIN` 문을 통해 이 카운터가 증가할 수 있습니다. |
| `Aurora_pq_request_not_chosen_column_bit` | 예상 열 목록에서 지원되지 않는 데이터 형식으로 인해 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_column_geometry` | 테이블에 `GEOMETRY` 데이터 형식의 열이 있기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. 이 제한 사항이 적용되지 않는 Aurora MySQL 버전에 대한 자세한 정보는 [Aurora MySQL 버전 3에 병렬 쿼리 클러스터 업그레이드](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2) 섹션을 참조하세요. |
| `Aurora_pq_request_not_chosen_column_lob` | 테이블에 `LOB` 데이터 형식의 열이 있거나 `VARCHAR` 선언된 길이로 인해 외부에 저장된 열이 있으므로에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. 이 제한 사항이 제거된 Aurora MySQL 버전에 대한 자세한 정보는 [Aurora MySQL 버전 3에 병렬 쿼리 클러스터 업그레이드](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2) 섹션을 참조하세요. |
| `Aurora_pq_request_not_chosen_column_virtual` | 테이블에 가상 열이 포함되어 있기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_custom_charset` | 테이블에 사용자 지정 문자 집합이 있는 열이 있기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_fast_ddl` | 테이블이 현재 빠른 DDL `ALTER` 문에 의해 변경되고 있기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | 테이블 데이터 중 95% 미만이 버퍼 풀에 있는 경우에도, 버퍼링되지 않은 테이블 데이터가 병렬 쿼리가 가치 있을 만큼 충분하지 않았기 때문에 병렬 쿼리가 선택되지 않은 횟수입니다. |
| `Aurora_pq_request_not_chosen_full_text_index` | 테이블에 전체 텍스트 인덱스가 있기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | 테이블 데이터 중 많은 양이(현재, 95% 이상) 이미 버퍼 풀에 있었기 때문에 병렬 쿼리가 선택되지 않은 횟수입니다. 이러한 경우, 옵티마이저는 버퍼 풀에서 데이터 읽기가 더 효율적이라고 결정합니다. 쿼리가 실제로 수행되지 않더라도 `EXPLAIN` 문을 통해 이 카운터가 증가할 수 있습니다. |
| `Aurora_pq_request_not_chosen_index_hint` | 쿼리에 인덱스 힌트가 포함되어 있기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_innodb_table_format` | 테이블이 지원되지 않는 InnoDB 행 형식을 사용하기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. Aurora 병렬 쿼리는 `COMPACT`, `REDUNDANT` 및 `DYNAMIC` 행 형식에만 적용됩니다. |
| `Aurora_pq_request_not_chosen_long_trx` | 장기 실행 트랜잭션 내부에서 쿼리가 시작되는 중이어서 비병렬 쿼리 처리 경로를 사용한 병렬 쿼리 요청의 수입니다. 쿼리가 실제로 수행되지 않더라도 `EXPLAIN` 문을 통해 이 카운터가 증가할 수 있습니다. |
| `Aurora_pq_request_not_chosen_no_where_clause` | 쿼리에 `WHERE` 절이 포함되어 있지 않기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_range_scan` | 쿼리가 인덱스에서 범위 스캔을 사용하기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_row_length_too_long` | 모든 열의 총 결합 길이가 너무 길기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_small_table` | 행의 수 및 평균 행 길이에 따라 결정된 테이블의 전체 크기로 인해 병렬 쿼리가 선택되지 않은 횟수입니다. 쿼리가 실제로 수행되지 않더라도 `EXPLAIN` 문을 통해 이 카운터가 증가할 수 있습니다. |
| `Aurora_pq_request_not_chosen_temporary_table` | 쿼리가 지원되지 않는 `MyISAM` 또는 `memory` 테이블 형식을 사용하는 임시 테이블을 참조하기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_tx_isolation` | 쿼리가 지원되지 않는 트랜잭션 격리 수준을 사용하기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. 읽기 전용 DB 인스턴스에서는 병렬 쿼리가 `REPEATABLE READ` 및 `READ COMMITTED` 격리 수준에만 적용됩니다. |
| `Aurora_pq_request_not_chosen_update_delete_stmts` | 쿼리가 `UPDATE` 또는 `DELETE` 문의 일부이기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. |
| `Aurora_pq_request_not_chosen_unsupported_access` | `WHERE` 절이 병렬 쿼리를 위한 기준에 부합되지 않기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청의 수입니다. 이 결과는 쿼리에 데이터 집약적인 스캔이 필요하지 않은 경우이거나 쿼리가 `DELETE` 또는 `UPDATE` 문인 경우에 발생할 수 있습니다. |
| `Aurora_pq_request_not_chosen_unsupported_storage_type` | Aurora MySQL DB 클러스터가 지원되는 Aurora 클러스터 스토리지 구성을 사용하지 않기 때문에 비병렬 쿼리 처리 경로를 사용하는 병렬 쿼리 요청 수입니다. 자세한 내용은 [제한 사항](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations) 섹션을 참조하세요. 이 파라미터는 Aurora MySQL 버전 3.04 이상에 적용됩니다. |
| `Aurora_pq_request_throttled` | 동시 병렬 쿼리의 최대 수가 이미 특정 Aurora DB 인스턴스에서 실행 중이기 때문에 병렬 쿼리가 선택되지 않은 횟수입니다. |
| `Aurora_repl_bytes_received` | 마지막 재시작 이후 Aurora MySQL 리더 데이터베이스 인스턴스에 복제된 바이트 수입니다. 자세한 내용은 [Amazon Aurora MySQL을 사용한 복제](AuroraMySQL.Replication.md) 섹션을 참조하세요. |
| `Aurora_reserved_mem_exceeded_incidents` | 마지막 재시작 이후 엔진이 예약된 메모리 제한을 초과한 횟수입니다. `aurora_oom_response`가 구성된 경우 이 임계값은 메모리 부족(OOM) 방지 활동이 트리거되는 시기를 정의합니다. Aurora MySQL OOM 응답에 대한 자세한 내용은 [Aurora MySQL 데이터베이스의 메모리 부족 문제 해결](AuroraMySQLOOM.md) 섹션을 참조하세요. |
| `aurora_temptable_max_ram_allocation` | 마지막 재시작 이후 내부 임시 테이블에서 사용하는 최대 메모리 양(바이트)입니다. |
| `aurora_temptable_ram_allocation` | 내부 임시 테이블에서 사용하는 현재 메모리 양(바이트)입니다. |
| `Aurora_in_memory_relaylog_status` | 메모리 릴레이 로그 기능에서의 현재 상태입니다. 값은 ENABLED 또는 DISABLED일 수 있습니다. |
| `Aurora_in_memory_relaylog_disabled_reason` | 메모리 릴레이 로그 기능 상태의 현재 이유를 표시합니다. 기능이 비활성화된 경우 기능이 비활성화된 이유에 대한 설명 메시지를 표시합니다. |
| `Aurora_in_memory_relaylog_fallback_count` | 메모리 내 릴레이 로그 기능의 총 폴백 수를 영구 릴레이 로그 모드(레거시)로 표시합니다. 단일 이벤트가 캐시 크기(현재 128MB)보다 크거나 트랜잭션 재시도가 복제본 트랜잭션 재시도 제한 replica\$1transaction\$1retries를 초과하면 폴백이 발생할 수 있습니다. |
| `Aurora_in_memory_relaylog_recovery_count` | 자동으로 수행되는 메모리 릴레이 로그 복구의 총수를 표시합니다. 이 수에는 총 폴백 수와 임시 폴백 후 메모리 릴레이 로그 모드에서 다시 전환되는 자동 모드 수가 포함됩니다. |
| `Aurora_thread_pool_thread_count` | Aurora 스레드 풀의 현재 스레드 수입니다. Aurora MySQL의 스레드 풀에 대한 자세한 내용은 [스레드 풀](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool) 섹션을 참조하세요. |
| `Aurora_tmz_version` | DB 클러스터에서 사용하는 시간대 정보의 현재 버전을 나타냅니다. 값은 인터넷 할당 번호 관리 기관(IANA) 형식인 `YYYYsuffix` 형식을 따릅니다(예: `2022a` 및 `2023c`). 이 파라미터는 Aurora MySQL 버전 2.12 이상 및 버전 3.04 이상에 적용됩니다. |
| `Aurora_zdr_oom_threshold` | 잠재적인 메모리 관련 문제에서 복구하기 위해 가동 중지 시간 제로 재시작(ZDR)을 시작하기 위한 Aurora DB 인스턴스의 메모리 임계값을 킬로바이트(KB)로 나타냅니다. |
| `server_aurora_das_running` | 이 DB 인스턴스에서 데이터베이스 활동 스트림(DAS)을 활성화했는지 아니면 비활성했는지를 나타냅니다. 자세한 내용은 [데이터베이스 활동 스트림을 사용하여 Amazon Aurora 모니터링](DBActivityStreams.md) 섹션을 참조하세요. |
## Aurora MySQL에 적용되지 않는 MySQL 상태 변수
Aurora MySQL과 MySQL 간의 아키텍처 차이 때문에 일부 MySQL 상태 변수는 Aurora MySQL에 적용되지 않습니다.
다음 MySQL 상태 변수는 Aurora MySQL에 적용되지 않습니다. 단, 이 목록이 전부는 아닙니다.
+ `innodb_buffer_pool_bytes_dirty`
+ `innodb_buffer_pool_pages_dirty`
+ `innodb_buffer_pool_pages_flushed`
Aurora MySQL 버전 3은 Aurora MySQL 버전 2에 있던 다음 상태 변수를 제거합니다.
+ `AuroraDb_lockmgr_bitmaps0_in_use`
+ `AuroraDb_lockmgr_bitmaps1_in_use`
+ `AuroraDb_lockmgr_bitmaps_mem_used`
+ `AuroraDb_thread_deadlocks`
+ `available_alter_table_log_entries`
+ `Aurora_lockmgr_memory_used`
+ `Aurora_missing_history_on_replica_incidents`
+ `Aurora_new_lock_manager_lock_release_cnt`
+ `Aurora_new_lock_manager_lock_release_total_duration_micro`
+ `Aurora_new_lock_manager_lock_timeout_cnt`
+ `Aurora_total_op_memory`
+ `Aurora_total_op_temp_space`
+ `Aurora_used_alter_table_log_entries`
+ `Aurora_using_new_lock_manager`
+ `Aurora_volume_bytes_allocated`
+ `Aurora_volume_bytes_left_extent`
+ `Aurora_volume_bytes_left_total`
+ `Com_alter_db_upgrade`
+ `Compression`
+ `External_threads_connected`
+ `Innodb_available_undo_logs`
+ `Last_query_cost`
+ `Last_query_partial_plans`
+ `Slave_heartbeat_period`
+ `Slave_last_heartbeat`
+ `Slave_received_heartbeats`
+ `Slave_retried_transactions`
+ `Slave_running`
+ `Time_since_zero_connections`
이러한 MySQL 상태 변수는 Aurora MySQL 버전 2에서 사용할 수 있지만 Aurora MySQL 버전 3에서는 사용할 수 없습니다.
+ `Innodb_redo_log_enabled`
+ `Innodb_undo_tablespaces_total`
+ `Innodb_undo_tablespaces_implicit`
+ `Innodb_undo_tablespaces_explicit`
+ `Innodb_undo_tablespaces_active`
# Aurora MySQL 대기 이벤트
다음은 Aurora MySQL의 일반 대기 이벤트입니다.
**참고**
대기 이벤트를 사용하여 Aurora MySQL 성능을 튜닝하는 방법에 대한 자세한 내용은 [대기 이벤트로 Aurora MySQL 튜닝](AuroraMySQL.Managing.Tuning.wait-events.md)을 참조하세요.
MySQL 대기 이벤트에 사용되는 이름 지정 규칙에 대한 자세한 내용은 MySQL 설명서의 [성능 스키마 장비 이름 지정 규칙](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html)을 참조하세요.
**cpu**
실행할 준비가 된 활성 연결 수는 vCPU 수보다 일관되게 많습니다. 자세한 내용은 [cpu](ams-waits.cpu.md) 섹션을 참조하세요.
**io/aurora\$1redo\$1log\$1flush**
세션은 Aurora 스토리지에 데이터를 유지하고 있습니다. 일반적으로 이 대기 이벤트는 Aurora MySQL의 쓰기 I/O 작업을 위한 것입니다. 자세한 내용은 [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) 섹션을 참조하세요.
**io/aurora\$1respond\$1to\$1client**
쿼리 처리가 완료되었으며 2.10.2 이상 2.10 버전, 2.09.3 이상 2.09 버전, 2.07.7 이상 2.07 버전과 같은 Aurora MySQL 버전에 대한 결과가 애플리케이션 클라이언트에 반환됩니다. DB 인스턴스 클래스의 네트워크 대역폭을 반환되는 결과 집합의 크기와 비교합니다. 또한 클라이언트측 응답 시간도 확인합니다. 클라이언트가 응답하지 않고 TCP 패킷을 처리할 수 없는 경우 패킷이 삭제되고 TCP가 재전송될 수 있습니다. 이러한 상황은 네트워크 대역폭에 부정적인 영향을 미칩니다. 2.10.2, 2.09.3 및 2.07.7 이전 버전에서는 이 대기 이벤트에 유휴 시간이 잘못 포함됩니다. 이 대기 시간이 눈에 띄게 표시되는 경우 데이터베이스를 튜닝하는 법을 알아보려면 [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) 섹션을 참조하세요.
**io/file/csv/data**
스레드는 쉼표로 구분된 값(CSV) 형식으로 테이블에 작성합니다. CSV 테이블 사용을 확인하세요. 일반적으로 이 이벤트는 테이블에서 `log_output`을 설정하는 중에 발생합니다.
**io/file/sql/binlog**
스레드는 디스크에 기록 중인 이진 로그(binlog) 파일에서 대기 중입니다.
**io/redo\$1log\$1flush**
세션은 Aurora 스토리지에 데이터를 유지하고 있습니다. 일반적으로 이 대기 이벤트는 Aurora MySQL의 쓰기 I/O 작업을 위한 것입니다. 자세한 내용은 [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) 섹션을 참조하세요.
**io/socket/sql/client\$1connection**
`mysqld` 프로그램은 들어오는 새 클라이언트 연결을 처리하기 위해 스레드를 만드는 중입니다. 자세한 내용은 [io/socket/sql/client\$1connection](ams-waits.client-connection.md) 섹션을 참조하세요.
**io/table/sql/handler**
엔진이 테이블에 대한 액세스를 기다리고 있습니다. 이 이벤트는 데이터가 버퍼 풀에 캐시되는지 디스크에 액세스되는지 관계없이 발생합니다. 자세한 내용은 [io/table/sql/handler](ams-waits.waitio.md) 섹션을 참조하세요.
**lock/table/sql/handler**
이 대기 이벤트는 테이블 잠금 대기 이벤트 핸들러입니다. 성능 스키마의 atom 및 molecule 이벤트에 대한 자세한 내용은 MySQL 설명서의 [성능 스키마 Atom 및 Molecule 이벤트](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html)를 참조하세요.
**synch/cond/innodb/row\$1lock\$1wait**
여러 데이터 조작 언어(DML) 문이 동시에 동일한 데이터베이스 행에 액세스하고 있습니다. 자세한 내용은 [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md) 섹션을 참조하세요.
**synch/cond/innodb/row\$1lock\$1wait\$1cond**
여러 DML 문이 동시에 동일한 데이터베이스 행에 액세스하고 있습니다. 자세한 내용은 [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) 섹션을 참조하세요.
**synch/cond/sql/MDL\$1context::COND\$1wait\$1status**
스레드가 테이블 메타데이터 잠금을 기다리는 중입니다. 엔진이 이러한 유형의 잠금을 사용하여 데이터베이스 스키마에 대한 동시 액세스를 관리하고 데이터 일관성을 보장합니다. 자세한 내용은 MySQL 설명서의 [잠금 작업 최적화](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html)를 참조하세요. 이 이벤트가 눈에 띄게 표시되는 경우 데이터베이스를 튜닝하는 법을 알아보려면 [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) 섹션을 참조하세요.
**synch/cond/sql/MYSQL\$1BIN\$1LOG::COND\$1done**
이진 로깅을 설정했습니다. 높은 커밋 처리량, 많은 커밋 트랜잭션 또는 binlog를 읽는 복제본이 있을 수 있습니다. 다중 행 문을 사용하거나 명령문을 하나의 트랜잭션에 번들링하는 것이 좋습니다. Aurora에서는 이진 로그 복제 대신 글로벌 데이터베이스를 사용하거나 `aurora_binlog_*` 파라미터를 사용합니다.
**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**
여러 DML 문이 동시에 동일한 데이터베이스 행에 액세스하고 있습니다. 자세한 내용은 [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) 섹션을 참조하세요.
**synch/mutex/innodb/buf\$1pool\$1mutex**
버퍼 풀은 작업 중인 데이터 세트를 보유하기에 충분하지 않습니다. 또는 워크로드가 특정 테이블의 페이지에 액세스하여 버퍼 풀에서 경합이 발생합니다. 자세한 내용은 [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) 섹션을 참조하세요.
**synch/mutex/innodb/fil\$1system\$1mutex**
프로세스가 테이블스페이스 메모리 캐시에 대한 액세스를 기다리고 있습니다. 자세한 내용은 [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) 섹션을 참조하세요.
**synch/mutex/innodb/trx\$1sys\$1mutex**
작업은 일관되거나 제어된 방식으로 InnoDB의 트랜잭션 ID를 확인, 업데이트, 삭제 또는 추가하는 것입니다. 이러한 작업에는 성능 스키마 계측을 통해 추적되는 `trx_sys` 뮤텍스 호출이 필요합니다. 작업에는 데이터베이스가 시작하거나 종료할 때 트랜잭션 시스템 관리, 롤백, 실행 취소 정리, 행 읽기 액세스 및 버퍼 풀 로드 등이 포함됩니다. 많은 수의 트랜잭션을 통한 데이터베이스 로드가 많으면 이 대기 이벤트가 자주 표시됩니다. 자세한 내용은 [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) 섹션을 참조하세요.
**synch/mutex/mysys/KEY\$1CACHE::cache\$1lock**
`keycache->cache_lock` 뮤텍스는 MyISAM 테이블의 키 캐시에 대한 액세스를 제어합니다. Aurora MySQL에서는 영구 데이터를 저장하는 데는 MyISAM 테이블을 사용할 수 없지만 내부 임시 테이블을 저장하는 데는 사용됩니다. 특정 상황에서는 임시 테이블이 더 이상 메모리에 들어가지 않을 때 디스크에 기록되므로 `created_tmp_tables` 또는 `created_tmp_disk_tables` 상태 카운터를 확인하는 것이 좋습니다.
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1offsets**
엔진은 테이블 메타데이터 파일을 열거나 생성할 때 이 뮤텍스를 가져옵니다. 이 대기 이벤트가 과도한 빈도로 발생하면 생성되거나 열려 있는 테이블 수가 급증합니다.
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1shim\$1lists**
엔진은 열린 테이블을 추적하는 내부 구조에서 `reset_size`, `detach_contents` 또는 `add_contents`와 같은 작업을 수행하는 동안 이 뮤텍스를 가져옵니다. 뮤텍스는 목록 내용에 대한 액세스를 동기화합니다. 이 대기 이벤트가 높은 빈도로 발생하면 이전에 액세스한 테이블 집합이 갑자기 변경되었음을 나타냅니다. 엔진은 새 테이블에 액세스하거나 이전에 액세스한 테이블과 관련된 컨텍스트를 제거해야 합니다.
**synch/mutex/sql/LOCK\$1open**
세션에서 열리는 테이블 수가 테이블 정의 캐시 또는 테이블 열기 캐시의 크기를 초과합니다. 이러한 캐시의 크기를 늘립니다. 자세한 내용은 [MySQL에서 테이블을 열고 닫는 방법](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)을 참조하세요.
**synch/mutex/sql/LOCK\$1table\$1cache**
세션에서 열리는 테이블 수가 테이블 정의 캐시 또는 테이블 열기 캐시의 크기를 초과합니다. 이러한 캐시의 크기를 늘립니다. 자세한 내용은 [MySQL에서 테이블을 열고 닫는 방법](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)을 참조하세요.
**synch/mutex/sql/LOG**
이 대기 이벤트에서는 로그 잠금을 대기 중인 스레드가 있습니다. 예를 들어, 스레드가 느린 쿼리 로그에 쓰기 위해 잠금을 대기 중일 수 있습니다.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1commit**
이 대기 이벤트에서는 바이너리 로그에 커밋할 목적으로 잠금 획득을 대기 중인 스레드가 있습니다. 변경률이 매우 높은 데이터베이스에서 바이너리 로깅 경합이 발생할 수 있습니다. MySQL의 버전에 따라 바이너리 로그의 일관성과 내구성을 보호하기 위해 사용 중인 특정 잠금이 있습니다. RDS for MySQL에서는 복제 및 자동 백업 과정에 바이너리 로그가 사용됩니다. Aurora MySQL에서는 기본 복제 또는 백업에 바이너리 로그가 사용되지 않습니다. 바이너리 로그는 기본적으로 비활성화되지만, 활성화한 후 외부 복제 또는 변경 데이터 캡처에 사용할 수 있습니다. 자세한 내용은 MySQL 설명서의 [바이너리 로그](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)를 참조하십시오.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1dump\$1thread\$1metrics\$1collection**
이진 로깅이 설정되어 있으면 엔진은 활성 덤프 스레드 지표를 엔진 오류 로그와 내부 작업 맵에 인쇄할 때 이 뮤텍스를 가져옵니다.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1inactive\$1binlogs\$1map**
이진 로깅이 설정되어 있으면 엔진이 최신 파일 뒤에 있는 binlog 파일 목록을 통해 추가, 삭제 또는 검색할 때 이 뮤텍스를 가져옵니다.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1io\$1cache**
이진 로깅이 설정되어 있으면 Aurora binlog IO 캐시 작업(캐시 정보 할당, 크기 조정, 해제, 쓰기, 읽기, 제거 및 액세스) 중에 엔진이 이 뮤텍스를 획득합니다. 이 이벤트가 자주 발생하면 엔진은 binlog 이벤트가 저장되는 캐시에 액세스합니다. 대기 시간을 줄이려면 커밋을 줄이세요. 여러 명령문을 단일 트랜잭션으로 그룹화해 보세요.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1log**
이진 로깅을 설정했습니다. 높은 커밋 처리량, 많은 커밋 트랜잭션 또는 binlog를 읽는 복제본이 있을 수 있습니다. 다중 행 문을 사용하거나 명령문을 하나의 트랜잭션에 번들링하는 것이 좋습니다. Aurora에서는 이진 로그 복제 대신 글로벌 데이터베이스를 사용하거나 `aurora_binlog_*` 파라미터를 사용합니다.
**synch/mutex/sql/SERVER\$1THREAD::LOCK\$1sync**
파일 쓰기를 위해 스레드를 스케줄링, 처리 또는 시작하는 동안 `SERVER_THREAD::LOCK_sync` 뮤텍스를 가져옵니다. 이 대기 이벤트가 과도하게 발생하면 데이터베이스에서 쓰기 작업이 증가했다는 것을 나타냅니다.
**synch/mutex/sql/TABLESPACES:lock**
엔진이 다음과 같은 테이블스페이스 작업(생성, 삭제, 자르기 및 확장) 중에 `TABLESPACES:lock` 뮤텍스를 가져옵니다. 이 대기 이벤트가 과도하게 발생하면 테이블스페이스 작업의 빈도가 높다는 것을 나타냅니다. 예를 들어 대량의 데이터를 데이터베이스에 로드하는 것입니다.
**synch/rwlock/innodb/dict**
이 대기 이벤트에서는 InnoDB 데이터 딕셔너리에 보관된 rwlock을 대기 중인 스레드가 있습니다.
**synch/rwlock/innodb/dict\$1operation\$1lock**
이 대기 이벤트에서는 InnoDB 데이터 딕셔너리 작업에 대한 잠금을 보유한 스레드가 있습니다.
**synch/rwlock/innodb/dict sys RW lock**
데이터 정의 언어(DDL) 코드에서 많은 수의 동시 데이터 제어 언어(DCL) 문이 동시에 트리거됩니다. 정기적인 애플리케이션 작업 중에 DDL에 대한 애플리케이션의 종속성을 줄입니다.
**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**
많은 수의 비슷한 데이터 조작 언어(DML) 문이 동시에 동일한 데이터베이스 객체에 액세스하고 있습니다. 다중 행 문을 사용해 보세요. 또한 서로 다른 데이터베이스 객체에 워크로드를 분산하세요. 예를 들어 파티셔닝을 구현합니다.
**synch/sxlock/innodb/dict\$1operation\$1lock**
데이터 정의 언어(DDL) 코드에서 많은 수의 동시 데이터 제어 언어(DCL) 문이 동시에 트리거됩니다. 정기적인 애플리케이션 작업 중에 DDL에 대한 애플리케이션의 종속성을 줄입니다.
**synch/sxlock/innodb/dict\$1sys\$1lock**
데이터 정의 언어(DDL) 코드에서 많은 수의 동시 데이터 제어 언어(DCL) 문이 동시에 트리거됩니다. 정기적인 애플리케이션 작업 중에 DDL에 대한 애플리케이션의 종속성을 줄입니다.
**synch/sxlock/innodb/hash\$1table\$1locks**
세션이 버퍼 풀에서 페이지를 찾을 수 없습니다. 엔진은 파일을 읽거나 버퍼 풀의 LRU(least-recently used) 목록을 수정해야 합니다. 버퍼 캐시 크기를 늘리고 관련 쿼리에 대한 액세스 경로를 개선하는 것이 좋습니다.
**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**
많은 수의 비슷한 데이터 조작 언어(DML) 문이 동시에 동일한 데이터베이스 객체에 액세스하고 있습니다. 다중 행 문을 사용해 보세요. 또한 서로 다른 데이터베이스 객체에 워크로드를 분산하세요. 예를 들어 파티셔닝을 구현합니다.
**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**
이 대기 이벤트는 세션이 세션 임시 테이블스페이스 풀 관리를 위한 뮤텍스 획득을 기다리고 있을 때 발생합니다.
동기화 대기 이벤트 문제 해결에 대한 자세한 내용은 [MySQL DB 인스턴스가 Performance Insights에서 SYNCH 대기 이벤트를 기다리는 많은 활성 세션 수를 표시하는 이유는 무엇인가요?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/)를 참조하세요.
# Aurora MySQL 스레드 상태
다음은 Aurora MySQL의 일반 스레드 상태입니다.
**권한 확인**
스레드는 서버에 명령문을 실행하는 데 필요한 권한이 있는지 확인합니다.
**쿼리에 대한 쿼리 캐시 확인**
서버는 현재 쿼리가 쿼리 캐시에 있는지 확인합니다.
**정리**
이 상태는 작업이 완료되었지만 클라이언트에 의해 닫히지 않은 연결의 최종 상태입니다. 가장 좋은 해결책은 코드에서 연결을 명시적으로 닫는 것입니다. 또는 파라미터 그룹에서 `wait_timeout`에 대해 더 낮은 값을 설정할 수 있습니다.
**테이블 닫기**
스레드가 변경된 테이블 데이터를 디스크로 플러시하고 사용된 테이블을 닫습니다. 빠른 작업이 아닌 경우 인스턴스 클래스 네트워크 대역폭에 대해 네트워크 대역폭 사용 지표를 확인합니다. 또한 `table_open_cache` 및 `table_definition_cache`의 파라미터 값이 엔진이 테이블을 자주 열고 닫을 필요가 없도록 충분한 테이블을 동시에 열 수 있는지 확인합니다. 이러한 파라미터는 인스턴스의 메모리 사용에 영향을 줍니다.
**HEAP을 MyISAM으로 변환**
쿼리는 임시 테이블을 인메모리에서 온디스크로 변환하고 있습니다. 쿼리 처리의 중간 단계에서 MySQL에서 만든 임시 테이블이 메모리에 비해 너무 커지기 때문에 이러한 변환이 필요합니다. `tmp_table_size` 및 `max_heap_table_size`의 값을 확인합니다. 이후 버전에서는 이 스레드 상태 이름은 `converting HEAP to ondisk`입니다.
**HEAP을 온디스크로 변환**
스레드는 내부 임시 테이블을 인메모리 테이블에서 온디스크 테이블로 변환합니다.
**임시 테이블에 복사**
스레드가 `ALTER TABLE` 문을 처리 중입니다. 이 상태는 새 구조의 테이블이 작성된 후 행이 이 테이블로 복사되기 전에 발생합니다. 이 상태의 스레드의 경우 성능 스키마를 사용하여 복사 작업의 진행률에 대한 정보를 얻을 수 있습니다.
**정렬 인덱스 생성**
Aurora MySQL은 기존 인덱스를 사용하여 쿼리의 `ORDER BY` 또는 `GROUP BY` 절을 충족시킬 수 없기 때문에 정렬을 수행합니다. 자세한 내용은 [정렬 인덱스 생성](ams-states.sort-index.md) 단원을 참조하십시오.
**테이블 생성**
스레드가 영구 또는 임시 테이블을 생성 중입니다.
**지연된 커밋 확인 완료**
Aurora MySQL의 비동기 커밋이 승인을 받아 완료되었습니다.
**지연된 커밋 확인 시작**
Aurora MySQL 스레드는 비동기 커밋 프로세스를 시작했지만 승인을 기다리고 있습니다. 이 시간은 일반적으로 트랜잭션의 진정한 커밋 시간입니다.
**지연된 전송 확인 완료**
응답이 클라이언트에 전송되는 동안 연결된 Aurora MySQL 작업자 스레드를 해제할 수 있습니다. 스레드는 다른 작업을 시작할 수 있습니다. `delayed send ok` 상태는 클라이언트에 대한 비동기 승인이 완료되었음을 의미합니다.
**지연된 전송 확인 시작**
Aurora MySQL 작업자 스레드가 클라이언트에 비동기적으로 응답을 보냈으므로 이제 다른 연결에 대해 자유롭게 작업할 수 있습니다. 트랜잭션이 아직 승인되지 않은 비동기 커밋 프로세스를 시작했습니다.
**executing**
스레드가 명령문을 실행하기 시작했습니다.
**freeing items**
스레드가 명령을 실행했습니다. 이 상태에서 수행되는 항목의 일부 해제에는 쿼리 캐시가 포함됩니다. 이 상태는 일반적으로 정리됩니다.
**init**
이 상태는 `ALTER TABLE`, `DELETE`, `INSERT`, `SELECT` 또는 `UPDATE` 문의 초기화 전에 발생합니다. 이 상태의 작업에는 이진 로그 또는 InnoDB 로그의 플러시 및 쿼리 캐시의 일부 정리가 포함됩니다.
**소스가 모든 binlog를 복제본으로 전송했습니다. 더 많은 업데이트를 기다리고 있습니다.**
주 노드가 복제의 일부를 완료했습니다. 스레드는 이진 로그(binlog)에 쓸 수 있도록 더 많은 쿼리가 실행되기를 기다리고 있습니다.
**테이블 열기**
스레드가 테이블을 열려고 합니다. 이 작업은 `ALTER TABLE` 또는 `LOCK TABLE` 문이 `table_open_cache` 값을 완료해야 하거나 초과하지 않는 한 빠르게 수행됩니다.
**최적화**
서버가 쿼리에 대해 초기 최적화를 수행 중입니다.
**준비 중**
이 상태는 쿼리 최적화 중에 발생합니다.
**쿼리 종료**
이 상태는 쿼리 처리 후 항목 해제 상태 전에 발생합니다.
**중복 제거**
Aurora MySQL은 쿼리의 초기 단계에서 `DISTINCT` 작업을 최적화 할 수 없습니다. Aurora MySQL은 결과를 클라이언트에 보내기 전에 중복된 행을 모두 제거해야 합니다.
**업데이트를 위해 행 검색**
스레드는 업데이트하기 전에 일치하는 모든 행을 찾습니다. 이 단계는 `UPDATE`가 엔진이 행을 찾는 데 사용하는 인덱스를 변경하는 경우 필요합니다.
**binlog 이벤트를 슬레이브로 보내기**
스레드는 이진 로그에서 이벤트를 읽은 다음 복제본으로 보냅니다.
**캐시된 결과를 클라이언트로 보내기**
서버가 쿼리 캐시에서 쿼리 결과를 가져와 클라이언트로 보냅니다.
**데이터 전송**
스레드가 `SELECT` 문에 대한 행을 읽고 처리하고 있지만 아직 클라이언트로 데이터 전송을 시작하지 않았습니다. 이 프로세스는 쿼리를 충족하는 데 필요한 결과가 포함된 페이지를 식별하는 것입니다. 자세한 내용은 [데이터 전송](ams-states.sending-data.md) 단원을 참조하십시오.
**클라이언트로 전송**
서버가 클라이언트에 패킷을 쓰고 있습니다. 이전 MySQL 버전에서 이 대기 이벤트에 `writing to net`의 레이블이 지정되었습니다.
**starting**
이 단계는 명령문 실행 시작의 첫 번째 단계입니다.
**statistics**
서버는 쿼리 실행 계획을 개발하기 위해 통계를 계산하고 있습니다. 스레드가 오랫동안 이 상태인 경우 서버가 다른 작업을 수행하는 동안 디스크 바인딩될 수 있습니다.
**쿼리 캐시에 결과 저장**
서버가 쿼리 캐시에 쿼리 결과를 저장하고 있습니다.
**system lock**
스레드가 `mysql_lock_tables`를 호출했지만 호출 이후 스레드 상태가 업데이트되지 않았습니다. 이 일반적인 상태는 여러 가지 이유로 발생합니다.
**update**
스레드가 테이블 업데이트를 시작하기 위해 준비 중입니다.
**updating**
스레드가 행을 검색하고 업데이트하고 있습니다.
**user lock**
스레드가 `GET_LOCK` 호출을 실행했습니다. 스레드는 자문 잠금을 요청하고 기다리고 있거나 자문 잠금을 요청할 계획입니다.
**추가 업데이트 대기 중**
주 노드가 복제의 일부를 완료했습니다. 스레드는 이진 로그(binlog)에 쓸 수 있도록 더 많은 쿼리가 실행되기를 기다리고 있습니다.
**스키마 메타데이터 잠금 대기 중**
메타데이터 잠금을 기다리는 것입니다.
**저장된 함수 메타데이터 잠금 대기 중**
메타데이터 잠금을 기다리는 것입니다.
**저장된 프로시저 메타데이터 잠금 대기 중**
메타데이터 잠금을 기다리는 것입니다.
**테이블 플러시 대기 중**
스레드는 `FLUSH TABLES`를 실행 중이며 모든 스레드에서 해당 테이블을 닫을 때까지 대기하고 있습니다. 또는 스레드는 테이블의 기본 구조가 변경되었다는 알림을 받았으므로 테이블을 다시 열어 새 구조를 가져와야 합니다. 테이블을 다시 열려면 스레드는 다른 모든 스레드에서 테이블을 닫을 때까지 기다려야 합니다. 이 알림은 다른 스레드가 테이블에서 `FLUSH TABLES`, `ALTER TABLE`, `RENAME TABLE`, `REPAIR TABLE`, `ANALYZE TABLE` 또는 `OPTIMIZE TABLE` 문 중 하나를 사용한 경우 발생합니다.
**테이블 수준 잠금 대기 중**
한 세션은 테이블에서 잠금을 유지하는 반면 다른 세션은 동일한 테이블에서 동일한 잠금을 가져오려고 시도합니다.
**테이블 메타데이터 잠금 대기 중**
Aurora MySQL은 메타데이터 잠금을 사용하여 데이터베이스 객체에 대한 동시 액세스를 관리하고 데이터 일관성을 보장합니다. 이 대기 이벤트에서 한 세션은 테이블에서 메타데이터 잠금을 유지하는 반면 다른 세션은 동일한 테이블에서 동일한 잠금을 가져오려고 시도합니다. 성능 스키마가 사용 설정되면 이 스레드 상태는 `synch/cond/sql/MDL_context::COND_wait_status` 대기 이벤트로 보고됩니다.
**net에 쓰기**
서버가 네트워크에 패킷을 쓰고 있습니다. MySQL 이후 버전에서 이 대기 이벤트에 `Sending to client`의 레이블이 지정됩니다.
# Aurora MySQL 격리 수준
Aurora MySQL 클러스터의 DB 인스턴스가 격리의 데이터베이스 속성을 구현하는 방식을 알아봅니다. 이 주제에서는 Aurora MySQL 기본 동작이 엄격한 일관성과 높은 성능 사이에서 어떻게 균형을 이루는지 설명합니다. 이 정보를 사용하여 워크로드의 특성에 따라 언제 기본 설정을 변경할지 결정할 수 있습니다.
## 라이터 인스턴스에 사용 가능한 격리 수준
Aurora MySQL DB 클러스터의 기본 인스턴스에서 격리 수준 `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED` 및 `SERIALIZABLE`을 사용할 수 있습니다. 이러한 격리 수준은 RDS for MySQL과 마찬가지로 Aurora MySQL에서 동일하게 작동합니다.
## 리더 인스턴스의 REPEATABLE READ 격리 수준
기본적으로, 읽기 전용 Aurora 복제본으로 구성된 Aurora MySQL DB 인스턴스에서는 항상 `REPEATABLE READ` 격리 수준을 사용합니다. 이 DB 인스턴스에서는 `SET TRANSACTION ISOLATION LEVEL` 문은 모두 무시하고 계속해서 `REPEATABLE READ` 격리 수준을 사용합니다.
## 리더 인스턴스의 READ COMMITTED 격리 수준
애플리케이션에 기본 인스턴스의 쓰기 집약적인 워크로드와 Aurora 복제본의 장기 실행 쿼리가 포함된 경우 상당한 제거 지연 시간이 발생할 수 있습니다. *제거 지연 시간*은 내부 가비지 수집이 장기 실행 쿼리로 차단되는 경우 발생합니다. 사용자가 겪는 증상은 `history list length` 명령의 출력에서 `SHOW ENGINE INNODB STATUS`의 값이 커지는 것입니다. CloudWatch의 `RollbackSegmentHistoryListLength` 지표를 사용하여 이 값을 모니터링할 수 있습니다. 상당한 제거 지연은 보조 인덱스의 효율성과 전반적인 쿼리 성능을 저하하며 스토리지 공간 낭비로 이어질 수 있습니다.
이러한 문제가 발생하면 Aurora MySQL 세션 수준 구성 설정인 `aurora_read_replica_read_committed`를 Aurora 복제본에서 `READ COMMITTED` 격리 수준을 사용하도록 설정할 수 있습니다. 이 설정을 적용하면 장기 실행 쿼리를 테이블을 수정하는 트랜잭션과 동시에 수행하여 발생할 수 있는 속도 저하 및 공간 낭비를 줄이는 데 도움이 됩니다.
이 설정을 사용하기 전에 `READ COMMITTED` 격리의 특정 Aurora MySQL 동작을 이해하는 것이 좋습니다. Aurora 복제본 `READ COMMITTED` 동작은 ANSI SQL 표준을 준수합니다. 그러나 격리는 사용자에게 익숙한 일반적인 MySQL `READ COMMITTED` 동작보다 덜 엄격합니다. 따라서 Aurora MySQL 기본 인스턴스 또는 RDS for MySQL의 `READ COMMITTED`에서 실행한 동일 쿼리에 대한 결과와는 다른 쿼리 결과가 Aurora MySQL 읽기 전용 복제본의 `READ COMMITTED`에서 나올 수 있습니다. 매우 큰 데이터베이스를 스캔하는 종합 보고서와 같은 사례에서는 `aurora_read_replica_read_committed` 설정을 사용하는 것을 고려해 볼 수 있습니다. 반면에, 정밀도 및 반복성이 중요하고 결과 집합이 작은 짧은 쿼리에는 이 설정을 사용하지 않는 것이 좋습니다.
쓰기 전달 기능을 사용하는 Aurora Global Database의 보조 클러스터 내에 있는 세션에는 `READ COMMITTED` 격리 수준을 사용할 수 없습니다. 쓰기 전달에 대한 자세한 내용은 [Amazon Aurora 글로벌 데이터베이스에서 쓰기 전달 사용](aurora-global-database-write-forwarding.md) 단원을 참조하십시오.
### 리더에 대해 READ COMMITTED 사용
Aurora 복제본에 대해 `READ COMMITTED` 격리 수준을 사용하려면 `aurora_read_replica_read_committed` 구성 설정을 `ON`으로 설정합니다. 특정 Aurora 복제본에 연결된 상태에서 이 설정을 세션 수준에서 사용합니다. 이렇게 하려면 다음 SQL 명령을 실행합니다.
```
set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;
```
이 구성 설정을 일시적으로 사용하여 대화형 일회성 쿼리를 수행할 수 있습니다. 또한 다른 애플리케이션에 대한 기본 설정을 변경하지 않은 상태에서 `READ COMMITTED` 격리 수준에서 이점을 얻는 보고 또는 데이터 분석 애플리케이션을 실행할 수 있습니다.
`aurora_read_replica_read_committed` 설정이 활성화된 경우 `SET TRANSACTION ISOLATION LEVEL` 명령을 사용하여 적절한 트랜잭션에 격리 수준을 지정하세요.
```
set transaction isolation level read committed;
```
### Aurora 복제본에서 READ COMMITTED 동작의 차이
`aurora_read_replica_read_committed` 설정을 통해 Aurora 복제본에 대해 `READ COMMITTED` 격리 수준을 사용할 수 있게 할 수 있습니다. 이때 일관성 동작은 장기 실행 트랜잭션에 최적화됩니다. Aurora 복제본의 `READ COMMITTED` 격리 수준은 Aurora 기본 인스턴스보다 격리가 덜 엄격합니다. 이러한 이유로 쿼리에서 일관성 없는 특정 유형의 결과가 반환될 가능성을 수용할 수 있음을 사용자가 알고 있는 Aurora 복제본에서만 이 설정을 활성화해야 합니다.
`aurora_read_replica_read_committed` 설정이 켜져 있으면 쿼리 시 특정한 종류의 읽기 이상이 발생할 수 있습니다. 두 가지 종류의 이상이 애플리케이션 코드를 이해하고 애플리케이션 코드에서 처리하는 데 특히 중요합니다. *반복 불가능한 읽기*는 쿼리가 실행 중일 때 다른 트랜잭션이 커밋되면 발생합니다. 장기 실행 쿼리에는 종료 시 반환되는 것과 다른 데이터가 쿼리 시작 시점에 반환될 수 있습니다. *가상 읽기*는 쿼리가 실행 중일 때 다른 트랜잭션으로 인해 기존 행이 재편되고 쿼리에서 하나 이상의 행을 두 번 읽으면 발생합니다.
가상 읽기의 결과로 쿼리에서 행 수의 일관성이 결여될 수 있습니다. 또한 반복 불가능한 읽기로 인해 쿼리에서 불완전하거나 일관성 없는 결과를 반환할 수 있습니다. 예를 들어 `INSERT` 또는 `DELETE`와 같은 SQL 문에서 동시에 수정하는 테이블을 조인 연산자가 참조한다고 가정합시다. 이 경우 조인 쿼리에서는 테이블 하나에서 행 하나를 읽지만 다른 테이블에서 이에 상응하는 행은 읽지 않을 수 있습니다.
ANSI SQL 표준에서는 `READ COMMITTED` 격리 수준에 대해 이 두 가지 동작을 모두 허용합니다. 그러나 그러한 동작은 `READ COMMITTED`의 일반적인 MySQL 구현과 다릅니다. 따라서 `aurora_read_replica_read_committed` 설정을 활성화하기 전에 모든 기존 SQL 코드를 확인하여 이 코드가 더 느슨한 일관성 모델에서 예상대로 작동하는지 확인하십시오.
이 설정이 활성화되어 있는 상태에서 행 수 및 기타 결과는 `READ COMMITTED` 격리 수준에서 강한 일관성을 보이지 않을 수 있습니다. 따라서 대량 데이터를 집계하고 절대적인 정밀성이 필요하지 않은 분석 쿼리를 실행 중일 때만 일반적으로 이 설정을 활성화합니다. 이러한 종류의 장기 실행 쿼리와 함께 쓰기 집약적인 워크로드가 없는 경우에는 `aurora_read_replica_read_committed` 설정이 필요 없을 수 있습니다. 장기 실행 쿼리와 쓰기 집약적인 워크로드의 조합이 없으면 기록 목록 길이와 관련된 문제를 겪지 않을 가능성이 높습니다.
**Example Aurora 복제본에서 READ COMMITTED에 대해 격리 동작을 보여주는 쿼리**
다음 예시는 트랜잭션에서 연결된 테이블을 동시에 수정하는 경우 Aurora 복제본의 `READ COMMITTED` 쿼리에서 반복 불가능한 결과를 반환하는 방식을 보여줍니다. 쿼리 시작 전에 `BIG_TABLE` 테이블에는 1백만 개의 행이 포함되어 있습니다. 다른 데이터 조작 언어(DML) 문은 실행 중에 행을 추가, 제거 또는 변경합니다.
`READ COMMITTED` 격리 수준에서 Aurora 기본 인스턴스에 대한 쿼리를 통해 예측 가능한 결과가 산출됩니다. 그러나 모든 장기 실행 쿼리의 수명에 대해 일관성 있는 읽기 뷰를 유지하는 오버헤드로 인해 나중에 높은 가비지 수집 비용이 발생할 수 있습니다.
`READ COMMITTED` 격리 수준에서 Aurora 복제본에 대한 쿼리는 이러한 가비지 수집 오버헤드를 최소화도록 최적화됩니다. 하지만 쿼리가 실행 중일 때 커밋되는 트랜잭션에서 추가, 제거 또는 재편하는 행을 쿼리에서 가져오는지 여부에 따라 결과가 달라질 수 있다는 단점이 있습니다. 쿼리는 이러한 행을 고려하도록 허용될 뿐 반드시 고려해야 하는 것은 아닙니다. 데모용으로 쿼리에서는 `COUNT(*)` 함수를 사용해 테이블의 행 수만 확인합니다.
| 시간 | Aurora 기본 인스턴스의 DML 문 | READ COMMITTED로 Aurora 기본 인스턴스에 대해 쿼리 | READ COMMITTED로 Aurora 복제본에 대해 쿼리 |
| --- | --- | --- | --- |
| T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | |
| T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; |
| T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | |
| T4 | | Q1이 지금 완료되면 결과는 1,000,000입니다. | Q2가 지금 완료되면 결과는 1,000,000 또는 1,000,001입니다. |
| T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | |
| T6 | | Q1이 지금 완료되면 결과는 1,000,000입니다. | Q2가 지금 완료되면 결과는 1,000,000 또는 1,000,001 또는 999,999 또는 999,998입니다. |
| T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | |
| T8 | | Q1이 지금 완료되면 결과는 1,000,000입니다. | Q2가 지금 완료되면 결과는 1,000,000 또는 1,000,001 또는 999,999이거나 이보다 더 높은 수 일 수도 있습니다. |
| T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; |
| T10 | | Q3이 지금 완료되면 결과는 999,999입니다. | Q4가 지금 완료되면 결과는 999,999입니다. |
| T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; |
| T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | |
| T13 | | Q5가 지금 완료되면 결과는 0입니다. | Q6이 지금 완료되면 결과는 0 또는 1입니다. |
다른 트랜잭션에서 DML 문을 수행하고 커밋하기 전에 쿼리가 빠르게 완료되면 결과는 예측 가능하며 기본 인스턴스와 Aurora 복제본 간에 동일합니다. 첫 번째 쿼리부터 시작하여 동작의 차이점을 자세히 살펴보겠습니다.
기본 인스턴스의 `READ COMMITTED`에서는 `REPEATABLE READ` 격리 수준과 유사한 강력한 일관성 모델을 사용하므로 Q1에 대한 결과는 예측 가능성이 매우 높습니다.
Q2에 대한 결과는 쿼리가 실행 중일 때 어떤 트랜잭션이 커밋되는가에 따라 달라질 수 있습니다. 예를 들어 쿼리가 실행 중일 때 다른 트랜잭션에서 DML 문을 수행하고 커밋한다고 가정합시다. 이 경우 격리 수준이 `READ COMMITTED`인 Aurora 복제본에 대한 쿼리에서는 이러한 변경 사항을 고려할 수도 하지 않을 수도 있습니다. 행 수는 `REPEATABLE READ` 격리 수준과 마찬가지로 예측할 수 없습니다. 또한 행 수를 기본 인스턴스 또는 RDS for MySQL 인스턴스의 `READ COMMITTED` 격리 수준에서 실행 중인 쿼리와 같은 수준으로 예측할 수는 없습니다.
T7의 `UPDATE` 문은 실제로 테이블의 행 수를 변경하지 않습니다. 그러나 이 문은 변수 길이 열의 길이를 변경함으로써 행이 내부적으로 재편되게 할 수 있습니다. 장기 실행 `READ COMMITTED` 트랜잭션에서는 행의 이전 버전이 생길 수 있고, 나중에 동일 쿼리 내에서는 동일 행의 새로운 버전이 생길 수 있습니다. 또한 쿼리는 행의 이전 버전과 새 버전을 모두 건너뛸 수 있으므로 행의 수가 예상과 다를 수 있습니다.
Q5 및 Q6의 결과는 서로 같거나 약간 다를 수 있습니다. `READ COMMITTED`에서 Aurora 복제본에 대한 쿼리 Q6에서는 쿼리가 실행 중일 때 커밋된 새 행이 반환될 수 있지만 반드시 반환되어야 하는 것은 아닙니다. 또한 테이블 하나에서 해당 행을 반환할 수 있지만 다른 테이블에서는 반환하지 않을 수 있습니다. 조인 쿼리가 두 테이블에서 일치하는 행을 찾지 못하는 경우 0이라는 수를 반환합니다. 이 쿼리가 `PARENT_TABLE` 및 `CHILD_TABLE` 모두에서 새 행을 찾지 못하면 쿼리는 1이라는 수를 반환합니다. 장기 실행 쿼리에서는 조인된 테이블에서의 조회는 간격이 크게 벌어진 여러 시점에 발생할 수 있습니다.
동작의 이러한 차이는 트랜잭션이 커밋되는 시점과 쿼리에서 기본 테이블 행을 처리하는 시점에 따라 달라집니다. 따라서 몇 분 또는 몇 시간이 걸리고 OLTP 트랜잭션을 동시에 처리하는 Aurora 클러스터에서 실행되는 보고서 쿼리에서 이러한 차이가 반환될 가능성이 높습니다. 이것은 Aurora 복제본의 `READ COMMITTED` 격리 수준에서 가장 큰 이익을 얻는 혼합 워크로드 유형입니다.
# Aurora MySQL 힌트
Aurora MySQL 쿼리와 함께 SQL 힌트를 사용하여 성능을 미세 조정할 수 있습니다. 또한 힌트를 사용하여 예기치 않은 조건으로 인해 중요한 쿼리에 대한 실행 계획이 변경되는 것을 방지할 수 있습니다.
**작은 정보**
힌트가 쿼리에 미치는 영향을 확인하려면 `EXPLAIN` 문에서 생성된 쿼리 계획을 검토합니다. 힌트가 있는 쿼리 계획과 없는 쿼리 계획을 비교합니다.
Aurora MySQL 버전 3에서는 MySQL Community Edition 8.0에서 사용 가능한 모든 힌트를 사용할 수 있습니다. 이러한 힌트에 대한 자세한 내용은 *MySQL 참조 설명서*의 [최적화 프로그램 힌트](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)를 참조하세요.
다음 힌트는 Aurora MySQL 버전 2에서 사용할 수 있습니다. 이러한 힌트는 Aurora MySQL 버전 2의 해시 조인 기능을 사용하는 쿼리, 특히 병렬 쿼리 최적화를 사용하는 쿼리에 적용됩니다.
**PQ, NO\$1PQ**
최적화 프로그램이 테이블별 또는 쿼리별로 병렬 쿼리를 사용하도록 할지 여부를 지정합니다.
`PQ`는 최적화 프로그램이 지정된 테이블 또는 전체 쿼리(블록)에 대해 병렬 쿼리를 사용하도록 합니다. `NO_PQ`는 최적화 프로그램이 지정된 테이블 또는 전체 쿼리(블록)에 대해 병렬 쿼리를 사용하지 못하도록 합니다.
이 힌트는 Aurora MySQL 버전 2.11 이상에서 사용할 수 있습니다. 다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다.
테이블 이름을 지정하면 최적화 프로그램은 이러한 선별된 테이블에만 `PQ/NO_PQ` 힌트를 적용합니다. 테이블 이름을 지정하지 않으면 쿼리 블록의 영향을 받는 모든 테이블에 `PQ/NO_PQ` 힌트가 적용됩니다.
```
EXPLAIN SELECT /*+ PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
EXPLAIN SELECT /*+ NO_PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
```
**HASH\$1JOIN, NO\$1HASH\$1JOIN**
쿼리에 해시 조인 최적화 방법을 사용할지 여부를 선택할 수 있는 병렬 쿼리 최적화 프로그램의 기능을 설정하거나 해제합니다. `HASH_JOIN`을 사용하면 해당 메커니즘이 더 효율적인 경우 최적화 프로그램이 해시 조인을 사용할 수 있습니다. `NO_HASH_JOIN`은 최적화 프로그램이 쿼리에 해시 조인을 사용하지 못하게 합니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다. Aurora MySQL 버전 3에서는 아무런 효과가 없습니다.
다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다.
```
EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1PROBING, NO\$1HASH\$1JOIN\$1PROBING**
해시 조인 쿼리에서 조인의 프로브 측에 지정된 테이블을 사용할지를 지정합니다. 쿼리는 프로브 테이블의 전체 내용을 읽는 대신 빌드 테이블의 열 값이 프로브 테이블에 있는지를 테스트합니다. `HASH_JOIN_PROBING` 및 `HASH_JOIN_BUILDING`을 사용하여 쿼리 텍스트 내에서 테이블을 재정렬하지 않고 해시 조인 쿼리가 처리되는 방법을 지정할 수 있습니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다. Aurora MySQL 버전 3에서는 아무런 효과가 없습니다.
다음 예제에서는 이 힌트를 사용하는 방법을 보여 줍니다. `HASH_JOIN_PROBING` 테이블에 `T2` 힌트를 지정하면 `NO_HASH_JOIN_PROBING` 테이블에 `T1`을 지정하는 것과 같은 효과가 있습니다.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1BUILDING, NO\$1HASH\$1JOIN\$1BUILDING**
해시 조인 쿼리에서 조인의 빌드 측에 지정된 테이블을 사용할지를 지정합니다. 쿼리는 이 테이블의 모든 행을 처리하여 다른 테이블과 상호 참조할 열 값 목록을 작성합니다. `HASH_JOIN_PROBING` 및 `HASH_JOIN_BUILDING`을 사용하여 쿼리 텍스트 내에서 테이블을 재정렬하지 않고 해시 조인 쿼리가 처리되는 방법을 지정할 수 있습니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다. Aurora MySQL 버전 3에서는 아무런 효과가 없습니다.
다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다. `HASH_JOIN_BUILDING` 테이블에 `T2` 힌트를 지정하면 `NO_HASH_JOIN_BUILDING` 테이블에 `T1`을 지정하는 것과 같은 효과가 있습니다.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**JOIN\$1FIXED\$1ORDER**
쿼리의 테이블이 쿼리에 나열된 순서에 따라 조인되도록 지정합니다. 이는 세 개 이상의 테이블을 포함하는 쿼리에 유용합니다. 이는 MySQL `STRAIGHT_JOIN` 힌트를 대체하기 위한 것이며, MySQL [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 힌트에 해당합니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다.
다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다.
```
EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1ORDER**
쿼리의 테이블에 대한 조인 순서를 지정합니다. 이는 세 개 이상의 테이블을 포함하는 쿼리에 유용합니다. 이는 MySQL [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 힌트에 해당합니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다.
다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다.
```
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1PREFIX**
조인 순서에서 먼저 넣을 테이블을 지정합니다. 이는 세 개 이상의 테이블을 포함하는 쿼리에 유용합니다. 이는 MySQL [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 힌트에 해당합니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다.
다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다.
```
EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1SUFFIX**
조인 순서에 마지막으로 넣을 테이블을 지정합니다. 이는 세 개 이상의 테이블을 포함하는 쿼리에 유용합니다. 이는 MySQL [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 힌트에 해당합니다. 이 힌트는 Aurora MySQL 버전 2.08 이상에서 사용할 수 있습니다.
다음 예시에서는 이 힌트를 사용하는 방법을 보여줍니다.
```
EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
해시 조인 쿼리 사용에 대한 자세한 내용은 [해시 조인을 사용하여 대규모 Aurora MySQL 조인 쿼리 최적화](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin) 단원을 참조하십시오.
# Aurora MySQL 저장 프로시저 참조
기본 제공 저장 프로시저를 호출하여 Aurora MySQL DB 클러스터를 관리할 수 있습니다.
**Topics**
+ [글로벌 상태 기록 수집 및 유지](mysql-stored-proc-gsh.md)
+ [이진수 로그(binlog) 복제 구성, 시작 및 중지](mysql-stored-proc-replicating.md)
+ [세션 또는 쿼리 종료](mysql-stored-proc-ending.md)
+ [GTID를 사용한 트랜잭션 복제](mysql-stored-proc-gtid.md)
+ [쿼리 로그 교체](mysql-stored-proc-logging.md)
+ [이진수 로그 구성 설정 및 표시](mysql-stored-proc-configuring.md)
# 글로벌 상태 기록 수집 및 유지
Amazon RDS는 시간에 따른 상태 변수 값의 스냅샷을 생성하고 이를 마지막 스냅샷 이후의 변경 사항과 함께 테이블에 쓰는 일련의 프로시저를 제공합니다. 이 인프라를 전역적 상태 이력이라고 합니다. 자세한 내용은 [전역적 상태 이력 관리](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)를 참조하세요.
다음 저장 프로시저는 전역적 상태 이력을 수집하고 유지하는 방법을 관리합니다.
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
전역적 상태 이력에 대해 요청 시 스냅샷을 생성합니다.
### 구문
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
전역적 상태 이력에서 생성한 스냅샷을 비활성화합니다.
### 구문
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
`mysql.global_status_history` 테이블 회전을 비활성화합니다.
### 구문
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
전역적 상태 이력을 활성화하여 `rds_set_gsh_collector`로 지정한 간격에 따라 기본 스냅샷을 생성합니다.
### 구문
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
`mysql.global_status_history` 테이블의 내용이 `rds_set_gsh_rotation`에서 설정한 주기에 따라 `mysql.global_status_history_old`로 회전되도록 회전을 활성화합니다.
### 구문
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
필요에 따라 `mysql.global_status_history` 테이블의 내용을 `mysql.global_status_history_old`로 로테이션합니다.
### 구문
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
전역적 상태 이력에서 생성하는 스냅샷 간격(분)을 지정합니다.
### 구문
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### 파라미터
*intervalPeriod*
스냅샷 주기(분)입니다. 기본값은 `5`입니다.
## mysql.rds\$1set\$1gsh\$1rotation
`mysql.global_status_history` 테이블의 로테이션 주기(일)을 지정합니다.
### 구문
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### 파라미터
*intervalPeriod*
테이블 로테이션 주기(일)입니다. 기본값은 `7`입니다.
# 이진수 로그(binlog) 복제 구성, 시작 및 중지
Aurora MySQL 클러스터에 있는 기본 인스턴스에 연결된 상태에서 다음과 같은 저장 프로시저를 호출할 수 있습니다. 이 프로시저에서는 트랜잭션이 외부 데이터베이스에서 Aurora MySQL로, 또는 Aurora MySQL에서 외부 데이터베이스로 복제되는 방식을 제어합니다.
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog(Aurora MySQL 버전 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog(Aurora MySQL 버전 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [vmysql.rds\$1next\$1master\$1log(Aurora MySQL 버전 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log(Aurora MySQL 버전 3)](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master(Aurora MySQL 버전 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source(Aurora MySQL 버전 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl(Aurora MySQL 버전 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master(Aurora MySQL 버전 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source(Aurora MySQL 버전 3)](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position(Aurora MySQL 버전 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position(Aurora MySQL 버전 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position(Aurora MySQL 버전 2)](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only(Aurora MySQL 버전 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format(Aurora MySQL 버전 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position(Aurora MySQL 버전 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 버전 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog(Aurora MySQL 버전 2)
`sql_log_bin` 변수를 `OFF`로 설정하여 현재 세션에 대한 이진 로깅을 끕니다.
### 구문
```
CALL mysql.rds_disable_session_binlog;
```
### 파라미터
없음
### 사용 노트
Aurora MySQL DB 클러스터의 경우, 기본 인스턴스에 연결된 상태에서 이 저장 프로시저를 호출합니다.
Aurora의 경우, 이 프로시저는 Aurora MySQL 버전 2.12 이상과 MySQL 5.7 호환 버전에서 지원됩니다.
**참고**
Aurora MySQL 버전 3에서는 `SESSION_VARIABLES_ADMIN` 권한이 있는 경우 다음 명령을 사용하여 현재 세션에 대한 바이너리 로깅을 비활성화할 수 있습니다.
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog(Aurora MySQL 버전 2)
`sql_log_bin` 변수를 `ON`으로 설정하여 현재 세션에 대한 이진 로깅을 켭니다.
### 구문
```
CALL mysql.rds_enable_session_binlog;
```
### 파라미터
없음
### 사용 노트
Aurora MySQL DB 클러스터의 경우, 기본 인스턴스에 연결된 상태에서 이 저장 프로시저를 호출합니다.
Aurora의 경우, 이 프로시저는 Aurora MySQL 버전 2.12 이상과 MySQL 5.7 호환 버전에서 지원됩니다.
**참고**
Aurora MySQL 버전 3에서는 `SESSION_VARIABLES_ADMIN` 권한이 있는 경우 다음 명령을 사용하여 현재 세션에 대한 바이너리 로깅을 활성화할 수 있습니다.
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
인증 기관(CA) 인증서, 클라이언트 인증서, 클라이언트 키를 Aurora MySQL DB 클러스터로 가져옵니다. SSL 통신과 암호화된 복제에 필요한 정보입니다.
**참고**
현재 이 프로시저는 Aurora MySQL 버전 2 중 2.09.2, 2.10.0, 2.10.1, 2.11.0 및 버전 3 중 3.01.1 이상에서 지원됩니다.
### 구문
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### 파라미터
*ssl\$1material*
MySQL 클라이언트를 위한 다음 .pem 형식 파일 내용이 포함된 JSON 페이로드.
+ "ssl\$1ca":"*Certificate authority certificate*"
+ "ssl\$1cert":"*Client certificate*"
+ "ssl\$1key":"*Client key*"
### 사용 노트
이 프로시저를 실행하기 전에 암호화된 복제를 준비합니다.
+ 외부 MySQL 소스 데이터베이스 인스턴스에서 SSL을 활성화하지 않았고 클라이언트 키와 클라이언트 인증서가 준비되지 않았다면, MySQL 데이터베이스 서버의 SSL을 활성화하고 필요한 클라이언트 키와 클라이언트 인증서를 생성합니다.
+ 외부 소스 데이터베이스 인스턴스에 SSL이 활성화되어 있으면 Aurora MySQL DB 클러스터에 클라이언트 키와 인증서를 제공합니다. 인증서와 키가 없다면, Aurora MySQL DB 클러스터에 대해 새 키와 인증서를 생성합니다. 클라이언트 인증서에 서명하려면, 외부 MySQL 소스 데이터베이스 인스턴스에 SSL을 구성할 때 사용하는 인증 기관(CA) 키가 있어야 합니다.
자세한 내용은 MySQL 설명서의 [openssl을 사용하여 SSL 인증서 및 키 생성](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html)을 참조하십시오.
**중요**
암호화된 복제를 준비한 후, SSL 연결을 사용해 이 프로시저를 실행합니다. 클라이언트 키를 보안성이 낮은 연결을 이용해 전송할 수 없습니다.
이 프로시저는 외부 MySQL 데이터베이스의 SSL 정보를 Aurora MySQL DB 클러스터로 가져옵니다. SSL 정보는 Aurora MySQL DB 클러스터에 대한 SSL 정보가 포함되어 있는 .pem 형식의 파일입니다. 암호화 복제 중, Aurora MySQL DB 클러스터는 MySQL 데이터베이스 서버의 클라이언트 역할을 합니다. Aurora MySQL 클라이언트 인증서와 키는 .pem 형식의 파일입니다.
이들 파일에서 올바른 JSON 페이로드의 `ssl_material` 파라미터로 정보를 복사할 수 있습니다. 암호화된 복제를 지원하려면 Aurora MySQL DB 클러스터로 이 SSL 정보를 가져옵니다.
JSON 페이로드는 다음 형식이어야 합니다.
```
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
```
### 예제
다음은 Aurora MySQL에 SSL 정보를 가져오는 예시입니다. .pem 형식 파일은 본문 코드의 길이가 일반적으로 예제의 본문 코드 길이보다 깁니다.
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
## vmysql.rds\$1next\$1master\$1log(Aurora MySQL 버전 2)
소스 데이터베이스 인스턴스 로그 위치를 소스 데이터베이스 인스턴스에서 다음 이진 로그의 시작으로 변경합니다. 읽기 전용 복제본에 대한 복제 I/O 오류 1236을 수신 중일 경우에만 이 프로시저를 사용하십시오.
### 구문
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### 파라미터
*curr\$1master\$1log*
현재 마스터 로그 파일의 인덱스입니다. 예를 들어, 현재 파일의 이름이 `mysql-bin-changelog.012345`이면 인덱스는 12345입니다. 현재 마스터 로그 파일 이름을 확인하려면 `SHOW REPLICA STATUS` 명령을 실행하고 `Master_Log_File` 필드를 봅니다.
### 사용 노트
마스터 사용자는 `mysql.rds_next_master_log` 프로시저를 실행해야 합니다.
**주의**
복제 원본인 다중 AZ DB 인스턴스의 장애 조치 후 복제가 실패하고 `mysql.rds_next_master_log`의 `Last_IO_Errno`필드에서 I/O 오류 1236을 보고하는 경우에만 `SHOW REPLICA STATUS`를 호출합니다.
장애 조치 이벤트가 발생하기 전에 원본 인스턴스의 트랜잭션이 디스크의 바이너리 로그에 기록되지 않은 경우 `mysql.rds_next_master_log`를 호출하면 읽기 전용 복제본에서 데이터가 손실될 수 있습니다.
### 예제
Aurora MySQL 읽기 전용 복제본에서 복제가 실패한다고 가정해 보겠습니다. 읽기 전용 복제본에서 `SHOW REPLICA STATUS\G`를 실행하면 다음 결과가 반환됩니다.
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
`Last_IO_Errno` 필드가 인스턴스에서 I/O 오류 1236을 수신하고 있음을 보여 줍니다. `Master_Log_File` 필드는 파일 이름이 `mysql-bin-changelog.012345`임을 보여 줍니다. 이는 로그 파일 인덱스가 `12345`임을 의미합니다. 오류를 해결하려면 다음 파라미터와 함께 `mysql.rds_next_master_log`를 호출합니다.
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log(Aurora MySQL 버전 3)
소스 데이터베이스 인스턴스 로그 위치를 소스 데이터베이스 인스턴스에서 다음 이진 로그의 시작으로 변경합니다. 읽기 전용 복제본에 대한 복제 I/O 오류 1236을 수신 중일 경우에만 이 프로시저를 사용하십시오.
### 구문
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### 파라미터
*curr\$1source\$1log*
현재 소스 로그 파일의 인덱스입니다. 예를 들어, 현재 파일의 이름이 `mysql-bin-changelog.012345`이면 인덱스는 12345입니다. 현재 소스 로그 파일 이름을 확인하려면 `SHOW REPLICA STATUS` 명령을 실행하고 `Source_Log_File` 필드를 봅니다.
### 사용 노트
관리 사용자는 `mysql.rds_next_source_log` 프로시저를 실행해야 합니다.
**주의**
복제 원본인 다중 AZ DB 인스턴스의 장애 조치 후 복제가 실패하고 `mysql.rds_next_source_log`의 `Last_IO_Errno`필드에서 I/O 오류 1236을 보고하는 경우에만 `SHOW REPLICA STATUS`를 호출합니다.
장애 조치 이벤트가 발생하기 전에 원본 인스턴스의 트랜잭션이 디스크의 바이너리 로그에 기록되지 않은 경우 `mysql.rds_next_source_log`를 호출하면 읽기 전용 복제본에서 데이터가 손실될 수 있습니다. 소스 인스턴스 파라미터 `innodb_support_xa` 및 `sync_binlog`를 `1`로 설정하여 이런 상황이 발생할 가능성을 줄일 수 있으나, 성능이 저하될 수 있습니다.
### 예제
Aurora MySQL 읽기 전용 복제본에서 복제가 실패한다고 가정해 보겠습니다. 읽기 전용 복제본에서 `SHOW REPLICA STATUS\G`를 실행하면 다음 결과가 반환됩니다.
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
`Last_IO_Errno` 필드가 인스턴스에서 I/O 오류 1236을 수신하고 있음을 보여 줍니다. `Source_Log_File` 필드는 파일 이름이 `mysql-bin-changelog.012345`임을 보여 줍니다. 이는 로그 파일 인덱스가 `12345`임을 의미합니다. 오류를 해결하려면 다음 파라미터와 함께 `mysql.rds_next_source_log`를 호출합니다.
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
SSL 통신과 암호화된 복제용 인증 기관(CA) 인증서, 클라이언트 인증서, 클라이언트 키를 제거합니다. [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)를 사용하여, 이 정보를 가져옵니다.
### 구문
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master(Aurora MySQL 버전 2)
이제 Aurora MySQL DB 인스턴스가 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본이 되지 않도록 다시 구성합니다.
**중요**
이 프로시저를 실행하려면 `autocommit`를 활성화해야 합니다. 활성화하려면 `autocommit` 파라미터를 `1`로 설정합니다. 파라미터 수정에 대한 자세한 정보는 [Amazon Aurora에서 DB 파라미터 그룹의 파라미터 수정](USER_WorkingWithParamGroups.Modifying.md) 섹션을 참조하십시오.
### 구문
```
CALL mysql.rds_reset_external_master;
```
### 사용 노트
마스터 사용자는 `mysql.rds_reset_external_master` 프로시저를 실행해야 합니다. 이 프로시저는 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본으로 제거되도록 MySQL DB 인스턴스에서 실행해야 합니다.
**참고**
이러한 저장 프로시저는 주로 Amazon RDS 외부에서 실행되는 MySQL 인스턴스를 사용하여 복제할 수 있도록 하기 위한 것입니다. 가능하면 Aurora 복제본을 사용하여 Aurora MySQL DB 클러스터 내에서 복제를 관리하는 것이 좋습니다. Aurora MySQL DB 클러스터의 복제 관리에 대한 자세한 내용은 [Aurora 복제본 사용](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas) 섹션을 참조하세요.
복제를 사용하여 Aurora MySQL 외부에서 실행 중인 MySQL 인스턴스에서 데이터를 가져오는 방법에 대한 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요.
## mysql.rds\$1reset\$1external\$1source(Aurora MySQL 버전 3)
이제 Aurora MySQL DB 인스턴스가 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본이 되지 않도록 다시 구성합니다.
**중요**
이 프로시저를 실행하려면 `autocommit`를 활성화해야 합니다. 활성화하려면 `autocommit` 파라미터를 `1`로 설정합니다. 파라미터 수정에 대한 자세한 정보는 [Amazon Aurora에서 DB 파라미터 그룹의 파라미터 수정](USER_WorkingWithParamGroups.Modifying.md) 섹션을 참조하십시오.
### 구문
```
CALL mysql.rds_reset_external_source;
```
### 사용 노트
관리 사용자는 `mysql.rds_reset_external_source` 프로시저를 실행해야 합니다. 이 프로시저는 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본으로 제거되도록 MySQL DB 인스턴스에서 실행해야 합니다.
**참고**
이러한 저장 프로시저는 주로 Amazon RDS 외부에서 실행되는 MySQL 인스턴스를 사용하여 복제할 수 있도록 하기 위한 것입니다. 가능하면 Aurora 복제본을 사용하여 Aurora MySQL DB 클러스터 내에서 복제를 관리하는 것이 좋습니다. Aurora MySQL DB 클러스터의 복제 관리에 대한 자세한 내용은 [Aurora 복제본 사용](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas) 섹션을 참조하세요.
## mysql.rds\$1set\$1binlog\$1source\$1ssl(Aurora MySQL 버전 3)
Binlog 복제를 위한 `SOURCE_SSL` 암호화를 활성화합니다. 자세한 내용은 MySQL 설명서의 [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)를 참조하세요.
### 구문
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### 파라미터
*mode*
`SOURCE_SSL` 암호화가 활성화되었는지를 나타내는 값입니다.
+ `0` - `SOURCE_SSL` 암호화가 비활성화되었습니다. 기본값은 `0`입니다.
+ `1` - `SOURCE_SSL` 암호화가 활성화었습니다. SSL 또는 TLS를 사용하여 암호화를 구성할 수 있습니다.
### 사용 노트
이 프로시저는 Aurora MySQL 버전 3.06 이상에서 지원됩니다.
## mysql.rds\$1set\$1external\$1master(Aurora MySQL 버전 2)
Aurora MySQL DB 인스턴스가 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본이 되도록 구성합니다.
`mysql.rds_set_external_master` 프로시저는 사용되지 않으며 향후 릴리스에서 삭제됩니다. 대신 `mysql.rds\$1set\$1external\$1source`을 사용하세요.
**중요**
이 프로시저를 실행하려면 `autocommit`를 활성화해야 합니다. 활성화하려면 `autocommit` 파라미터를 `1`로 설정합니다. 파라미터 수정에 대한 자세한 정보는 [Amazon Aurora에서 DB 파라미터 그룹의 파라미터 수정](USER_WorkingWithParamGroups.Modifying.md) 섹션을 참조하십시오.
### 구문
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### 파라미터
*host\$1name*
소스 데이터베이스 인스턴스가 될 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 호스트 이름 또는 IP 주소입니다.
*host\$1port*
소스 데이터베이스 인스턴스로 구성될 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스에서 사용하는 포트입니다. 네트워크 구성에 포트 번호를 변환하는 SSH 포트 복제가 포함되는 경우 SSH(Secure Shell)에 의해 공개되는 포트 이름을 지정하십시오.
*replication\$1user\$1name*
Amazon RDS 외부에서 실행 중인 MySQL 인스턴스에서 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 보유한 사용자의 ID입니다. 외부 인스턴스를 사용한 복제에만 사용되는 계정을 제공하는 것이 좋습니다.
*replication\$1user\$1password*
`replication_user_name`에 지정된 사용자 ID의 암호입니다.
*mysql\$1binary\$1log\$1file\$1name*
복제 정보를 포함하는 소스 데이터베이스 인스턴스의 이진 로그 이름입니다.
*mysql\$1binary\$1log\$1file\$1location*
복제 시 복제 정보를 읽기 시작하는 `mysql_binary_log_file_name` 이진수 로그 내 위치입니다.
소스 데이터베이스 인스턴스의 `SHOW MASTER STATUS`를 실행하여 binlog 파일 이름 및 위치를 확인할 수 있습니다.
*ssl\$1encryption*
복제 연결에 보안 소켓 계층(SSL) 암호화를 사용할지 여부를 지정하는 값입니다. 1은 SSL 암호화 사용, 0은 암호화 사용 안 함입니다. 기본값은 0입니다.
`MASTER_SSL_VERIFY_SERVER_CERT` 옵션은 지원되지 않습니다. 이 옵션은 0으로 설정되어 있는데, 이는 연결이 암호화되었지만 인증서는 확인되지 않았음을 의미합니다.
### 사용 노트
마스터 사용자는 `mysql.rds_set_external_master` 프로시저를 실행해야 합니다. 이 프로시저는 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본으로 구성되도록 MySQL DB 인스턴스에서 실행해야 합니다.
`mysql.rds_set_external_master`을 실행하기 전에 소스 데이터베이스 인스턴스가 되도록 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스를 구성해야 합니다. Amazon RDS 외부에서 실행하는 MySQL 인스턴스에 연결하려면 MySQL의 외부 인스턴스에서 `replication_user_name` 및 `replication_user_password` 권한이 있는 복제 사용자를 나타내는 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 값을 지정해야 합니다.
**MySQL의 외부 인스턴스를 소스 데이터베이스 인스턴스로 구성하려면**
1. 선택한 MySQL 클라이언트를 사용하여 MySQL의 외부 인스턴스에 연결하고 복제에 사용될 사용자 계정을 생성합니다. 다음은 예입니다.
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
1. MySQL의 외부 인스턴스에서 복제 사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다. 다음 예제에서는 도메인의 'repl\$1user' 사용자에게 모든 데이터베이스에 대한 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다.
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
암호화된 복제를 사용하려면 SSL 연결을 사용하도록 소스 데이터베이스 인스턴스를 구성합니다. 또한 [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) 프로시저를 사용하여 인증 기관(CA) 인증서, 클라이언트 인증서, 클라이언트 키를 DB 인스턴스나 DB 클러스터로 가져옵니다.
**참고**
이러한 저장 프로시저는 주로 Amazon RDS 외부에서 실행되는 MySQL 인스턴스를 사용하여 복제할 수 있도록 하기 위한 것입니다. 가능하면 Aurora 복제본을 사용하여 Aurora MySQL DB 클러스터 내에서 복제를 관리하는 것이 좋습니다. Aurora MySQL DB 클러스터의 복제 관리에 대한 자세한 내용은 [Aurora 복제본 사용](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas) 섹션을 참조하세요.
`mysql.rds_set_external_master`을 호출하여 Amazon RDS DB 인스턴스를 읽기 전용 복제본으로 구성한 후 읽기 전용 복제본에서 [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)을 호출하여 복제 프로세스를 시작할 수 있습니다. [mysql.rds\$1reset\$1external\$1master(Aurora MySQL 버전 2)](#mysql_rds_reset_external_master)를 호출하여 읽기 전용 복제본 구성을 제거할 수 있습니다.
`mysql.rds_set_external_master`를 호출하면 Amazon RDS는 `set master`의 시간, 사용자 및 작업을 `mysql.rds_history` 및 `mysql.rds_replication_status` 테이블에 기록합니다.
### 예제:
MySQL DB 인스턴스에서 다음 예제를 실행하면 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본이 되도록 DB 인스턴스가 구성됩니다.
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source(Aurora MySQL 버전 3)
Aurora MySQL DB 인스턴스가 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본이 되도록 구성합니다.
**중요**
이 프로시저를 실행하려면 `autocommit`를 활성화해야 합니다. 활성화하려면 `autocommit` 파라미터를 `1`로 설정합니다. 파라미터 수정에 대한 자세한 정보는 [Amazon Aurora에서 DB 파라미터 그룹의 파라미터 수정](USER_WorkingWithParamGroups.Modifying.md) 섹션을 참조하십시오.
### 구문
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### 파라미터
*host\$1name*
소스 데이터베이스 인스턴스가 될 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 호스트 이름 또는 IP 주소입니다.
*host\$1port*
소스 데이터베이스 인스턴스로 구성될 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스에서 사용하는 포트입니다. 네트워크 구성에 포트 번호를 변환하는 SSH 포트 복제가 포함되는 경우 SSH(Secure Shell)에 의해 공개되는 포트 이름을 지정하십시오.
*replication\$1user\$1name*
Amazon RDS 외부에서 실행 중인 MySQL 인스턴스에서 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 보유한 사용자의 ID입니다. 외부 인스턴스를 사용한 복제에만 사용되는 계정을 제공하는 것이 좋습니다.
*replication\$1user\$1password*
`replication_user_name`에 지정된 사용자 ID의 암호입니다.
*mysql\$1binary\$1log\$1file\$1name*
복제 정보를 포함하는 소스 데이터베이스 인스턴스의 이진 로그 이름입니다.
*mysql\$1binary\$1log\$1file\$1location*
복제 시 복제 정보를 읽기 시작하는 `mysql_binary_log_file_name` 이진수 로그 내 위치입니다.
소스 데이터베이스 인스턴스의 `SHOW MASTER STATUS`를 실행하여 binlog 파일 이름 및 위치를 확인할 수 있습니다.
*ssl\$1encryption*
복제 연결에 보안 소켓 계층(SSL) 암호화를 사용할지 여부를 지정하는 값입니다. 1은 SSL 암호화 사용, 0은 암호화 사용 안 함입니다. 기본값은 0입니다.
이 옵션을 활성화하려면 [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)을 사용하여 사용자 지정 SSL 인증서를 가져와야 합니다. 사용자 지정 SSL 인증서를 가져오지 않은 경우 이 파라미터를 0으로 설정하고 [mysql.rds\$1set\$1binlog\$1source\$1ssl(Aurora MySQL 버전 3)](#mysql_rds_set_binlog_source_ssl)을 사용하여 binlog 복제를 위한 SSL을 활성화하세요.
`SOURCE_SSL_VERIFY_SERVER_CERT` 옵션은 지원되지 않습니다. 이 옵션은 0으로 설정되어 있는데, 이는 연결이 암호화되었지만 인증서는 확인되지 않았음을 의미합니다.
### 사용 노트
관리 사용자는 `mysql.rds_set_external_source` 프로시저를 실행해야 합니다. 이 프로시저는 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본으로 구성되도록 Aurora MySQL DB 인스턴스에서 실행해야 합니다.
`mysql.rds_set_external_source`을 실행하기 전에 소스 데이터베이스 인스턴스가 되도록 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스를 구성해야 합니다. Amazon RDS 외부에서 실행하는 MySQL 인스턴스에 연결하려면 MySQL의 외부 인스턴스에서 `replication_user_name` 및 `replication_user_password` 권한이 있는 복제 사용자를 나타내는 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 값을 지정해야 합니다.
**MySQL의 외부 인스턴스를 소스 데이터베이스 인스턴스로 구성하려면**
1. 선택한 MySQL 클라이언트를 사용하여 MySQL의 외부 인스턴스에 연결하고 복제에 사용될 사용자 계정을 생성합니다. 다음은 예입니다.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
1. MySQL의 외부 인스턴스에서 복제 사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다. 다음 예제에서는 도메인의 'repl\$1user' 사용자에게 모든 데이터베이스에 대한 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
암호화된 복제를 사용하려면 SSL 연결을 사용하도록 소스 데이터베이스 인스턴스를 구성합니다. 또한 [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html) 프로시저를 사용하여 인증 기관(CA) 인증서, 클라이언트 인증서, 클라이언트 키를 DB 인스턴스나 DB 클러스터로 가져옵니다.
**참고**
이러한 저장 프로시저는 주로 Amazon RDS 외부에서 실행되는 MySQL 인스턴스를 사용하여 복제할 수 있도록 하기 위한 것입니다. 가능하면 Aurora 복제본을 사용하여 Aurora MySQL DB 클러스터 내에서 복제를 관리하는 것이 좋습니다. Aurora MySQL DB 클러스터의 복제 관리에 대한 자세한 내용은 [Aurora 복제본 사용](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas) 섹션을 참조하세요.
`mysql.rds_set_external_source`를 직접 호출하여 Aurora MySQL DB 인스턴스를 읽기 전용 복제본으로 구성한 후 읽기 전용 복제본에서 [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)을 직접 호출하여 복제 프로세스를 시작할 수 있습니다. [mysql.rds\$1reset\$1external\$1source(Aurora MySQL 버전 3)](#mysql_rds_reset_external_source)를 호출하여 읽기 전용 복제본 구성을 제거할 수 있습니다.
`mysql.rds_set_external_source`를 호출하면 Amazon RDS는 `set master`의 시간, 사용자 및 작업을 `mysql.rds_history` 및 `mysql.rds_replication_status` 테이블에 기록합니다.
### 예제
Aurora MySQL DB 인스턴스에서 실행할 경우 다음 예시는 Amazon RDS 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본이 되도록 DB 인스턴스를 구성합니다.
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position(Aurora MySQL 버전 2)
Aurora MySQL 기본 인스턴스가 외부 MySQL 인스턴스에서 수신되는 복제를 수락하도록 구성하십시오. 또한 이 절차에서는 전역 트랜잭션 식별자(GTID)를 기반으로 한 복제를 구성합니다.
Aurora MySQL은 지연된 복제를 지원하지 않기 때문에 이 프로시저는 지연된 복제를 구성하지 않습니다.
### 구문
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### 파라미터
*host\$1name*
복제 소스가 될 Aurora의 외부에서 실행 중인 MySQL 인스턴스의 호스트 이름 또는 IP 주소입니다.
*host\$1port*
복제 소스로 구성될 Aurora 외부에서 실행 중인 MySQL 인스턴스에서 사용하는 포트입니다. 네트워크 구성에 포트 번호를 변환하는 SSH 포트 복제가 포함되는 경우 SSH(Secure Shell)에 의해 공개되는 포트 이름을 지정하세요.
*replication\$1user\$1name*
Aurora 외부에서 실행하는 MySQL 인스턴스에서 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 보유한 사용자의 ID입니다. 외부 인스턴스를 사용한 복제에만 사용되는 계정을 제공하는 것이 좋습니다.
*replication\$1user\$1password*
`replication_user_name`에 지정된 사용자 ID의 암호입니다.
*ssl\$1encryption*
이 옵션은 현재 구현되지 않았습니다. 기본값은 0입니다.
### 사용 노트
Aurora MySQL DB 클러스터의 경우, 기본 인스턴스에 연결된 상태에서 이 저장 프로시저를 호출합니다.
마스터 사용자는 `mysql.rds_set_external_master_with_auto_position` 프로시저를 실행해야 합니다. 마스터 사용자는 복제 대상의 역할을 하는 Aurora MySQL DB 클러스터의 기본 인스턴스에서 이 절차를 실행합니다. 이것은 외부 MySQL DB 인스턴스 또는 Aurora MySQL DB 클러스터의 복제 대상이 될 수 있습니다.
이 프로시저는 Aurora MySQL 버전 2에서 지원됩니다. Aurora MySQL 버전 3의 경우 대신 [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position(Aurora MySQL 버전 3)](#mysql_rds_set_external_source_with_auto_position) 프로시저를 사용하세요.
`mysql.rds_set_external_master_with_auto_position`을 실행하기 전에 외부 MySQL DB 인스턴스가 복제 소스가 되도록 구성합니다. 외부 MySQL 인스턴스에 연결하려면 `replication_user_name` 및 `replication_user_password`의 값을 지정해야 합니다. 이러한 값은 외부 MySQL의 외부 인스턴스에 대해 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 가진 복제 사용자를 나타내야 합니다.
**외부 MySQL 인스턴스를 복제 소스로 구성하려면**
1. 선택한 MySQL 클라이언트를 사용하여 외부 MySQL 인스턴스에 연결하고 복제에 사용할 사용자 계정을 생성합니다. 다음은 예제입니다.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. 외부 MySQL 인스턴스의 경우 복제 사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다. 다음 예제에서는 도메인의 `REPLICATION CLIENT` 사용자에게 모든 데이터베이스에 대한 `REPLICATION SLAVE` 및 `'repl_user'` 권한을 부여합니다.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
`mysql.rds_set_external_master_with_auto_position`을 호출하면 Amazon RDS는 특정 정보를 기록합니다. 이 정보는 `"set master"` 및 `mysql.rds_history` 테이블에 있는 `mysql.rds_replication_status`의 시간, 사용자 및 작업입니다.
문제의 원인으로 알려진 특정 GTID 기반 트랜잭션을 건너뛰려면 [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL 버전 2 및 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) 저장 프로시저를 사용할 수 있습니다. GTID 기반 복제 작업에 대한 자세한 내용은 [GTID 기반 복제 사용](mysql-replication-gtid.md) 섹션을 참조하세요.
### 예제
Aurora 기본 인스턴스에서 다음 예제를 실행하면 Aurora 클러스터가 Aurora 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본의 역할을 하도록 구성됩니다.
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position(Aurora MySQL 버전 3)
Aurora MySQL 기본 인스턴스가 외부 MySQL 인스턴스에서 수신되는 복제를 수락하도록 구성하십시오. 또한 이 절차에서는 전역 트랜잭션 식별자(GTID)를 기반으로 한 복제를 구성합니다.
### 구문
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### 파라미터
*host\$1name*
복제 소스가 될 Aurora의 외부에서 실행 중인 MySQL 인스턴스의 호스트 이름 또는 IP 주소입니다.
*host\$1port*
복제 소스로 구성될 Aurora 외부에서 실행 중인 MySQL 인스턴스에서 사용하는 포트입니다. 네트워크 구성에 포트 번호를 변환하는 SSH 포트 복제가 포함되는 경우 SSH(Secure Shell)에 의해 공개되는 포트 이름을 지정하세요.
*replication\$1user\$1name*
Aurora 외부에서 실행하는 MySQL 인스턴스에서 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 보유한 사용자의 ID입니다. 외부 인스턴스를 사용한 복제에만 사용되는 계정을 제공하는 것이 좋습니다.
*replication\$1user\$1password*
`replication_user_name`에 지정된 사용자 ID의 암호입니다.
*ssl\$1encryption*
이 옵션은 현재 구현되지 않았습니다. 기본값은 0입니다.
Binlog를 복제하려면 [mysql.rds\$1set\$1binlog\$1source\$1ssl(Aurora MySQL 버전 3)](#mysql_rds_set_binlog_source_ssl)을 사용하여 SSL을 활성화합니다.
### 사용 노트
Aurora MySQL DB 클러스터의 경우, 기본 인스턴스에 연결된 상태에서 이 저장 프로시저를 호출합니다.
관리 사용자는 `mysql.rds_set_external_source_with_auto_position` 프로시저를 실행해야 합니다. 관리 사용자는 복제 대상의 역할을 하는 Aurora MySQL DB 클러스터의 기본 인스턴스에서 이 프로시저를 실행합니다. 이것은 외부 MySQL DB 인스턴스 또는 Aurora MySQL DB 클러스터의 복제 대상이 될 수 있습니다.
이 프로시저는 Aurora MySQL 버전 3에서 지원됩니다. Aurora MySQL은 지연된 복제를 지원하지 않기 때문에 이 프로시저는 지연된 복제를 구성하지 않습니다.
`mysql.rds_set_external_source_with_auto_position`을 실행하기 전에 외부 MySQL DB 인스턴스가 복제 소스가 되도록 구성합니다. 외부 MySQL 인스턴스에 연결하려면 `replication_user_name` 및 `replication_user_password`의 값을 지정해야 합니다. 이러한 값은 외부 MySQL의 외부 인스턴스에 대해 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 가진 복제 사용자를 나타내야 합니다.
**외부 MySQL 인스턴스를 복제 소스로 구성하려면**
1. 선택한 MySQL 클라이언트를 사용하여 외부 MySQL 인스턴스에 연결하고 복제에 사용할 사용자 계정을 생성합니다. 다음은 예제입니다.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. 외부 MySQL 인스턴스의 경우 복제 사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다. 다음 예제에서는 도메인의 `REPLICATION CLIENT` 사용자에게 모든 데이터베이스에 대한 `REPLICATION SLAVE` 및 `'repl_user'` 권한을 부여합니다.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
`mysql.rds_set_external_source_with_auto_position`을 호출하면 Amazon RDS는 특정 정보를 기록합니다. 이 정보는 `"set master"` 및 `mysql.rds_history` 테이블에 있는 `mysql.rds_replication_status`의 시간, 사용자 및 작업입니다.
문제의 원인으로 알려진 특정 GTID 기반 트랜잭션을 건너뛰려면 [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL 버전 2 및 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) 저장 프로시저를 사용할 수 있습니다. GTID 기반 복제 작업에 대한 자세한 내용은 [GTID 기반 복제 사용](mysql-replication-gtid.md) 섹션을 참조하세요.
### 예제
Aurora 기본 인스턴스에서 다음 예제를 실행하면 Aurora 클러스터가 Aurora 외부에서 실행 중인 MySQL 인스턴스의 읽기 전용 복제본의 역할을 하도록 구성됩니다.
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position(Aurora MySQL 버전 2)
복제 모드를 바이너리 로그 파일 위치 또는 전역 트랜잭션 식별자(GTID)를 기반으로 설정합니다.
### 구문
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### 파라미터
*auto\$1position\$1mode*
로그 파일 위치 복제 또는 GTID를 기반으로 하는 복제를 사용할지 여부를 나타내는 값:
+ `0` – 바이너리 로그 파일 위치를 기반으로 한 복제 방법을 사용합니다. 기본값은 `0`입니다.
+ `1` – GTID 기반 복제 방법을 사용합니다.
### 사용 노트
마스터 사용자는 `mysql.rds_set_master_auto_position` 프로시저를 실행해야 합니다.
이 프로시저는 Aurora MySQL 버전 2에서 지원됩니다.
## mysql.rds\$1set\$1read\$1only(Aurora MySQL 버전 3)
DB 인스턴스에 대해 전역적으로 `read_only` 모드를 활성화하거나 비활성화합니다.
### 구문
```
CALL mysql.rds_set_read_only(mode);
```
### 파라미터
*mode*
DB 인스턴스에 대해 `read_only` 모드가 전역적으로 활성화되었는지 또는 비활성화되었는지를 나타내는 값입니다.
+ `0` - `OFF`. 기본값은 `0`입니다.
+ `1` – `ON`
### 사용 노트
`mysql.rds_set_read_only` 저장 프로시저는 `read_only` 파라미터만 수정합니다. 리더 DB 인스턴스에서는 `innodb_read_only` 파라미터를 변경할 수 없습니다.
`read_only` 파라미터 변경 사항은 재부팅 후에는 지속되지 않습니다. `read_only`를 영구적으로 변경하려면 `read_only` DB 클러스터 파라미터를 사용해야 합니다.
이 프로시저는 Aurora MySQL 버전 3.06 이상에서 지원됩니다.
## mysql.rds\$1set\$1session\$1binlog\$1format(Aurora MySQL 버전 2)
현재 세션의 이진 로그 형식을 설정합니다.
### 구문
```
CALL mysql.rds_set_session_binlog_format(format);
```
### 파라미터
*형식*
현재 세션의 이진 로그 형식을 나타내는 값:
+ `STATEMENT` - 복제 소스가 SQL 명령문을 기반으로 이진 로그에 이벤트를 기록합니다.
+ `ROW` - 복제 소스가 개별 테이블 행의 변경을 나타내는 이벤트를 이진 로그에 기록합니다.
+ `MIXED` - 로깅이 일반적으로 SQL 명령문을 기반으로 하지만 특정 조건에서는 행으로 전환됩니다. 자세한 내용은 MySQL 설명서의 [혼합 이진 로깅 형식](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html)을 참조하세요.
### 사용 노트
Aurora MySQL DB 클러스터의 경우, 기본 인스턴스에 연결된 상태에서 이 저장 프로시저를 호출합니다.
이 저장 프로시저를 사용하려면 현재 세션에 대해 이진 로깅을 구성해야 합니다.
Aurora의 경우, 이 프로시저는 Aurora MySQL 버전 2.12 이상과 MySQL 5.7 호환 버전에서 지원됩니다.
## mysql.rds\$1set\$1source\$1auto\$1position(Aurora MySQL 버전 3)
복제 모드를 바이너리 로그 파일 위치 또는 전역 트랜잭션 식별자(GTID)를 기반으로 설정합니다.
### 구문
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### 파라미터
*auto\$1position\$1mode*
로그 파일 위치 복제 또는 GTID를 기반으로 하는 복제를 사용할지 여부를 나타내는 값:
+ `0` – 바이너리 로그 파일 위치를 기반으로 한 복제 방법을 사용합니다. 기본값은 `0`입니다.
+ `1` – GTID 기반 복제 방법을 사용합니다.
### 사용 노트
Aurora MySQL DB 클러스터의 경우, 기본 인스턴스에 연결된 상태에서 이 저장 프로시저를 호출합니다.
관리 사용자는 `mysql.rds_set_source_auto_position` 프로시저를 실행해야 합니다.
## mysql.rds\$1skip\$1repl\$1error
MySQL DB 읽기 전용 복제본의 복제 오류를 건너뛰고 삭제합니다.
### 구문
```
CALL mysql.rds_skip_repl_error;
```
### 사용 노트
마스터 사용자는 읽기 전용 복제본에서 `mysql.rds_skip_repl_error` 프로시저를 실행해야 합니다. 이 프로시저에 대한 자세한 내용은 [현재 복제 오류 넘어가기](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError)를 참조하세요.
오류가 있는지 여부를 판별하려면 MySQL `SHOW REPLICA STATUS\G` 명령을 실행합니다. 중대한 복제 오류가 아닌 경우 `mysql.rds_skip_repl_error`를 사용하여 오류를 건너뛸 수 있습니다. 오류가 여러 개인 경우 `mysql.rds_skip_repl_error`는 첫 번째 오류를 삭제한 후 다른 오류가 있음을 경고합니다. `SHOW REPLICA STATUS\G`를 사용하여 다음 오류에 대한 적합한 조치를 결정할 수 있습니다. 반환된 값에 대한 자세한 내용은 MySQL 설명서의 [SHOW SLAVE STATUS 문](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html)을 참조하세요.
Aurora MySQL의 복제 오류 해결에 대한 자세한 내용은 [MySQL 읽기 복제 오류 진단 및 해결](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR) 섹션을 참조하세요.
#### 복제 중지 오류
`mysql.rds_skip_repl_error` 프로시저를 호출할 때 복제본이 중단되었거나 사용 중지되었다는 오류 메시지가 표시될 수 있습니다.
읽기 전용 복제본 대신 기본 인스턴스에서 프로시저를 실행하면 이 오류 메시지가 나타납니다. 이 프로시저가 작동하려면 읽기 전용 복제본에서 이 프로시저를 실행해야 합니다.
이 오류 메시지는 읽기 전용 복제본에서 프로시저를 실행하지만 복제를 성공적으로 다시 시작할 수 없는 경우에도 나타날 수 있습니다.
많은 수의 오류를 건너뛰어야 하는 경우, 복제 지연이 바이너리 로그(binlog) 파일의 기본값 보관 기간 이상으로 늘어날 수 있습니다. 이 경우 binlog 파일이 읽기 전용 복제본에서 재생되기 전에 지워지기 때문에 치명적 오류가 발생할 수 있습니다. 이 제거는 복제를 중지시키며, 복제 오류를 건너뛰기 위해 더 이상 `mysql.rds_skip_repl_error` 명령을 호출할 수 없습니다.
이 문제는 소스 데이터베이스 인스턴스에서 binlog 파일이 보관되는 시간을 늘려서 완화할 수 있습니다. binlog 보관 시간을 늘린 후에 복제를 재시작하고 필요에 따라 `mysql.rds_skip_repl_error` 명령을 호출할 수 있습니다.
binlog 보관 기간을 설정하려면 [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) 프로시저를 사용하여 `'binlog retention hours'` 구성 파라미터와 DB 클러스터에 binlog 파일을 보관할 시간을 함께 지정하십시오. 다음 예제에서는 binlog 파일의 보관 기간을 48시간으로 설정합니다.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Aurora MySQL DB 클러스터에서 복제를 시작합니다.
**참고**
[mysql.rds\$1start\$1replication\$1until(Aurora MySQL 버전 3)](#mysql_rds_start_replication_until) 또는 [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL 버전 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) 저장 프로시저를 사용하여 Aurora MySQL DB 인스턴스에서 복제를 시작하고 지정된 바이너리 로그 파일 위치에서 복제를 중지할 수 있습니다.
### 구문
```
CALL mysql.rds_start_replication;
```
### 사용 노트
마스터 사용자는 `mysql.rds_start_replication` 프로시저를 실행해야 합니다.
Amazon RDS 외부에서 실행 중인 MySQL 인스턴스에서 데이터를 가져오려면 [mysql.rds\$1set\$1external\$1master(Aurora MySQL 버전 2)](#mysql_rds_set_external_master) 또는 [mysql.rds\$1set\$1external\$1source(Aurora MySQL 버전 3)](#mysql_rds_set_external_source)를 직접 호출하여 복제 구성을 빌드한 다음, 읽기 전용 복제본에서 `mysql.rds_start_replication`을 직접 호출하여 복제 프로세스를 시작합니다. 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요.
Amazon RDS 외부의 MySQL 인스턴스로 데이터를 내보내려면 읽기 전용 복제본에서 `mysql.rds_start_replication` 및 `mysql.rds_stop_replication`을 호출하여 바이너리 로그 삭제 등의 몇 가지 복제 작업을 제어합니다. 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요.
읽기 전용 복제본에서 `mysql.rds_start_replication`을 호출하여 이전에 `mysql.rds_stop_replication`을 호출하여 중지한 복제 프로세스를 재시작할 수도 있습니다. 자세한 내용은 [복제 중지 오류](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped) 섹션을 참조하세요.
## mysql.rds\$1start\$1replication\$1until(Aurora MySQL 버전 3)
Aurora MySQL DB 클러스터에서 복제를 시작하고 지정된 바이너리 로그 파일 위치에서 복제를 중지합니다.
### 구문
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### 파라미터
*replication\$1log\$1file*
복제 정보를 포함하는 소스 데이터베이스 인스턴스의 이진 로그 이름입니다.
*replication\$1stop\$1point *
복제를 중지할 `replication_log_file` 바이너리 로그 내 위치입니다.
### 사용 노트
마스터 사용자는 `mysql.rds_start_replication_until` 프로시저를 실행해야 합니다.
이 프로시저는 Aurora MySQL 버전 3.04 이상에서 지원됩니다.
`mysql.rds_start_replication_until` 저장 프로시저는 다음을 포함하는 관리형 복제에 지원되지 않습니다.
+ [여러 AWS 리전에 걸쳐 Amazon Aurora MySQL DB 클러스터 복제](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora 읽기 전용 복제본을 사용하여 RDS for MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
`replication_log_file` 파라미터에 지정된 파일 이름은 소스 데이터베이스 인스턴스 binlog 파일 이름과 일치해야 합니다.
`replication_stop_point` 파라미터가 과거에 해당하는 중지 위치를 지정하는 경우 복제가 즉시 중지됩니다.
### 예제
다음 예에서는 복제를 시작하고 `120` 바이너리 로그 파일의 `mysql-bin-changelog.000777` 위치에 도달할 때까지 변경 사항을 복제합니다.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
MySQL DB 인스턴스에서 복제를 중지합니다.
### 구문
```
CALL mysql.rds_stop_replication;
```
### 사용 노트
마스터 사용자는 `mysql.rds_stop_replication` 프로시저를 실행해야 합니다.
Amazon RDS 외부에서 실행 중인 MySQL 인스턴스에서 데이터를 가져오도록 복제를 구성하는 경우 가져오기가 완료된 후 읽기 전용 복제본에서 `mysql.rds_stop_replication`을 호출하여 복제 프로세스를 중지합니다. 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요.
Amazon RDS 외부의 MySQL 인스턴스로 데이터를 내보내도록 복제를 구성할 경우 읽기 전용 복제본에서 `mysql.rds_start_replication` 및 `mysql.rds_stop_replication`을 호출하여 이진 로그 삭제 등의 몇 가지 복제 작업을 제어합니다. 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요.
`mysql.rds_stop_replication` 저장 프로시저는 다음을 포함하는 관리형 복제에 지원되지 않습니다.
+ [여러 AWS 리전에 걸쳐 Amazon Aurora MySQL DB 클러스터 복제](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora 읽기 전용 복제본을 사용하여 RDS for MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# 세션 또는 쿼리 종료
다음 저장 프로시저는 세션 또는 쿼리를 종료합니다.
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
MySQL Server와의 연결을 종료합니다.
### 구문
```
CALL mysql.rds_kill(processID);
```
### 파라미터
*processID*
종료할 연결 스레드의 ID입니다.
### 사용 노트
MySQL Server에 대한 각 연결은 별개의 스레드로 실행됩니다. 연결을 종료하려면 `mysql.rds_kill` 프로시저를 사용하여 해당 연결의 스레드 ID를 전달합니다. 스레드 ID를 확인하려면 MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) 명령을 사용합니다.
### 예시
다음 예제는 스레드 ID가 4243인 연결을 종료합니다.
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
MySQL Server에서 실행 중인 쿼리를 종료합니다.
### 구문
```
CALL mysql.rds_kill_query(processID);
```
### 파라미터
*processID*
종료할 쿼리를 실행 중인 프로세스 또는 스레드의 ID입니다.
### 사용 노트
MySQL Server에서 실행 중인 쿼리를 중지하려면 `mysql_rds_kill_query` 프로시저를 사용하여 해당 쿼리를 실행 중인 스레드의 연결 ID를 전달합니다. 그러면 프로시저가 연결을 종료합니다.
ID를 확인하려면 MySQL [INFORMATION\$1SCHEMA PROCESSLIST 테이블](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html)을 쿼리하거나 MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) 명령을 사용합니다. `SHOW PROCESSLIST` 또는 `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST`에서 가져온 ID 열의 값은 *processID*입니다.
### 예시
다음 예시는 쿼리 스레드 ID가 230040인 쿼리를 중지합니다.
```
CALL mysql.rds_kill_query(230040);
```
# GTID를 사용한 트랜잭션 복제
다음 저장 프로시저는 Aurora MySQL에서 전역 트랜잭션 식별자(GTID)를 사용하여 트랜잭션을 복제하는 방법을 제어합니다. Aurora MySQL에서 GTID 기반 복제를 사용하는 방법을 알아보려면 [GTID 기반 복제 사용](mysql-replication-gtid.md) 섹션을 참조하세요.
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions(Aurora MySQL 버전 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged(Aurora MySQL 버전 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL 버전 2 및 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL 버전 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions(Aurora MySQL 버전 3)
`CHANGE REPLICATION SOURCE TO` 문의 `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` 옵션을 구성합니다. 이렇게 하면 복제 채널에서 GTID를 가지고 있지 않은 복제된 트랜잭션에 GTID를 할당합니다. 이렇게 하면 GTID 기반 복제를 사용하지 않는 소스에서 GTID 기반 복제를 사용하는 복제본으로 바이너리 로그 복제를 수행할 수 있습니다. 자세한 내용은 *MySQL 참조 설명서*의 [복제 소스를 명령문으로 변경](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) 및 [GTID를 사용하지 않는 소스에서 GTID를 사용하는 복제본으로 복제](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html)를 참조하세요.
### 구문
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### 파라미터
*gtid\$1option*
문자열 값입니다. 허용 값은 `OFF`, `LOCAL` 또는 지정된 UUID입니다.
### 사용 노트
이 프로시저에는 커뮤니티 MySQL에서 `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` 문을 실행하는 것과 동일한 효과가 있습니다.
GTID는 *gtid\$1option*에 대한 `ON`로 튜닝되어 `LOCAL` 또는 특정 UUID로 설정되어야 합니다.
기본값은 `OFF`이며, 기능이 사용되지 않음을 의미합니다.
`LOCAL`은 복제본의 자체 UUID(`server_uuid` 설정)를 포함하는 GTID를 할당합니다.
UUID인 파라미터를 전달하면 지정된 UUID(예: 복제 소스 서버에 대한 `server_uuid` 설정)를 포함하는 GTID를 할당합니다.
### 예제
이 기능을 해제하려면 다음과 같이 하세요.
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF');
+-------------------------------------------------------------+
| Message |
+-------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF |
+-------------------------------------------------------------+
1 row in set (0.07 sec)
```
복제본의 자체 UUID를 사용하려면 다음과 같이 하세요.
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL');
+---------------------------------------------------------------+
| Message |
+---------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL |
+---------------------------------------------------------------+
1 row in set (0.07 sec)
```
지정된 UUID를 사용하려면 다음과 같이 하세요.
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e');
+----------------------------------------------------------------------------------------------+
| Message |
+----------------------------------------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e |
+----------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)
```
## mysql.rds\$1gtid\$1purged(Aurora MySQL 버전 3)
시스템 변수 `gtid_purged`의 글로벌 값을 지정된 글로벌 트랜잭션 식별자(GTID) 집합으로 설정합니다. `gtid_purged` 시스템 변수는 서버에서 커밋되었지만 서버의 이진 로그 파일에는 존재하지 않는 모든 트랜잭션의 GTID로 구성된 GTID 집합입니다.
MySQL 8.0과의 호환되도록 하기 위해 다음 두 가지 방법으로 `gtid_purged` 값을 설정할 수 있습니다.
+ `gtid_purged`의 값을 지정된 GTID 집합으로 교체합니다.
+ 지정된 GTID 집합을 `gtid_purged`에 이미 포함된 GTID 집합 세트에 덧붙입니다.
### 구문
`gtid_purged`의 값을 지정된 GTID 집합으로 교체하는 방법:
```
CALL mysql.rds_gtid_purged (gtid_set);
```
`gtid_purged`의 값을 지정된 GTID 집합에 덧붙이는 방법:
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### 파라미터
*gtid\$1set*
*gtid\$1set*의 값은 현재 `gtid_purged` 값의 상위 집합이어야 하며, `gtid_subtract(gtid_executed,gtid_purged)`와 겹쳐서는 안 됩니다. 즉, 새 GTID 집합에는 `gtid_purged`에 이미 들어 있던 모든 GTID를 포함해야 하며, `gtid_executed`에서 아직 삭제되지 않은 GTID는 포함할 수 없습니다. 또한 *gtid\$1set* 파라미터는 글로벌 `gtid_owned` 집합에 있는 GTID, 즉 현재 서버에서 처리 중인 트랜잭션에 대한 GTID를 포함할 수 없습니다.
### 사용 노트
마스터 사용자는 `mysql.rds_gtid_purged` 프로시저를 실행해야 합니다.
이 프로시저는 Aurora MySQL 버전 3.04 이상에서 지원됩니다.
### 예제
다음 예에서는 GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`을 `gtid_purged` 글로벌 변수에 할당합니다.
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL 버전 2 및 3)
Aurora 기본 인스턴스에서 지정된 전역 트랜잭션 식별자(GTID)를 사용하여 트랜잭션 복제를 건너뜁니다.
특정 GTID 트랜잭션이 문제의 원인으로 알려진 경우 재해 복구를 위해 이 프로시저를 사용할 수 있습니다. 이 저장 프로시저를 사용하여 문제의 트랜잭션을 건너 뛰십시오. 문제의 트랜잭션의 예로는 복제를 비활성화하거나 중요한 데이터를 삭제하거나 DB 인스턴스를 사용할 수 없도록 하는 트랜잭션이 포함됩니다.
### 구문
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### 파라미터
*gtid\$1to\$1skip*
건너 뛸 복제 트랜잭션의 GTID입니다.
### 사용 노트
마스터 사용자는 `mysql.rds_skip_transaction_with_gtid` 프로시저를 실행해야 합니다.
이 프로시저는 Aurora MySQL 버전 2 및 3에서 지원됩니다.
### 예제
다음 예에서는 GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`을 사용하여 트랜잭션의 복제를 건너뜁니다.
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL 버전 3)
Aurora MySQL DB 클러스터에서 복제를 시작하고 지정된 글로벌 트랜잭션 식별자(GTID) 바로 다음에서 복제를 중지합니다.
### 구문
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### 파라미터
*gtid*
GTID 이후 복제를 중지해야 합니다.
### 사용 노트
마스터 사용자는 `mysql.rds_start_replication_until_gtid` 프로시저를 실행해야 합니다.
이 프로시저는 Aurora MySQL 버전 3.04 이상에서 지원됩니다.
`mysql.rds_start_replication_until_gtid` 저장 프로시저는 다음을 포함하는 관리형 복제에 지원되지 않습니다.
+ [여러 AWS 리전에 걸쳐 Amazon Aurora MySQL DB 클러스터 복제](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora 읽기 전용 복제본을 사용하여 RDS for MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
`gtid` 파라미터가 복제본으로 이미 실행한 트랜잭션을 지정하는 경우 복제가 즉시 중지됩니다.
### 예제
다음 예제에서는 복제를 시작하고 GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`에 도달할 때까지 변경 사항을 복제합니다.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# 쿼리 로그 교체
다음 저장 프로시저는 MySQL 로그를 백업 테이블로 로테이션합니다. 자세한 내용은 [Aurora MySQL 데이터베이스 로그 파일](USER_LogAccess.Concepts.MySQL.md) 단원을 참조하십시오.
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
`mysql.general_log` 테이블을 백업 테이블로 로테이션합니다.
### 구문
```
CALL mysql.rds_rotate_general_log;
```
### 사용 노트
`mysql.rds_rotate_general_log` 프로시저를 호출하여 `mysql.general_log` 테이블을 백업 테이블로 로테이션할 수 있습니다. 로그 테이블이 순환되면 현재 로그 테이블은 백업 로그 테이블에 복사되며 현재 로그 테이블의 해당 항목들은 제거됩니다. 백업 로그 테이블이 이미 존재할 경우, 현재 로그 테이블이 백업으로 복사되기 전에 백업 로그 테이블이 삭제됩니다. 필요하다면 백업 로그 테이블을 쿼리할 수 있습니다. `mysql.general_log` 테이블에 대한 백업 로그 테이블 이름은 `mysql.general_log_backup`으로 지정됩니다.
이 절차는 `log_output` 파라미터를 `TABLE`로 설정한 경우에만 실행할 수 있습니다.
## mysql.rds\$1rotate\$1slow\$1log
`mysql.slow_log` 테이블을 백업 테이블로 로테이션합니다.
### 구문
```
CALL mysql.rds_rotate_slow_log;
```
### 사용 노트
`mysql.rds_rotate_slow_log` 프로시저를 호출하여 `mysql.slow_log` 테이블을 백업 테이블로 로테이션할 수 있습니다. 로그 테이블이 순환되면 현재 로그 테이블은 백업 로그 테이블에 복사되며 현재 로그 테이블의 해당 항목들은 제거됩니다. 백업 로그 테이블이 이미 존재할 경우, 현재 로그 테이블이 백업으로 복사되기 전에 백업 로그 테이블이 삭제됩니다.
필요하다면 백업 로그 테이블을 쿼리할 수 있습니다. `mysql.slow_log` 테이블에 대한 백업 로그 테이블 이름은 `mysql.slow_log_backup`으로 지정됩니다.
# 이진수 로그 구성 설정 및 표시
다음 저장 프로시저는 바이너리 로그 파일 유지에 대한 파라미터와 같은 구성 파라미터를 설정하고 표시합니다.
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
바이너리 로그를 보관할 기간(시간) 또는 복제를 지연할 시간(초)을 지정합니다.
### 구문
```
CALL mysql.rds_set_configuration(name,value);
```
### 파라미터
*이름*
설정할 구성 파라미터의 이름입니다.
*USD 상당*
구성 파라미터의 값입니다.
### 사용 노트
`mysql.rds_set_configuration` 프로시저는 다음 구성 파라미터를 지원합니다.
+ [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
구성 파라미터는 영구적으로 저장되며 DB 인스턴스 재부팅 또는 장애 조치 이후에도 유지됩니다.
#### binlog retention hours
`binlog retention hours` 파라미터는 이진 로그 파일을 보관할 기간(시간)을 지정하는 데 사용됩니다. Amazon Aurora는 일반적으로 가능한 한 빨리 바이너리 로그를 삭제하지만 Aurora 외부의 MySQL 데이터베이스 복제에는 바이너리 로그가 필요할 수 있습니다.
`binlog retention hours`의 기본값은 `NULL`입니다. Aurora MySQL에 대해 `NULL`은 이진 로그가 느리게 정리됨을 의미합니다. Aurora MySQL 바이너리 로그는 특정 기간(보통 하루 이하) 시스템에 남아 있을 수 있습니다.
DB 클러스터에 대한 바이너리 로그를 유지할 기간(시간)을 지정하려면 다음 예에 나와 있는 것처럼 `mysql.rds_set_configuration` 저장 프로시저를 사용하여 복제 수행에 충분한 기간을 지정합니다.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**참고**
`binlog retention hours`에는 `0` 값을 사용할 수 없습니다.
Aurora MySQL 버전 2.11.0 이상 및 버전 3 DB 클러스터의 최대 `binlog retention hours` 값은 2160(90일)입니다.
보존 기간을 설정한 후, DB 인스턴스 스토리지의 사용량을 모니터링하여 보존된 바이너리 로그가 너무 많은 스토리지를 차지하지 않도록 합니다.
## mysql.rds\$1show\$1configuration
바이너리 로그가 유지되는 시간입니다.
### 구문
```
CALL mysql.rds_show_configuration;
```
### 사용 노트
Amazon RDS의 이진수 로그 보관 시간을 확인하려면 `mysql.rds_show_configuration` 저장 프로시저를 사용합니다.
### 예제
다음 예제는 보존 기간을 표시합니다.
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Aurora MySQL 전용 information\$1schema 테이블
Aurora MySQL에는 Aurora 전용 특정 `information_schema` 테이블이 있습니다.
## information\$1schema.aurora\$1global\$1db\$1instance\$1status
`information_schema.aurora_global_db_instance_status` 테이블에는 글로벌 데이터베이스의 기본 및 보조 DB 클러스터에 있는 모든 DB 인스턴스의 상태에 대한 정보가 들어 있습니다. 사용할 수 있는 열이 다음 테이블에 나와 있습니다. 나머지 열은 Aurora 내부용으로만 사용됩니다.
**참고**
이 정보 스키마 테이블은 Aurora MySQL 버전 3.04.0 이상의 글로벌 데이터베이스에서만 사용할 수 있습니다.
| 열 | 데이터 유형 | 설명 |
| --- | --- | --- |
| SERVER\$1ID | varchar(100) | DB 인스턴스의 식별자입니다. |
| SESSION\$1ID | varchar(100) | 현재 세션에 대한 고유 식별자입니다. MASTER\$1SESSION\$1ID의 값은 Writer(프라이머리) DB 인스턴스를 식별합니다. |
| AWS\$1REGION | varchar(100) | 이 글로벌 데이터베이스 인스턴스가 실행되는 AWS 리전입니다. 리전 목록은 [리전 가용성](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability) 섹션을 참조하세요. |
| DURABLE\$1LSN | bigint 서명 안 됨 | 스토리지에서 뛰어난 내구성을 갖게 된 로그 시퀀스 번호(LSN)입니다. LSN(로그 시퀀스 번호)은 데이터베이스 트랜잭션 로그의 레코드를 식별하는 고유한 순차적 번호입니다. LSN은 더 큰 LSN이 더 이후의 트랜잭션을 나타내도록 정렬됩니다. |
| HIGHEST\$1LSN\$1RCVD | bigint 서명 안 됨 | 라이터 DB 인스턴스로부터 DB 인스턴스가 수신한 가장 높은 LSN입니다. |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint 서명 안 됨 | 라이터 DB 인스턴스가 삭제할 수 있는 가장 오래된 트랜잭션의 ID입니다. |
| OLDEST\$1READ\$1VIEW\$1LSN | bigint 서명 안 됨 | DB 인스턴스가 스토리지에서 읽는 데 사용하는 가장 오래된 LSN입니다. |
| VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) 서명 안 됨 | 기본 DB 클러스터의 리더의 경우 이 DB 인스턴스가 라이터 DB 인스턴스보다 얼마나 뒤처지는지 밀리초 단위로 나타낸 것입니다. 보조 DB 클러스터의 리더의 경우 이 DB 인스턴스가 보조 볼륨보다 얼마나 뒤처지는지 밀리초 단위로 나타낸 것입니다. |
## information\$1schema.aurora\$1global\$1db\$1status
`information_schema.aurora_global_db_status` 테이블에는 Aurora Global Database 지연의 다양한 측면, 특히 기본 Aurora 스토리지의 지연(내구성 지연) 및 Recovery Point Objective(RPO) 간의 지연에 대한 정보가 표시됩니다. 사용할 수 있는 열이 다음 테이블에 나와 있습니다. 나머지 열은 Aurora 내부용으로만 사용됩니다.
**참고**
이 정보 스키마 테이블은 Aurora MySQL 버전 3.04.0 이상의 글로벌 데이터베이스에서만 사용할 수 있습니다.
| 열 | 데이터 유형 | 설명 |
| --- | --- | --- |
| AWS\$1REGION | varchar(100) | 이 글로벌 데이터베이스 인스턴스가 실행되는 AWS 리전입니다. 리전 목록은 [리전 가용성](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability) 섹션을 참조하세요. |
| HIGHEST\$1LSN\$1WRITTEN | bigint 서명 안 됨 | 이 DB 클러스터에 현재 존재하는 가장 높은 로그 시퀀스 번호(LSN)입니다. LSN(로그 시퀀스 번호)은 데이터베이스 트랜잭션 로그의 레코드를 식별하는 고유한 순차적 번호입니다. LSN은 더 큰 LSN이 더 이후의 트랜잭션을 나타내도록 정렬됩니다. |
| DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) 서명 안 됨 | 보조 DB 클러스터의 HIGHEST\$1LSN\$1WRITTEN과 기본 DB 클러스터의 HIGHEST\$1LSN\$1WRITTEN 간 타임스탬프 값 차이입니다. 이 값은 Aurora 글로벌 데이터베이스의 기본 DB 클러스터에서 항상 0입니다. |
| RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) 서명 안 됨 | Recovery Point Objective(RPO) 지연입니다. RPO 지연은 Aurora Global Databse의 기본 DB 클러스터에 저장된 후 가장 최근의 사용자 트랜잭션 COMMIT 보조 DB 클러스터에 저장하는 데 걸리는 시간입니다. 이 값은 Aurora 글로벌 데이터베이스의 기본 DB 클러스터에서 항상 0입니다. 간단히 말해서 이 지표는 Aurora 글로벌 데이터베이스의 각 Aurora MySQL DB 클러스터에 대한 복구 시점 목표, 즉 중단 시 손실될 수 있는 데이터의 양을 계산합니다. 지연과 마찬가지로 RPO는 시간 단위로 측정됩니다. |
| LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | DURABILITY\$1LAG\$1IN\$1MILLISECONDS 및 RPO\$1LAG\$1IN\$1MILLISECONDS에 대한 값이 마지막으로 계산된 시점을 나타내는 타임스탬프입니다. 시간 값(예: 1970-01-01 00:00:00\$100)은 이것이 기본 DB 클러스터임을 의미합니다. |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint 서명 안 됨 | 라이터 DB 인스턴스가 삭제할 수 있는 가장 오래된 트랜잭션의 ID입니다. |
## information\$1schema.replica\$1host\$1status
`information_schema.replica_host_status` 테이블에는 복제 정보가 들어 있습니다. 사용할 수 있는 열이 다음 테이블에 나와 있습니다. 나머지 열은 Aurora 내부용으로만 사용됩니다.
| 열 | 데이터 유형 | 설명 |
| --- | --- | --- |
| CPU | double | 복제본 호스트의 CPU 사용률(%)입니다. |
| IS\$1CURRENT | tinyint | 복제본이 최신 상태인지를 나타냅니다. |
| LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | 마지막 업데이트가 발생한 시간입니다. 레코드가 오래되었는지를 확인하는 데 사용됩니다. |
| REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | 밀리 초로 나타낸 복제본 지연 시간입니다. |
| SERVER\$1ID | varchar(100) | 데이터베이스 서버의 ID입니다. |
| SESSION\$1ID | varchar(100) | 데이터베이스 세션의 ID입니다. DB 인스턴스가 라이터 인스턴스인지 아니면 리더 인스턴스인지를 결정하는 데 사용됩니다. |
**참고**
복제본 인스턴스가 지연되면 해당 `information_schema.replica_host_status` 테이블에서 쿼리된 정보가 만료될 수 있습니다. 이러한 경우 라이터 인스턴스에서 쿼리하는 것이 좋습니다.
`mysql.ro_replica_status` 테이블에 비슷한 정보가 있지만 사용하지 않는 것이 좋습니다.
## information\$1schema.aurora\$1forwarding\$1processlist
`information_schema.aurora_forwarding_processlist` 테이블에는 쓰기 전달과 관련된 프로세스에 대한 정보가 들어 있습니다.
이 테이블의 내용은 글로벌 또는 클러스터 내 쓰기 전달이 켜진 DB 클러스터의 라이터 DB 인스턴스에서만 볼 수 있습니다. 리더 DB 인스턴스에는 빈 결과 세트가 반환됩니다.
| 필드 | 데이터 유형 | 설명 |
| --- | --- | --- |
| ID | bigint | 라이터 DB 인스턴스의 연결 식별자입니다. 이 식별자는 SHOW PROCESSLIST 명령문의 Id 열에 표시된 값 및 스레드 내에서 CONNECTION\$1ID() 함수가 반환하는 값과 동일한 값입니다. |
| USER | varchar(32) | 명령문을 발행한 MySQL 사용자입니다. |
| HOST | varchar(255) | 명령문을 발행한 MySQL 클라이언트입니다. 전달된 명령문의 경우 이 필드에는 전달하는 리더 DB 인스턴스에 연결을 설정한 애플리케이션 클라이언트 호스트 주소가 표시됩니다. |
| DB | varchar(64) | 스레드의 기본 데이터베이스입니다. |
| 명령 | varchar(16) | 스레드가 클라이언트를 대신하여 실행하는 명령 유형 또는 세션이 유휴 상태인 경우 Sleep입니다. 스레드 명령에 대한 설명은 MySQL 설명서에서 [스레드 명령 값](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html)을 참조하세요. |
| TIME | int | 스레드가 현재 상태를 유지한 시간(초)입니다. |
| STATE | varchar(64) | 스레드가 수행하는 일을 나타내는 작업, 이벤트 또는 상태입니다. 상태 값에 대한 설명은 MySQL 설명서에서 [일반 스레드 상태](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html)를 참조하세요. |
| INFO | longtext | 스레드가 실행 중이라는 명령문 또는 명령문을 실행하지 않는 경우 NULL입니다. 명령문은 서버로 전송된 명령문일 수도 있고 해당 명령문이 다른 명령문을 실행하는 경우 가장 안쪽에 있는 명령문일 수도 있습니다. |
| IS\$1FORWARDED | bigint | 스레드가 리더 DB 인스턴스에서 전달되었는지를 나타냅니다. |
| REPLICA\$1SESSION\$1ID | bigint | Aurora 복제본의 연결 식별자입니다. 이 식별자는 전달하는 Aurora 리더 DB 인스턴스에서 SHOW PROCESSLIST 명령문의 Id 열에 표시된 값과 동일한 값입니다. |
| REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | 전달하는 스레드의 DB 인스턴스 식별자입니다. |
| REPLICA\$1CLUSTER\$1NAME | varchar(64) | 전달하는 스레드의 DB 클러스터 식별자입니다. 클러스터 내 쓰기 전달의 경우 이 식별자는 라이터 DB 인스턴스와 동일한 DB 클러스터입니다. |
| REPLICA\$1REGION | varchar(64) | 전달하는 스레드의 출처가 되는 AWS 리전입니다. 클러스터 내 쓰기 전달의 경우 이 리전은 라이터 DB 인스턴스와 동일한 AWS 리전입니다. |