[AWS MySQL] AWS JDBC Driver for MySQL

-          AWS JDBC 드라이버를 사용하여 장애조치 시간 단축하기

 

l  Version : AWS MySQL, Aurora

 

 

Amazon Web Service (AWS) JDBC Driver for MySQL 사용하면 애플리케이션에서 클러스터된 MySQL 데이터베이스의 기능을 활용할 있다. AWS JDBC Driver for MySQL 오픈소스 MySQL JDBC Connector 기반으로 제작되었기 때문에 호환 가능하다.

l  mysql-connector-j : https://github.com/mysql/mysql-connector-j

l  aws-mysql-jdbc : https://github.com/awslabs/aws-mysql-jdbc

 

MySQL AWS JDBC Driver MySQL 호환되는 Amazon Aurora 대해서도 빠른 장애 조치를 지원한다. Amazon RDS for MySQL 온프레미스 MySQL 배포 기능을 포함하여 클러스터형 데이터베이스 추가 기능에 대한 지원이 계획되어 있다.

 

Amazon Aurora에서 장애 조치는 기본 DB 인스턴스를 사용할 없을 데이터베이스가 클러스터 상태를 자동으로 복구하는 메커니즘이다. 클러스터가 기본 쓰기-읽기 DB 인스턴스에 최대 가용성을 제공할 있도록 데이터베이스 복제본을 새로운 기본 DB 인스턴스로 선택하여 이를 달성한다. 복제본 인스턴스를 기본 DB 인스턴스 역할로 승격하려면 먼저 연결을 올바르게 지정하기 위해 DNS 레코드를 업데이트해야 한다. 프로세스는 최대 분이 소요될 있다.

 

MySQL AWS JDBC Driver 가동 중지 시간을 최소화하기 위해 동작을 최적화하여 설계되었다. MySQL 클러스터 토폴로지의 캐시와 인스턴스의 역할(복제본 또는 기본 DB 인스턴스) 유지함으로써 이를 달성한다. 토폴로지는 MySQL 데이터베이스에 대한 직접 쿼리를 통해 제공되어 DNS 확인으로 인한 지연을 우회하는 지름길을 제공한다. 이를 바탕으로 MySQL AWS JDBC Driver 데이터베이스 클러스터 상태를 보다 면밀히 모니터링하여 새로운 기본 DB 인스턴스에 대한 연결을 최대한 빨리 설정할 있다.

 

MySQL AWS JDBC Driver에는 연결 플러그인 관리자도 있다. 플러그인 관리자를 사용하면 개발자는 주요 드라이버 기능을 그대로 유지하면서 유연한 방식으로 드라이버 기능을 확장할 있다. 연결 플러그인 관리자는 연결에 대한 초기화, 트리거 연결 체인을 정리한다. 연결 플러그인은 해당 연결과 관련된 추가 또는 보완 논리를 실행하는 도움이 되도록 연결 개체에 연결된 위젯이다. Enhanced Failure Monitoring 기능은 연결 플러그인 하나이다. 아래 그림은 연결 플러그인 관리자의 간소화된 워크플로를 보여준다.

드라이버가 JDBC 메소드를 실행할 때마다 연결 플러그인 관리자로 전달된다. Connection Plugin Manager에서 JDBC 메소드가 Plugin 순서대로 전달되어 체인처럼 로드 된다. 예제에서는 메서드는 먼저 Custom Plugin A 전달되고, 다음으로 Custom Plugin B 전달되고, 마지막으로 Default Plugin으로 전달된다. 플러그인은 JDBC 메소드를 실행하고 체인을 통해 결과를 다시 반환한다.

 

Enhanced Failure Monitoring 모니터 스레드에 의해 구현된 연결 플러그인으로 MySQL AWS JDBC Driver 향상된 장애 조치를 지원한다. 모니터는 연결된 데이터베이스 노드의 상태를 주기적으로 확인한다. 데이터베이스 노드가 비정상인 것으로 확인되면 데이터베이스 노드로 쿼리가 재시도되고 모니터가 다시 시작된다. 기본적으로 Enhanced Failure Monitoring 플러그인이 로드 된다. 그러나 Amazon RDS Proxy 사용하는 경우에는 향상된 장애 조치가 필요하지 않으며 RDS Proxy드라이버가 처리한다.

 

아래 표는 Aurora MySQL 5.7(2.10.0) 사용하여 AWS JDBC Driver for MySQL MariaDB Connector/J(Aurora 인식하도록 구성됨) 간의 장애 조치 시간을 벤치마킹한 결과이다. 데이터베이스에 연결되고 1초마다 테이블에 대해 쿼리를 실행하는 간단한 Java 앱을 실행한다음 Amazon RDS 콘솔을 통해 기본 데이터베이스에 장애 조치 명령이 실행되었다. 경우 모두 드라이버가 복제본에 자동으로 다시 연결되었지만 MySQL AWS JDBC Driver 오류를 인식하고 연결하는데 훨씬 빠르게 동작하였다.

 

