Aurora 재부팅 작업의 예 - Amazon Aurora

Aurora 재부팅 작업의 예

다음 Aurora MySQL 예제에서는 Aurora DB 클러스터의 리더 및 라이터 DB 인스턴스에 대한 재부팅 작업의 여러 조합을 보여줍니다. 재부팅할 때마다 SQL 쿼리는 클러스터의 인스턴스에 대한 가동 시간을 보여줍니다.

Aurora 클러스터의 라이터 및 리더 인스턴스 찾기

DB 인스턴스가 여러 개인 Aurora MySQL 클러스터에서는 어느 인스턴스가 라이터이고, 어느 인스턴스가 리더인지 파악하는 것이 중요합니다. 또한 라이터 인스턴스와 리더 인스턴스는 장애 조치 작업이 수행될 때 역할을 전환할 수 있습니다. 따라서 라이터 또는 리더 인스턴스가 필요한 작업을 수행하기 전에 다음과 같은 검사를 수행하는 것이 가장 좋습니다. 이 경우 FalseIsClusterWriter 값은 리더 인스턴스 instance-6305instance-7448을 식별합니다. True 값은 라이터 인스턴스 instance-1234를 식별합니다.

$ aws rds describe-db-clusters --db-cluster-id tpch100g \ --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \ --output text Cluster: tpch100g Instance: instance-6305 False Instance: instance-7448 False Instance: instance-1234 True

재부팅 예제를 시작하기 전에 라이터 인스턴스의 가동 시간은 약 1주일입니다. 이 예제의 SQL 쿼리는 가동 시간을 확인하는 MySQL 관련 방법을 보여줍니다. 데이터베이스 애플리케이션에서 이 기술을 사용할 수 있습니다. AWS CLI를 사용하고 두 Aurora 엔진에서 모두 작동하는 다른 기술은 Aurora 클러스터 및 인스턴스의 가동 시간 확인 섹션을 참조하세요.

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status -> where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-08 17:49:06.000000 | 174h 42m| +----------------------------+---------+

단일 리더 인스턴스 재부팅

이 예제에서는 리더 DB 인스턴스 중 하나를 재부팅합니다. 아마도 이 인스턴스는 거대한 쿼리 또는 많은 동시 연결로 인해 오버로드되었을 수 있습니다. 또는 네트워크 문제로 인해 라이터 인스턴스보다 뒤쳐졌을 수 있습니다. 재부팅 작업이 시작된 후 이 예제에서는 wait 명령을 사용하여 인스턴스를 사용할 수 있게 될 때까지 일시 중지합니다. 이 시점까지 인스턴스의 가동 시간은 몇 분입니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-6305 { "DBInstance": { "DBInstanceIdentifier": "instance-6305", "DBInstanceStatus": "rebooting", ... } } $ aws rds wait db-instance-available --db-instance-id instance-6305 $ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status -> where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:35:02.000000 | 00h 03m | +----------------------------+---------+

리더 인스턴스를 재부팅해도 라이터 인스턴스의 가동 시간은 영향을 받지 않았습니다. 여전히 가동 시간은 약 1주일입니다.

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+----------+ | Last Startup | Uptime | +----------------------------+----------+ | 2021-03-08 17:49:06.000000 | 174h 49m | +----------------------------+----------+

라이터 인스턴스 재부팅

이 예제에서는 라이터 인스턴스를 재부팅합니다. 이 클러스터는 Aurora MySQL 버전 2.09를 실행 중입니다. Aurora MySQL 버전이 2.10보다 낮기 때문에 라이터 인스턴스를 재부팅하면 클러스터의 모든 리더 인스턴스도 재부팅됩니다.

wait 명령에 의해 재부팅이 완료될 때까지 일시 중지됩니다. 이제 해당 인스턴스의 가동 시간이 0으로 재설정됩니다. 라이터 및 리더 DB 인스턴스에 대한 재부팅 작업에 소요되는 시간은 크게 다를 수 있습니다. 라이터 및 리더 DB 인스턴스는 역할에 따라 서로 다른 종류의 정리 작업을 수행합니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstance": { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... } } $ aws rds wait db-instance-available --db-instance-id instance-1234 $ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:27.000000 | 00h 00m | +----------------------------+---------+

