Aurora를 MySQL용 Cloud SQL로 마이그레이션하기 전에 고려해야 할 중요 사항

Aurora는 기본 문자 집합 서버 latin1을 사용합니다(MySQL v5.7까지). 이는 utf8을 마이그레이션 중에 기본 문자 집합으로 설정되어 만들어지는 데이터베이스, 테이블, 저장 프로시저, 함수에 대한 MySQL용 Cloud SQL의 기본 구성과는 다릅니다. 이로 인해 성능 문제가 발생할 수 있습니다.

예를 들어 사용자는 테이블은 latin1 문자 집합을 사용하여 만들어지고 저장 프로시저 또는 함수는 Cloud SQL 기본 utf8 문자 집합으로 만들어지는 상황에 부딪힐 수 있습니다. 이러한 경우 저장 프로시져 또는 함수에서 변수를 utf8 매개변수로 예상하고 이 변수를 latin1 문자 집합으로 만들어진 열 값과 비교하면, 서로 다른 두 개 문자 집합의 비교와 콜레이션으로 인해 성능 문제가 발생합니다. 

아래 명령어를 사용하여 루틴의 문자 집합을 확인할 수 있습니다.

mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES;

latin1인 Aurora(v5.7까지)의 기본 문자 집합을 사용한 경우 데이터를 가져오기 전에 Cloud SQL에서 기본 문자 집합을 utf8에서 latin1로 변경해야 합니다.

다른 솔루션으로 모든 것을 utf8로 변경하는 방법이 있지만 이 경우 문자 집합 변경으로 인해 예상치 못한 데이터 표현이 발생할 수 있으므로 사용자는 전체 애플리케이션과 데이터 세트를 테스트해야 합니다.

사용자는 아래 그림과 같이 플래그 섹션의 Cloud SQL 인스턴스에서 이 설정을 수정할 수 있습니다.

Aurora MySQL 5.7에는 MySQL 8.0용 Cloud SQL에서만 사용할 수 있는 콜레이션이 많습니다(예: utf8mb4_0900_ai_ci 문자 집합 utf8mb4). 이러한 콜레이션을 사용 중이고 MySQL 5.7용 Cloud SQL에서 데이터를 가져올 경우 '오류 '문자 집합 '#255'는 컴파일된 문자 집합이 아닙니다'와 같은 오류 메시지가 표시됩니다.

해결 방법은 MySQL 버전 5.7에서 사용 가능한 콜레이션으로 변경하는 것입니다.

MySQL용 Cloud SQL은 Aurora와 달리 MyISAM 엔진을 지원하지 않습니다. Aurora에서 Cloud SQL로 마이그레이션을 시작하기 전에 모든 테이블을 InnoDB로 변환하는 것이 좋습니다. 

InnoDB 이외의 엔진에 테이블이 있는 경우 사용자는 'ALTER' 명령어를 사용하여 테이블의 엔진을 변경할 수 있습니다.

mysql> alter table table_1 engine='Innodb' ;

Query OK, 0 rows affected (2.89 sec)

Records: 0 Duplicates: 0 Warnings: 0

참고: 쿼리 시간은 테이블 크기에 따라 달라지며 동일한 테이블의 다른 작업이 잠길 수도 있습니다. 또한 pt-online-schema-change 또는 gh-ost와 같은 온라인 스키마 변경 도구를 사용하여 다른 작업을 잠그지 않고 테이블을 변경할 수 있습니다.

Aurora 사용자는 단일 엔드포인트에 여러 리더를 설정할 수 있지만 MySQL용 Cloud SQL 사용자는 이 기능을 바로 사용할 수 없습니다. MySQL용 Cloud SQL의 모든 읽기 복제본에는 자체 IP가 있으며 사용자는 ProxySQL과 같은 기능을 사용하여 트래픽을 여러 읽기 복제본 인스턴스에 분할해야 합니다.

다음은 ProxySQL을 사용하여 여러 읽기 복제본 간에 트래픽을 라우팅하는 방법을 보여주는 가이드입니다.

변경 버퍼는 보조 색인 페이지가 버퍼 풀에 없는 경우 보조 색인 페이지의 변경사항을 캐시하고, 나중에 다른 읽기 작업에 의해 보조 색인 페이지가 버퍼 풀로 로드될 때 병합되는 특수한 데이터 구조입니다. 자세한 내용은 변경 버퍼를 참조하세요.