벤치 마크 결과를 살펴보면 AWS JDBC Driver for MySQL 오류 감지에 평균 2, 복제본에 연결에 평균2초를 수행하여 최종 읽기까지의 중단 시간은 4초가 소요되었다.

MySQL 5.7 AWS JDBC Driver for MySQL MariaDB Connector/J Driver
Average Client Failure Detection 2 seconds 19 seconds
Average Reconnect Time 2 seconds 18 seconds
Total Reconnect Time 4 seconds 37 seconds

 

 

AWS JDBC 드라이버를 RDS Proxy 함께 사용할 주의해야할 부분이 있다. Enhanced Failure Monitoring 플러그인이 포함된 MySQL AWS JDBC Driver 함께 RDS Proxy 엔드포인트를 함께 사용할 경우 심각한 문제가 발생하지는 않지만 함께 사용을 권장하지는 않는다. 이유는 RDS Proxy 드라이버 요청을 데이터베이스 인스턴스 하나로 투명하게 다시 라우팅하기 때문이다. RDS Proxy 여러 기준에 따라 어떤 데이터베이스 인스턴스가 사용되는지를 결정한다. 이러한 결정 전환은 인스턴스 상태 모니터링 측면에서 플러그인을 쓸모 없게 만든다. 플러그인은 연결된 실제 인스턴스와 모니터링 중인 인스턴스를 식별할 없기 때문에 오류 감지에 대해서 오탐지의 원인이 있다. 동시에 플러그인은 여전히 ​​RDS Proxy 엔드포인트에 대한 네트워크 연결을 사전에 모니터링하고 중단이 발생할 경우 사용자 애플리케이션에 다시 보고할 있기 때문이다. 따라서 Enhanced Failure Monitoring 플러그인을 사용할 때에는 RDS Proxy 엔드포인트를 사용하지 않는 것이 좋다.

 

 

[참고자료]

l  https://awslabs.github.io/aws-mysql-jdbc/

l  https://aws.amazon.com/blogs/database/improve-application-availability-with-the-aws-jdbc-driver-for-amazon-aurora-mysql/

l  https://github.com/awslabs/aws-mysql-jdbc#the-aws-jdbc-driver-failover-process

 

 

 

2022-03-27 / Sungwook Kang / http://sungwookkang.com

 

 

AWS JDBC Driver, MySQL Connector, AWS JDBC, MySQL Failover, 장애조치, AWS 장애조치

SQL Server 2016 향상된 가용성 그룹데이터베이스 수준의 상태 탐지 장애조치

 

·         Version : SQL Server 2016, SQL Server 2017

 

SQL Server2016에서 도입된 가용성 그룹(Availability Group) 대한 데이터베이스 수준 상태 탐지 장애 조치 (Database Level Failover) 옵션은 가용성 그룹에 있는 하나 이상의 데이터베이스에 문제가 있을 경우 가용성 그룹에 장애 조치 메커니즘을 실행시키기 위해 도입되었다. 기능을 사용하면 데이터베이스의 고가용성을 보장할 있으며 업무상 중요한 데이터베이스가 있는 모든 가용성 그룹에 권장되는 최상의 방법이다.

데이터베이스 수준 상태 탐지 장애조치의 초기 구현에서는 가용성 그룹의 복제본에서 다음 조건을 검사 하도록 설계 되었다.

·         DB Status 온라인 상태인가?

·         데이터베이스의 트랜잭션 로그 파일에 트랜잭션 쓰기를 사용할 있는가?

조건중 하나라도 true 아닌 경우 데이터베이스를 호스팅하는 가용성 그룹은 사용 가능한 동기(동기화) 보조 노드 하나에 장애조치가 된다.

 

과거에는 사용자가 하드웨어 문제 때문에 발생하는 오류와 같은 추가 검사를 진행하였으나 최신 서비스 릴리즈에서는 데이터베이스 수준의 상태 확인 검사의 일부로 포함될수 있다. SQL Server 최신 서비스 릴리스는 아래 링크를 참고한다.

·         SQL2017RTM CU9

 https://support.microsoft.com/en-us/help/4341265/cumulative-update-9-for-sql-server-2017

·         SQL2016SP1 CU10

 https://support.microsoft.com/en-us/help/4341569/cumulative-update-10-for-sql-server-2016-sp1

·         SQL2016SP2 CU2

 https://support.microsoft.com/en-us/help/4340355/cumulative-update-2-for-sql-server-2016-sp2

 

만약 릴리즈 적용이후 이전 상태로 되돌릴경우 사용자는 TF9576 시작 매개변수로 사용하거나 DBCC TRACEON 명령을 사용한다. 글을 쓰는 현재 시점에는 윈도우에서만 가능하지만 추후 Linux 버전의  SQL Server 2017에도 적용될 예정이다.

 