라이터 DB 인스턴스를 재부팅한 후 두 리더 DB 인스턴스의 가동 시간이 모두 재설정됩니다. 라이터 인스턴스가 재부팅되어 리더 인스턴스도 재부팅되었습니다. 이 동작은 Aurora PostgreSQL 클러스터 및 버전 2.10 이전의 Aurora MySQL 클러스터에 적용됩니다.

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:35.000000 | 00h 00m | +----------------------------+---------+ $ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:33.000000 | 00h 01m | +----------------------------+---------+

라이터와 리더를 독립적으로 재부팅

다음 예제에서는 Aurora MySQL 버전 2.10을 실행하는 클러스터를 보여줍니다. 이 Aurora MySQL 버전 이상에서는 모든 리더 인스턴스에 대한 재부팅을 야기하지 않고 라이터 인스턴스를 재부팅할 수 있습니다. 이렇게 하면 라이터 인스턴스를 재부팅할 때 쿼리 집약적인 애플리케이션이 중단되지 않습니다. 나중에 리더 인스턴스를 재부팅할 수 있습니다. 쿼리 트래픽이 낮은 시간에 이러한 재부팅을 수행할 수 있습니다. 리더 인스턴스를 한 번에 하나씩 재부팅할 수도 있습니다. 이렇게 하면 애플리케이션의 쿼리 트래픽에 항상 하나 이상의 리더 인스턴스를 사용할 수 있습니다.

다음 예제에서는 Aurora MySQL 버전 cluster-2393을 실행하는 5.7.mysql_aurora.2.10.0이라는 이름의 클러스터를 사용합니다. 이 클러스터에는 이름이 instance-9404인 라이터 인스턴스 1개와 이름이 instance-6772, instance-2470instance-5138인 리더 인스턴스 3개가 있습니다.

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \ --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \ --output text Cluster: cluster-2393 Instance: instance-5138 False Instance: instance-2470 False Instance: instance-6772 False Instance: instance-9404 True

uptime 명령을 통해 각 데이터베이스 인스턴스의 mysql 값을 확인하면 각 인스턴스의 가동 시간이 거의 동일하다는 것을 알 수 있습니다. 예를 들어 instance-5138의 가동 시간은 다음과 같습니다.

mysql> SHOW GLOBAL STATUS LIKE 'uptime'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime | 3866 | +---------------+-------+

CloudWatch를 사용하면 실제로 인스턴스에 로그인하지 않고도 해당 가동 시간 정보를 얻을 수 있습니다. 이 방식으로 관리자는 데이터베이스를 모니터링할 수 있지만 테이블 데이터를 보거나 변경할 수는 없습니다. 이 예에서는 5분에 걸친 기간을 지정하고 1분 간격으로 가동 시간 값을 확인합니다. 가동 시간 값이 증가하면 해당 기간 동안 인스턴스가 다시 시작되지 않았음을 나타냅니다.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4648.0 2021-03-17T23:42:00+00:00 Seconds DATAPOINTS 4708.0 2021-03-17T23:43:00+00:00 Seconds DATAPOINTS 4768.0 2021-03-17T23:44:00+00:00 Seconds DATAPOINTS 4828.0 2021-03-17T23:45:00+00:00 Seconds DATAPOINTS 4888.0 2021-03-17T23:46:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4315.0 2021-03-17T23:42:00+00:00 Seconds DATAPOINTS 4375.0 2021-03-17T23:43:00+00:00 Seconds DATAPOINTS 4435.0 2021-03-17T23:44:00+00:00 Seconds DATAPOINTS 4495.0 2021-03-17T23:45:00+00:00 Seconds DATAPOINTS 4555.0 2021-03-17T23:46:00+00:00 Seconds

