Amazon Aurora DB 클러스터 또는 Amazon Aurora DB 인스턴스 재부팅
일반적으로 유지 관리를 위해 DB 클러스터 또는 클러스터 내의 일부 인스턴스를 재부팅해야 할 수 있습니다. 예를 들어 파라미터 그룹 내의 파라미터를 수정하거나 다른 파라미터 그룹을 클러스터에 연결한다고 가정해 보겠습니다. 이러한 경우 변경 사항을 적용하려면 클러스터를 재부팅해야 합니다. 마찬가지로 클러스터 내에서 하나 이상의 리더 DB 인스턴스를 재부팅할 수 있습니다. 개별 인스턴스에 대한 재부팅 작업을 준비하면 전체 클러스터의 다운타임을 최소화할 수 있습니다.
클러스터의 각 DB 인스턴스를 재부팅하는 데 필요한 시간은 재부팅 시 데이터베이스 활동에 따라 다릅니다. 또한 특정 DB 엔진의 복구 프로세스에 따라서도 다릅니다. 가능하다면 재부팅 프로세스를 시작하기 전에 특정 인스턴스의 데이터베이스 활동을 줄이세요. 이렇게 하면 데이터베이스를 다시 시작하는 데 필요한 시간을 줄일 수 있습니다.
클러스터의 각 DB 인스턴스는 사용 가능한 상태인 경우에만 재부팅할 수 있습니다. DB 인스턴스를 사용할 수 없는 이유로는 여러 가지가 있습니다. 예를 들어 클러스터가 중지 상태에 있는 경우, 인스턴스에 수정을 적용 중인 경우 및 유지 관리 기간 작업(예: 버전 업그레이드)이 여기에 포함됩니다.
DB 인스턴스를 재부팅하면 데이터베이스 엔진 프로세스가 다시 시작됩니다. DB 인스턴스를 재부팅하면 DB 인스턴스 상태가 rebooting으로 설정되면서 잠시 중단됩니다.
참고
DB 인스턴스에서 연결된 DB 파라미터 그룹에 대한 최신 변경 내용을 사용하고 있지 않은 경우 AWS Management Console에 DB 파라미터 그룹이 재시작 보류중 상태로 표시됩니다. 재시작 보류중 파라미터 그룹 상태로 인해 다음번 유지 관리 기간 중에 자동 재부팅이 되지는 않습니다. 최신 파라미터 변경 내용을 이 DB 인스턴스에 적용하려면 해당 DB 인스턴스를 수동으로 재부팅해야 합니다. 파라미터 그룹에 대한 자세한 내용은 파라미터 그룹 작업 단원을 참조하십시오.
주제
Aurora 클러스터 내의 DB 인스턴스 재부팅
이 절차는 Aurora에서 재부팅을 수행할 때 가장 중요한 작업입니다. 대부분의 유지 관리 절차에는 하나 이상의 Aurora DB 인스턴스를 특정 순서로 재부팅하는 작업이 포함됩니다.
DB 인스턴스를 재부팅하려면
-
AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/
에서 Amazon RDS 콘솔을 엽니다. -
탐색 창에서 데이터베이스를 선택한 다음 재부팅하려는 DB 인스턴스를 선택합니다.
-
작업에서 재부팅을 선택합니다.
[Reboot DB Instance] 페이지가 나타납니다.
-
DB 인스턴스를 재부팅하려면 [Reboot]를 선택합니다.
또는 [취소(Cancel)]를 선택합니다.
AWS CLI를 사용하여 DB 인스턴스를 재부팅하려면 reboot-db-instance 명령을 호출하십시오.
대상 LinuxmacOS, 또는Unix:
aws rds reboot-db-instance \ --db-instance-identifiermydbinstance
Windows의 경우:
aws rds reboot-db-instance ^ --db-instance-identifiermydbinstance
Amazon RDS API를 사용하여 DB 인스턴스를 재부팅하려면 RebootDBInstance 작업을 호출하세요.
읽기 가용성을 포함하여 Aurora 클러스터 재부팅
읽기 가용성 기능을 사용하면 기본 또는 보조 DB 클러스터의 리더 인스턴스를 재부팅하지 않고도 Aurora 클러스터의 라이터 인스턴스를 재부팅할 수 있습니다. 이렇게 하면 라이터 인스턴스를 재부팅하는 동안 읽기 작업에 대한 클러스터의 고가용성을 유지하는 데 도움이 됩니다. 나중에 편리한 일정에 따라 리더 인스턴스를 재부팅할 수 있습니다. 예를 들어 프로덕션 클러스터에서는 프라이머리 인스턴스의 재부팅이 완료된 후에만 리더 인스턴스를 한 번에 하나씩 재부팅할 수 있습니다. 재부팅하는 각 DB 인스턴스에 대해 Aurora 클러스터 내의 DB 인스턴스 재부팅의 절차를 따릅니다.
기본 DB 클러스터의 읽기 가용성 기능은 Aurora MySQL 버전 2.10 이상에서 사용할 수 있습니다. 보조 DB 클러스터의 읽기 가용성은 Aurora MySQL 버전 3.06 이상에서 사용할 수 있습니다.
이 함수는 다음 Aurora PostgreSQL 버전에서 기본적으로 사용할 수 있습니다.
15.2 이상의 15 버전
14.7 이상의 14 버전
13.10 이상의 13 버전
12.14 이상의 12 버전
Aurora PostgreSQL의 읽기 가용성 기능에 대한 자세한 내용은 Aurora 복제본의 읽기 가용성 향상 섹션을 참조하세요.
이 기능이 출시되기 전에는 기본 인스턴스를 재부팅하면 각 리더 인스턴스가 동시에 재부팅되었습니다. Aurora 클러스터에서 이전 버전을 실행 중인 경우 읽기 가용성을 포함하지 않고 Aurora 클러스터 재부팅의 재부팅 절차를 대신 사용합니다.
참고
Aurora MySQL 버전 3.06 미만의 Aurora 글로벌 데이터베이스의 경우 읽기 가용성이 포함된 Aurora DB 클러스터의 재부팅 동작에 대한 변경 사항이 다릅니다. Aurora 글로벌 데이터베이스의 프라이머리 클러스터에 대한 라이터 인스턴스를 재부팅하는 경우 프라이머리 클러스터의 리더 프로그램 인스턴스는 사용할 수 있는 상태로 유지됩니다. 그러나 세컨더리 클러스터의 DB 인스턴스는 동시에 재부팅됩니다.
향상된 읽기 가용성 기능의 제한된 버전은 Aurora PostgreSQL 버전 12.16, 13.12, 14.9, 15.4 이상용 Aurora 글로벌 데이터베이스에서 지원됩니다.
클러스터 파라미터 그룹을 변경한 후에는 클러스터를 자주 재부팅하게 됩니다. 파라미터를 변경하려면 파라미터 그룹 작업의 절차를 따릅니다. 클러스터 파라미터에 변경 사항을 적용하기 위해 Aurora 클러스터에서 라이터 DB 인스턴스를 재부팅한다고 가정해 보겠습니다. 리더 DB 인스턴스의 일부 또는 전부에는 이전 파라미터 설정이 계속해서 사용될 수 있습니다. 그러나 다른 파라미터 설정이 클러스터의 데이터 무결성에 영향을 미치지는 않습니다. 데이터 파일 구성에 영향을 주는 클러스터 파라미터는 라이터 DB 인스턴스에만 사용됩니다.
예를 들어, Aurora MySQL 인스턴스에서 리더 인스턴스 전에 라이터 인스턴스의 binlog_format 및 innodb_purge_threads와 같은 클러스터 파라미터를 업데이트할 수 있습니다. 라이터 인스턴스만 바이너리 로그를 작성하고 실행 취소 레코드를 제거합니다. 쿼리에서 SQL 문 또는 쿼리 출력을 해석하는 방식을 변경하는 파라미터의 경우 리더 인스턴스를 즉시 재부팅해야 할 수 있습니다. 이렇게 해야 쿼리 중에 예기치 않은 애플리케이션 동작을 방지할 수 있습니다. 예를 들어 lower_case_table_names 파라미터를 변경하고 라이터 인스턴스를 재부팅한다고 가정합시다. 이 경우 리더 인스턴스가 모두 재부팅될 때까지 새로 생성한 테이블에 액세스하지 못할 수 있습니다.
모든 Aurora MySQL 클러스터 파라미터 목록은 클러스터 수준 파라미터 섹션을 참조하세요.
모든 Aurora PostgreSQL 클러스터 파라미터 목록은 Aurora PostgreSQL 클러스터 수준 파라미터 섹션을 참조하세요.
작은 정보
클러스터에서 처리량이 높은 워크로드를 처리 중인 경우 Aurora MySQL은 라이터 인스턴스와 함께 일부 리더 인스턴스를 재부팅할 수 있습니다.
재부팅 횟수의 감소는 장애 조치 작업 중에도 적용됩니다. Aurora MySQL은 장애 조치 중에 라이터 DB 인스턴스와 장애 조치 대상만 재시작합니다. 클러스터의 다른 리더 DB 인스턴스는 리더 엔드포인트에 대한 연결을 통해 쿼리를 처리하는 데 계속해서 사용할 수 있습니다. 따라서 클러스터에 리더 DB 인스턴스를 2개 이상 보유하여 장애 조치 중에 가용성을 개선할 수 있습니다.
읽기 가용성을 포함하지 않고 Aurora 클러스터 재부팅
읽기 가용성 기능을 사용하지 않으면 클러스터의 라이터 DB 인스턴스를 재부팅하여 전체 Aurora DB 클러스터를 재부팅할 수 있습니다. 이 작업을 수행하려면 의 절차를 수행합니다Aurora 클러스터 내의 DB 인스턴스 재부팅
라이터 DB 인스턴스를 재부팅하면 클러스터의 각 리더 DB 인스턴스에 대해서도 재부팅이 시작됩니다. 이 방식으로 클러스터 전체 파라미터 변경 사항이 모든 DB 인스턴스에 동시에 적용됩니다. 그러나 모든 DB 인스턴스를 재부팅하면 클러스터가 잠시 중단됩니다. 라이터 DB 인스턴스의 재부팅이 완료되고 사용할 수 있게 될 때까지 리더 DB 인스턴스를 사용할 수 없게 됩니다.
이 재부팅 동작은 Aurora MySQL 버전 2.09 이하에서 생성된 모든 DB 클러스터에 적용됩니다.
Aurora PostgreSQL의 경우 이 동작은 다음 버전에 적용됩니다.
14.6 이하 14 버전
13.9 이하 13 버전
12.13 이하 12 버전
모든 PostgreSQL 11 버전
RDS 콘솔에서 라이터 DB 인스턴스의 값인 [라이터(Writer)]는 [데이터베이스(Databases)] 페이지의 [역할(Role)] 열에 표시됩니다. RDS CLI에서 describe-db-clusters 명령 출력에는 DBClusterMembers 섹션이 포함됩니다. 라이터 DB 인스턴스를 나타내는 DBClusterMembers 요소는 true 필드에 IsClusterWriter 값이 표시됩니다.
중요
읽기 가용성 기능을 사용하면 Aurora MySQL 및 Aurora PostgreSQL에서는 재부팅 동작이 다릅니다. 일반적으로 라이터 인스턴스를 재부팅하는 동안 리더 DB 인스턴스를 사용할 수 있습니다. 그런 다음 편리한 시간에 리더 인스턴스를 재부팅할 수 있습니다. 일부 리더 인스턴스를 항상 사용할 수 있도록 하려면 시간 간격을 두고 리더 인스턴스를 재부팅하면 됩니다. 자세한 내용은 읽기 가용성을 포함하여 Aurora 클러스터 재부팅 단원을 참조하십시오.
Aurora 클러스터 및 인스턴스의 가동 시간 확인
Aurora 클러스터의 각 DB 인스턴스에 대한 마지막 재부팅 이후 경과 시간을 확인하고 모니터링할 수 있습니다. Amazon CloudWatch 지표 EngineUptime은 DB 인스턴스가 마지막으로 시작된 이후의 시간(초)을 보고합니다. 특정 시점에 이 지표를 검토하여 DB 인스턴스의 가동 시간을 확인할 수 있습니다. 이 지표를 시간대별로 모니터링하여 인스턴스가 재부팅되는 시기를 감지할 수도 있습니다.
클러스터 수준에서 EngineUptime 지표를 검사할 수도 있습니다. Minimum 및 Maximum 차원은 클러스터의 모든 DB 인스턴스에 대한 최소 및 최대 가동 시간 값을 보고합니다. 클러스터의 리더 인스턴스가 재부팅되거나 다른 이유로 다시 시작된 최근 시간을 확인하려면 Minimum 차원을 사용하여 클러스터 수준 지표를 모니터링합니다. 클러스터에서 재부팅 없이 가장 오래 지속된 인스턴스를 확인하려면 Maximum 차원을 사용하여 클러스터 수준 지표를 모니터링합니다. 예를 들어 구성 변경 후 클러스터의 모든 DB 인스턴스가 재부팅되었는지 확인해야 할 수 있습니다.
작은 정보
장기 모니터링의 경우 클러스터 수준 대신 개별 인스턴스에 대한 EngineUptime 지표를 모니터링하는 것이 좋습니다. 클러스터에 새 DB 인스턴스가 추가되면 클러스터 수준 EngineUptime 지표가 0으로 설정됩니다. 이러한 클러스터 변경은 Auto Scaling에서 수행되는 것과 같은 유지 관리 및 확장 작업의 일부로 발생할 수 있습니다.
다음 CLI 예제는 클러스터의 라이터 및 리더 인스턴스에 대한 EngineUptime 지표를 검사하는 방법을 보여줍니다. 이 예제에는 이름이 tpch100g인 클러스터가 사용됩니다. 이 클러스터에는 라이터 DB 인스턴스 instance-1234가 있습니다. 또한 2개의 리더 DB 인스턴스 instance-7448과 instance-6305가 있습니다.
먼저 reboot-db-instance 명령은 리더 인스턴스 중 하나를 재부팅합니다. 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
CloudWatch get-metric-statistics 명령은 지난 5분간의 EngineUptime 지표를 1분 간격으로 검사합니다. instance-6305 인스턴스의 가동 시간이 0으로 재설정되고 다시 계산되기 시작합니다. 이 Linux용 AWS CLI 예제에서는 $() 변수 대체를 사용하여 CLI 명령에 해당하는 타임스탬프를 삽입합니다. 또한 Linux sort 명령을 사용하여 지표가 수집된 시간별로 출력 순서를 지정합니다. 이 타임스탬프 값은 출력의 각 줄에서 세 번째 필드입니다.
$ 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 Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 231.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 291.0 2021-03-16T18:20:00+00:00 Seconds DATAPOINTS 351.0 2021-03-16T18:21:00+00:00 Seconds DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
클러스터의 인스턴스 중 하나가 재부팅되었으므로 클러스터의 최소 가동 시간이 0으로 재설정됩니다. 클러스터의 DB 인스턴스 중 하나 이상이 사용 가능한 상태로 남아 있기 때문에 클러스터의 최대 가동 시간은 재설정되지 않습니다.
$ 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=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63099.0 2021-03-16T18:12:00+00:00 Seconds DATAPOINTS 63159.0 2021-03-16T18:13:00+00:00 Seconds DATAPOINTS 63219.0 2021-03-16T18:14:00+00:00 Seconds DATAPOINTS 63279.0 2021-03-16T18:15:00+00:00 Seconds DATAPOINTS 51.0 2021-03-16T18:16: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 Maximum \ --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63389.0 2021-03-16T18:16:00+00:00 Seconds DATAPOINTS 63449.0 2021-03-16T18:17:00+00:00 Seconds DATAPOINTS 63509.0 2021-03-16T18:18:00+00:00 Seconds DATAPOINTS 63569.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 63629.0 2021-03-16T18:20:00+00:00 Seconds
그런 다음 다른 reboot-db-instance 명령에 의해 클러스터의 라이터 인스턴스가 재부팅됩니다. 다른 wait 명령은 라이터 인스턴스의 재부팅이 완료될 때까지 일시 중지됩니다.
$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... $ aws rds wait db-instance-available --db-instance-id instance-1234
이제 라이터 인스턴스의 EngineUptime 지표에서 인스턴스 instance-1234가 최근에 재부팅되었음을 알 수 있습니다. 리더 인스턴스 instance-6305도 라이터 인스턴스와 함께 자동으로 재부팅되었습니다. 이 클러스터는 Aurora MySQL 2.09를 실행 중이므로 라이터 인스턴스가 재부팅될 때 리더 인스턴스의 실행이 유지되지 않습니다.
$ 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 Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \ | sort -k 3 EngineUptime DATAPOINTS 63749.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 63809.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 63869.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 41.0 2021-03-16T18:25:00+00:00 Seconds DATAPOINTS 101.0 2021-03-16T18:26: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 Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 531.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 49.0 2021-03-16T18:26:00+00:00 Seconds
Aurora 재부팅 작업의 예
다음 Aurora MySQL 예제에서는 Aurora DB 클러스터의 리더 및 라이터 DB 인스턴스에 대한 재부팅 작업의 여러 조합을 보여줍니다. 재부팅할 때마다 SQL 쿼리는 클러스터의 인스턴스에 대한 가동 시간을 보여줍니다.
주제
Aurora 클러스터의 라이터 및 리더 인스턴스 찾기
DB 인스턴스가 여러 개인 Aurora MySQL 클러스터에서는 어느 인스턴스가 라이터이고, 어느 인스턴스가 리더인지 파악하는 것이 중요합니다. 또한 라이터 인스턴스와 리더 인스턴스는 장애 조치 작업이 수행될 때 역할을 전환할 수 있습니다. 따라서 라이터 또는 리더 인스턴스가 필요한 작업을 수행하기 전에 다음과 같은 검사를 수행하는 것이 가장 좋습니다. 이 경우 False의 IsClusterWriter 값은 리더 인스턴스 instance-6305 및 instance-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 -umy-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 -umy-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 -umy-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 -umy-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 -umy-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 -umy-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-2470 및 instance-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-5138 및 instance-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, Foo 및FOO 테이블 각각에 액세스할 수 있습니다.
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 \ -umy-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 \ -umy-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 \ -umy-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 \ -umy-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 | +--------------------------+