기존 검사외에 새로운 구현에는 다음과 같은 추가 검사가 있다.

1.       데이터베이스 상태 정보를  스냅샷으로 저장하고 사용하여 AG 오류 상태로 표시되어야 하는지 여부를 결정한다. 상태 검사 루틴은 데이터베이스 상태 관련 오류 정보를 마지막 번의 실행 결과를 캐시한 다음 현재 상태 검사 루틴의 실행 상태 정보와 비교한다. 상태 탐지 루틴의 번의 연속 실행중에 동일한 오류 조건(아래 언급된 오류코드) 존재하면 장애조치가 시작된다.

2.       아래 목록의 추가 오류를 확인한다. 이러한 오류의 대부분은 서버의 하드웨어 문제를 나타낸다. 아래 목록이 데이터베이스 가용성에 영향을 있는 모든 오류 목록은 아니다.

Error

Cause

Documentation

605

페이지 또는 할당 손상

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-605-database-engine-error?view=sql-server-2017

823

검사점 실패

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-823-database-engine-error?view=sql-server-2017

829

디스크 손상

 

832

하드웨어 또는 메모리 손상

 

1101

파일 그룹에 사용가능한 디스크 공간 부족

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-1101-database-engine-error?view=sql-server-2017

1105

파일 그룹에 사용 가능한 디스크 공간부족

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-1105-database-engine-error?view=sql-server-2017

5102

누락된 파일 그룹 ID 요청

 

5108

잘못된 파일 ID 요청

 

5515

 

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-5515-database-engine-error?view=sql-server-2017

5534

FILESTREAM 작업 로그 레코드로 인해 로그가 손상됨

 

5535

FILESTREAM 데이터 컨테이너가 손상됨

 

9004

로그 손상

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-9004-database-engine-error?view=sql-server-2017

 

 

 

 

2018-08-27 / Sungwook Kang / http://sqlmvp.kr

 

SQL Server, MSSQL, AlwaysOn, SQL Failover, SQL Server Availability Group, 가용성 그룹, SQL 가용성 그룹, 장애조치, 향상된 가용성 그룹


.NET 4.6.1에 변경된 Multisubnet 기본 수신기 동작

  • Version : SQL Server 2012, 2014, 2016

 

SQL Server에서 AlwaysOn을 구성하여 사용할 때 리스너는 여러 개의 IP 주소를 감지하여 가용성 그룹에 정의되어 있는 IP주소에 연결을 시도하는데 간헐적으로 연결시간 초과가 발생할 수 있다. SQL 클라이언트의 기본 동작은 DNS에서 반환된 모든 IP 주소에 연결을 시도하는데 DNS 구성에 의존하기 때문에 몇 가지 문제가 발생할 수 있다. 가장 빈번하게 발생하는 문제가 정확하지 않은 IP 반환 또는 온라인되어 있지 않은 IP 반환이다. 기본적으로 TCP 연결 시도에 대한 기본 제한시간은 21초이며 IP 주소가 온라인 상태가 아닌 경우 다음 IP를 시도하기까지 21초를 기다려야 한다.

 

.NET 4.6.1에 업데이트된 내용은 SQL 클라이언트 제공자의 기본값이 MultiSubnetFailover=True 이며 이 동작은 모둔 IP 주소를 검색하고 병렬로 모든 연결을 시도한다. IP가 온라인 상태이면 성공적으로 연결이 되며 장애조치의 경우 가용성 그룹에 다시 연결하는 최적의 방법으로 동작한다.

 

자세한 업데이트 내용 및 .NET 패키지 다운로드는 아래 링크를 참고 한다.

http://blogs.msdn.com/b/dotnet/archive/2015/11/30/net-framework-4-6-1-is-now-available.aspx

 

새로운 릴리즈를 적용하지 않아도 이전의 SQL Server 2012 가용성 그룹 수신기 또는 장애조치 클러스터 인스턴스 연결을 사용할 때 MultiSubnetFailover=True를 지정하면 장애조치 클러스터 인스턴스 또는 모든 가용성 그룹에 대해 병렬로 연결을 시도하여 서브넷 장애조치가 시행 되는동안 신속하게 TCP 연결을 다시 시도한다.

 

[참고자료]

http://blogs.msdn.com/b/alwaysonpro/archive/2015/12/01/improved-multisubnet-listener-behavior-with-newly-released-sql-client-provider-in-net-4-6-1.aspx

 

2015-12-04 / 강성욱 / http://sqlmvp.kr

 

 

SQL Server, AlwaysOn, 가용성 그룹, Multisibnet, Failover Cluster, 장애조치, 고가용성, 멀티서브넷, SQL 클라이언트 공급자

+ Recent posts