이제 리더 인스턴스 중 하나인 instance-5138을 재부팅합니다. 재부팅 후 인스턴스를 다시 사용할 수 있을 때까지 기다립니다. 이제 5분 동안 가동 시간을 모니터링하면 해당 시간 동안 가동 시간이 0으로 재설정된 것을 알 수 있습니다. 가장 최근의 가동 시간 값은 재부팅이 완료되고 5초 후에 측정되었습니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-5138 $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4500.0 2021-03-17T23:46:00+00:00 Seconds DATAPOINTS 4560.0 2021-03-17T23:47:00+00:00 Seconds DATAPOINTS 4620.0 2021-03-17T23:48:00+00:00 Seconds DATAPOINTS 4680.0 2021-03-17T23:49:00+00:00 Seconds DATAPOINTS 5.0 2021-03-17T23:50:00+00:00 Seconds

다음으로 라이터 인스턴스 instance-9404에 대해 재부팅을 수행합니다. 라이터 인스턴스와 리더 인스턴스 중 하나에 대한 가동 시간 값을 비교합니다. 이렇게 하면 라이터를 재부팅해도 리더가 재부팅되지 않았다는 것을 알 수 있습니다. Aurora MySQL 2.10 이전 버전에서는 모든 리더의 가동 시간 값이 라이터와 동시에 재설정됩니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-9404 { "DBInstanceIdentifier": "instance-9404", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-9404 $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 371.0 2021-03-17T23:57:00+00:00 Seconds DATAPOINTS 431.0 2021-03-17T23:58:00+00:00 Seconds DATAPOINTS 491.0 2021-03-17T23:59:00+00:00 Seconds DATAPOINTS 551.0 2021-03-18T00:00:00+00:00 Seconds DATAPOINTS 37.0 2021-03-18T00:01:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \ --output text | sort -k 3 EngineUptime DATAPOINTS 5215.0 2021-03-17T23:57:00+00:00 Seconds DATAPOINTS 5275.0 2021-03-17T23:58:00+00:00 Seconds DATAPOINTS 5335.0 2021-03-17T23:59:00+00:00 Seconds DATAPOINTS 5395.0 2021-03-18T00:00:00+00:00 Seconds DATAPOINTS 5455.0 2021-03-18T00:01:00+00:00 Seconds

모든 리더 인스턴스에서 라이터 인스턴스와 동일한 구성 파라미터가 변경되도록 하려면 라이터 다음에 모든 리더 인스턴스를 재부팅합니다. 이 예제에서는 모든 리더를 재부팅한 다음 사용할 수 있을 때까지 기다린 후 계속합니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-6772 { "DBInstanceIdentifier": "instance-6772", "DBInstanceStatus": "rebooting" } $ aws rds reboot-db-instance --db-instance-identifier instance-2470 { "DBInstanceIdentifier": "instance-2470", "DBInstanceStatus": "rebooting" } $ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-6772 $ aws rds wait db-instance-available --db-instance-id instance-2470 $ aws rds wait db-instance-available --db-instance-id instance-5138

이제 라이터 DB 인스턴스의 가동 시간이 가장 높다는 것을 알 수 있습니다. 이 인스턴스의 가동 시간 값은 모니터링 기간 동안 꾸준히 증가했습니다. 리더 DB 인스턴스는 모두 리더 이후에 재부팅되었습니다. 모니터링 기간 내에서 각 리더가 재부팅되고 가동 시간이 0으로 재설정된 시점을 확인할 수 있습니다.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 457.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 517.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 577.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 637.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 697.0 2021-03-18T00:12:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \ --output text | sort -k 3 EngineUptime DATAPOINTS 5819.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 35.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 95.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 155.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 215.0 2021-03-18T00:12:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \ --output text | sort -k 3 EngineUptime DATAPOINTS 1085.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 1145.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 1205.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 49.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 109.0 2021-03-18T00:12:00+00:00 Seconds

Aurora MySQL 버전 2.10 클러스터에 클러스터 파라미터 변경 사항 적용

다음 예제는 Aurora MySQL 2.10 클러스터의 모든 DB 인스턴스에 파라미터 변경 사항을 적용하는 방법을 보여줍니다. 이 Aurora MySQL 버전에서는 라이터 인스턴스와 모든 리더 인스턴스를 독립적으로 재부팅합니다.

이 예제에서는 MySQL 구성 파라미터 lower_case_table_names를 사용하여 설명합니다. 이 파라미터 설정이 라이터와 리더 DB 인스턴스 간에 다른 경우 쿼리에서 대문자 또는 대/소문자 혼합 이름으로 선언된 테이블에 액세스하지 못할 수 있습니다. 또는 2개의 테이블 이름이 대문자와 소문자의 측면에서만 다른 경우 쿼리가 잘못된 테이블에 액세스할 수 있습니다.

이 예제에서는 각 인스턴스의 IsClusterWriter 속성을 검사하여 클러스터의 라이터 및 리더 인스턴스를 확인하는 방법을 보여줍니다. 클러스트 이름은 cluster-2393입니다. 이 클러스터에는 instance-9404라는 이름의 라이터 인스턴스가 있습니다. 클러스터의 리더 인스턴스 이름은 instance-5138instance-2470입니다.

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \ --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \ --output text cluster-2393 instance-5138 False instance-2470 False instance-9404 True

lower_case_table_names 파라미터 변경의 효과를 보여주기 위해 2개의 DB 클러스터 파라미터 그룹을 설정했습니다. lower-case-table-names-0 파라미터 그룹에서는 이 파라미터가 0으로 설정되어 있습니다. lower-case-table-names-1 파라미터 그룹에서는 이 파라미터 그룹이 1로 설정되어 있습니다.

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \ --db-parameter-group-family aurora-mysql5.7 \ --db-cluster-parameter-group-name lower-case-table-names-0 { "DBClusterParameterGroup": { "DBClusterParameterGroupName": "lower-case-table-names-0", "DBParameterGroupFamily": "aurora-mysql5.7", "Description": "lower-case-table-names-0" } } $ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \ --db-parameter-group-family aurora-mysql5.7 \ --db-cluster-parameter-group-name lower-case-table-names-1 { "DBClusterParameterGroup": { "DBClusterParameterGroupName": "lower-case-table-names-1", "DBParameterGroupFamily": "aurora-mysql5.7", "Description": "lower-case-table-names-1" } } $ aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name lower-case-table-names-0 \ --parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "lower-case-table-names-0" } $ aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name lower-case-table-names-1 \ --parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "lower-case-table-names-1" }