보조 색인이 있는 테이블에 대한 많은 쓰기가 포함되는 워크로드인 경우 Aurora는 MySQL용 Cloud SQL보다 느리게 작동할 수 있는데, MySQL용 Cloud SQL는 기본 InnoDB 변경 버퍼 기능을 사용하여 이러한 업데이트를 이후 단계로 연기하기 때문입니다. 사용자는 애플리케이션 워크로드에 따라 성능을 벤치마킹해야 합니다.

쿼리 캐시는 select 명령어를 그 결과와 함께 중간 스토리지 레이어에 저장합니다. 나중에 동일한 문을 수신하면 서버는 명령어를 다시 실행하는 대신 쿼리 캐시에서 결과를 확인 및 검색합니다. 쿼리 캐시는 세션 간에 공유되므로 모든 세션이 다른 세션에서 이미 실행된 문에 의해 캐시된 결과를 활용할 수 있습니다. 쿼리 캐시 자세히 알아보기

Aurora는 기본적으로 쿼리 캐시를 사용 설정하지만 MySQL 커뮤니티는 5.7 버전에서 쿼리 캐시를 사용 중지하고 8.0 버전에서 완전히 삭제했습니다. Cloud SQL MySQL에서도 동일하게 적용했습니다. 쿼리가 Aurora의 쿼리 캐시 기능에 의존하는 경우 Cloud SQL MySQL에서 성능이 다르게 나타날 수 있습니다. Aurora에서의 실행 시간과 비교하여 Cloud SQL MySQL에서의 쿼리 성능을 테스트하는 것이 좋습니다.

리전 내 읽기 복제본의 경우 Aurora는 해당 리전 내 3개 가용성 영역에 걸쳐 데이터 사본이 있는 클러스터 볼륨 개념을 사용합니다. Aurora의 복제 지연 시간은 보통 동일한 데이터베이스 클러스터 내의 기본 데이터와 복제본이 모두 클러스터 볼륨의 데이터를 단일 논리 볼륨으로 보기 때문에 100밀리초 미만입니다. 또한 리전 간 읽기 복제본의 경우 Aurora는 바이너리 로그 기반 복제 대신 리전 간 디스크 기반 데이터 동기화를 사용합니다.

즉, Aurora의 스토리지 레이어에서 복제를 처리하는 반면, MySQL용 Cloud SQL에서는 바이너리 로그를 복제본 인스턴스로 전송한 후 MySQL 인스턴스를 사용하는 복제본에서 로그를 재생하는 표준 복제 메커니즘이 사용됩니다. Cloud SQL에서 동시 복제를 구성하여 복제 성능을 개선할 수 있습니다. 동시 복제 설정에 대한 세부정보 살펴보기

복제 지연은 애플리케이션과 기본 및 복제본 인스턴스 간 네트워크에서 변경되는 데이터 양에 따라 달라지지만, 대부분의 애플리케이션은 Aurora와 MySQL용 Cloud SQL 모두에서 현저한 지연 없이 원활하게 작동합니다. 하지만 애플리케이션이 쓰기가 많고 복제본에서 읽기 작업을 수행하는 경우 마이그레이션 전에 AWS Aurora 및 CloudSQL MySQL 모두에서 복제 지연 시간을 벤치마킹하는 것이 좋습니다.

디스크 기반 데이터 동기화를 사용하는 AWS Aurora와 달리 MySQL용 Cloud SQL은 GTID 복제를 사용합니다. 마이그레이션하기 전에 아래에 나열된 GTID의 제한사항을 확인하고 애플리케이션 워크플로가 이러한 기능에 의존하는 경우 애플리케이션에 필요한 변경사항을 적용해야 합니다.

• CREATE TABLE ... SELECT 문은 GTID 기반 복제를 사용하는 경우 허용되지 않습니다.
• CREATE TEMPORARY TABLE 및 DROP TEMPORARY TABLE 문은 트랜잭션, 프러시저, 함수, 트리거 내에서 지원되지 않습니다. GTID가 사용 설정된 상태에서 이 문을 사용할 수 있지만 모든 트랜젝션 외부에서와 autocommit=1인 경우에만 사용할 수 있습니다.

GTID 기반 제한사항에 대한 자세한 내용은 GTID 제한사항을 참조하세요.