Amazon Aurora 라이터 엔드포인트에 연결하려고 할 때 연결이 리더 인스턴스로 리디렉션되는 이유는 무엇입니까?

3분 분량

애플리케이션 서버에서 Amazon Aurora 클러스터 엔드포인트/라이터 엔드포인트를 사용하고 있지만 애플리케이션이 리더 인스턴스에 대신 연결됩니다.

간략한 설명

Aurora 클러스터 엔드포인트 또는 라이터 엔드포인트에 연결하려고 하면 애플리케이션이 리더 인스턴스에 대신 연결될 수 있습니다. 이는 엔드포인트와 매핑된 IP 주소가 클라이언트 애플리케이션 측에서 캐시될 때 발생합니다.

Aurora 클러스터 엔드포인트는 항상 Aurora 라이터 인스턴스를 가리킵니다. 장애 조치가 발생하면 Aurora 클러스터 엔드포인트가 새 라이터 인스턴스를 가리킵니다. 클러스터 엔드포인트를 사용하는 경우 장애 조치 중에 읽기/쓰기 연결은 Aurora 복제본에 자동으로 리디렉션됩니다. 이 복사본 인스턴스는 기본 인스턴스로 승격됩니다.

따라서 장애 조치 중에 Aurora 인스턴스의 기본 IP 주소가 변경되어 캐시된 값이 더 이상 사용되지 않을 수 있습니다.

DNS 이름을 사용하여 데이터베이스에 연결하려는 클라이언트는 DNS 서버를 쿼리하여 해당 DNS 이름을 IP 주소로 확인해야 합니다. 그러면 클라이언트가 응답을 캐싱합니다. 프로토콜별로 DNS 응답은 클라이언트가 레코드를 캐싱해야 하는 기간을 제어하는 Time to Live(TTL)를 지정합니다. Aurora DNS 영역은 5초의 짧은 TTL을 사용합니다. 그러나 많은 시스템은 설정이 다른 클라이언트 캐시를 구현하므로 TTL이 더 길어질 수 있습니다.

DNS 레코드 변경 사항이 전파되지 않은 상태에서 클라이언트가 클러스터에 연결하려고 하면 클라이언트는 이전 주소를 수신합니다. 그러면 클라이언트가 이전의 기본 인스턴스, 이제 리더 인스턴스에 연결됩니다.

따라서 DNS 데이터를 장기간 캐싱하면 연결이 실패할 수 있습니다.

클라이언트는 장애 조치가 시작된 후 데이터베이스에서 더 이상 TCP 트래픽을 받지 않습니다. 대신, 타임아웃은 클라이언트에 달려 있습니다. 모든 장애 조치 시 원본 기본 데이터베이스를 이렇게 하드 펜싱하면 클라이언트가 계획된 장애 조치 및 계획되지 않은 장애 조치 중에 유사한 동작을 보게 됩니다.

해결 방법

라이터 인스턴스 또는 Aurora 복사본에 연결 중인지 확인합니다.

클라이언트가 라이터 인스턴스에 연결되는지 Aurora 복사본에 연결되는지 확인하려면 @@innodb_read_only 변수를 사용합니다.

mysql> select @@innodb_read_only;

값이 0이면 라이터 인스턴스에 연결되었음을 의미합니다.

다음 쿼리를 실행하여 현재 연결되어 있는 서버와 해당 서버가 라이터인지 리더인지 확인합니다.

mysql> select concat("You are connected to '",server_id,"', which is a ",if(SESSION_ID='MASTER_SESSION_ID',"Writer","Reader")) as CONNECTION_STATUS from information_schema.replica_host_status where SERVER_ID in (select @@aurora_server_id);
+-----------------------------------------------------------------+
| CONNECTION_STATUS                                               |
+-----------------------------------------------------------------+
| You are connected to 'aurora-test-instance1', which is a Writer |
+-----------------------------------------------------------------+
1 row in set (0.08 sec)

클러스터의 여러 리더 인스턴스 문제 해결

Aurora 리더 엔드포인트는 DNS CNAME 항목입니다. 클러스터에 리더 인스턴스가 여러 개 있는 경우, 리더 엔드포인트를 확인하면 라운드 로빈 방식으로 선택된 인스턴스 IP를 받게 됩니다. 이는 리더 엔드포인트에 모든 Aurora 복사본이 포함되어 있고 새 연결을 위한 DNS 기반 라운드 로빈 로드 밸런싱을 제공하기 때문입니다.

각 해결 방법에서 다른 인스턴스 IP를 얻으려면 DNS를 캐싱하지 않고 엔드포인트를 계속 확인해야 합니다. 엔드포인트를 한 번만 해결하고 풀에 연결을 유지하면 해당 연결의 모든 쿼리가 동일한 인스턴스로 이동합니다. DNS를 캐싱하면 엔드포인트를 확인할 때마다 동일한 인스턴스 IP를 받게 됩니다.

모범 사례 따르기

네트워크 및 클라이언트 구성으로 인해 DNS 캐시 TTL이 더 이상 증가하지 않는지 확인하십시오. 어떤 형태로든 연결 풀링이나 기타 멀티플렉싱을 사용하는 경우 캐싱된 DNS 정보를 플러싱하거나 사용 시간을 줄여야 할 수 있습니다. 클라이언트 애플리케이션이 DB 인스턴스의 DNS 데이터를 캐싱하는 경우 TTL 값을 30초 미만으로 설정하십시오.
Amazon Relational Database Service(Amazon RDS) 프록시를 사용하여 연결을 관리합니다. 자세한 내용은, Amazon RDS 프록시 사용을 참조하세요.
스마트 드라이버 사용 모범 사례를 검토하세요.
Elastic Load Balancing 또는 HA/Proxy와 같은 TCP 기반 로드 밸런서를 사용합니다.