lower_case_table_names의 기본값은 0입니다. 이 파라미터 설정에서 테이블 foo는 테이블 FOO와 구별됩니다. 이 예제에서는 파라미터가 여전히 기본 설정에 있는지 확인합니다. 그런 다음 이름에서 대문자와 소문자만 다른 테이블 3개를 생성합니다.

mysql> create database lctn; Query OK, 1 row affected (0.07 sec) mysql> use lctn; Database changed mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ mysql> create table foo (s varchar(128)); mysql> insert into foo values ('Lowercase table name foo'); mysql> create table Foo (s varchar(128)); mysql> insert into Foo values ('Mixed-case table name Foo'); mysql> create table FOO (s varchar(128)); mysql> insert into FOO values ('Uppercase table name FOO'); mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +---------------------------+ | s | +---------------------------+ | Mixed-case table name Foo | +---------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Uppercase table name FOO | +--------------------------+

다음으로 DB 파라미터 그룹을 클러스터에 연결하여 lower_case_table_names 파라미터를 1로 설정합니다. 이 변경 사항은 각 DB 인스턴스를 재부팅한 후에만 적용됩니다.

$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \ --db-cluster-parameter-group-name lower-case-table-names-1 { "DBClusterIdentifier": "cluster-2393", "DBClusterParameterGroup": "lower-case-table-names-1", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" }

첫 번째 재부팅은 라이터 DB 인스턴스에 대해 수행합니다. 그런 다음 인스턴스를 다시 사용할 수 있을 때까지 기다립니다. 이 시점에서 라이터 엔드포인트에 연결하고 라이터 인스턴스에 변경된 파라미터 값이 있는지 확인합니다. SHOW TABLES 명령을 사용하여 데이터베이스에 3개의 서로 다른 테이블이 포함되어 있음을 확인합니다. 그러나 foo, Foo 또는 FOO 테이블을 참조하는 쿼리는 이름이 모두 소문자인 foo 테이블에 액세스합니다.

# Rebooting the writer instance $ aws rds reboot-db-instance --db-instance-identifier instance-9404 $ aws rds wait db-instance-available --db-instance-id instance-9404

이제 클러스터 엔드포인트를 사용하는 쿼리를 통해 파라미터 변경의 영향을 볼 수 있습니다. 쿼리의 테이블 이름이 대문자인지, 소문자인지, 대/소문자 혼합인지 여부에 관계없이 SQL 문은 이름이 모두 소문자인 테이블에 액세스합니다.

mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+ mysql> use lctn; mysql> show tables; +----------------+ | Tables_in_lctn | +----------------+ | FOO | | Foo | | foo | +----------------+ mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+

다음 예제는 이전 쿼리와 동일한 쿼리를 보여줍니다. 이 예에서 쿼리는 리더 엔드포인트를 사용하고 리더 DB 인스턴스 중 하나에서 실행됩니다. 이러한 인스턴스는 아직 재부팅되지 않았습니다. 따라서 lower_case_table_names 파라미터에 대한 원래 설정이 유지됩니다. 즉, 쿼리는 foo, FooFOO 테이블 각각에 액세스할 수 있습니다.

mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ mysql> use lctn; mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +---------------------------+ | s | +---------------------------+ | Mixed-case table name Foo | +---------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Uppercase table name FOO | +--------------------------+

다음으로 리더 인스턴스 중 하나를 재부팅하고 다시 사용할 수 있을 때까지 기다립니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-2470 { "DBInstanceIdentifier": "instance-2470", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-2470

instance-2470에 대한 인스턴스 엔드포인트에 연결되어 있는 동안 쿼리는 새 파라미터가 적용되었음을 보여줍니다.

mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+

이 시점에서 클러스터의 두 리더 인스턴스는 서로 다른 lower_case_table_names 설정으로 실행됩니다. 따라서 클러스터의 리더 엔드포인트에 대한 연결에서 이 설정에는 예측할 수 없는 값이 사용됩니다. 둘 다 일관된 설정을 갖도록 다른 리더 인스턴스를 즉시 재부팅하는 것이 중요합니다.

$ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-5138

다음 예제에서는 모든 리더 인스턴스의 lower_case_table_names 파라미터 설정이 동일한지 확인합니다. 명령은 각 리더 인스턴스의 lower_case_table_names 설정 값을 확인합니다. 그런 다음 리더 엔드포인트를 사용하는 동일한 명령으로 리더 엔드포인트에 대한 각 연결에 리더 인스턴스 중 하나(어느 것인지는 예측할 수 없음)가 사용되고 있음을 보여줍니다.

# Check lower_case_table_names setting on each reader instance. $ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-5138 | 1 | +--------------------------+--------------------------+ $ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-2470 | 1 | +--------------------------+--------------------------+ # Check lower_case_table_names setting on the reader endpoint of the cluster. $ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-5138 | 1 | +--------------------------+--------------------------+ # Run query on writer instance $ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-9404 | 1 | +--------------------------+--------------------------+

파라미터 변경이 모든 위치에 적용되면 lower_case_table_names=1 설정의 효과를 확인할 수 있습니다. 테이블이 foo든, Foo든, FOO든 쿼리는 이 이름을 foo로 변환하고 모든 경우 동일한 테이블에 액세스합니다.

mysql> use lctn; mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+