복원한 RDS가 available로 표시됩니다. 그런데 서비스에서 조회한 데이터는 여전히 기존 DB의 내용으로 보이는 경우가 간혹 있습니다. 복원 작업 시 진행 상태만 보고 애플리케이션까지 새 DB로 옮겨 갔다고 판단하면, 정작 뭘 확인해야될지 확인해야 할 접속 대상이 빠집니다.
복원 완료와 접속 전환의 차이
AWS의 스냅샷 복원 문서에 따르면 DB 스냅샷 복원은 기존 인스턴스를 덮어쓰는 방식이 아니라 DB 인스턴스를 새로 만드는 작업입니다. 따라서 기존 주소로 직접 접속하는 애플리케이션은 새 DB를 사용하도록 별도로 config를 변경해줘야 합니다. 여기서는 일반 RDS DB 인스턴스의 직접 연결을 기준으로 설명하며, Aurora나 프록시를 통한 연결은 구성을 따로 확인해야 합니다.
먼저 복원 목적을 정합니다. 데이터 확인용 복원이라면 운영 애플리케이션의 주소를 바꿀 이유가 없습니다. 운영 전환이라면 스냅샷 시점 이후 기존 DB에 들어온 데이터를 어떻게 처리할지부터 결정해야 합니다. 주소 변경은 그 차이를 자동으로 메워 주지 않습니다.
요약: 복원 목적과 데이터 기준 시점을 정한 뒤 접속 전환 여부를 결정합니다.
새 엔드포인트와 실행 설정 대조
RDS 콘솔에서 계정과 리전을 확인하고 복원한 DB를 선택합니다. MySQL 기준으로 Connectivity & security에서 엔드포인트와 포트를 확인할 수 있습니다. AWS 연결 정보 안내처럼 호스트에는 엔드포인트의 DNS 이름을 기재합니다. 인스턴스 식별자나 임의로 확인한 IP 주소를 그대로 접속 주소로 넣지 않습니다.
그다음 애플리케이션이 실제로 읽는 설정 위치를 찾습니다. 저장소의 설정 파일, 배포 환경변수, 컨테이너 실행 설정, 비밀정보 저장소 중 어디에서 호스트가 전달되는지 확인합니다. 여러 곳에 같은 항목이 있으면 해당 프레임워크의 우선순위와 실행 중인 값을 대조합니다. 설정 파일 하나를 고쳤다는 사실만으로 적용을 판정하지 않습니다.
가령 웹 서버 두 대와 야간 배치 한 개가 각각 DB 주소를 받는 구성이라면 세가지 시스템을 모두 확인해야 합니다. 점검표에는 실행 단위, 설정 출처, 변경 전후 호스트, 포트, DB 이름, 적용 방법등 일반적인 접근을 위한 정보만을 남기고 그 외 보안사항은 삭제합니다.
요약: 수정한 파일보다 실행 중인 프로세스가 사용하는 접속 설정이 판단 기준입니다.
연결 실패를 나누는 점검 순서
새 주소가 맞는데 연결되지 않으면 애플리케이션이 실행되는 환경에서 점검합니다. DNS resolution, 대상 포트 접근, DB 인증, 필요한 권한 순으로 범위를 좁히면 됩니다. AWS 연결 문제 해결 문서도 보안 그룹, 포트, 가용 상태 등을 구분합니다. 관리자 PC에서 접속되는 결과를 서버의 접속 가능 여부로 판단하면 안됩니다.
복원 DB의 VPC, 서브넷 그룹, 보안 그룹과 필요한 파라미터 그룹도 기존 구성과 비교합니다. 복원 과정에서 원하는 구성이 선택됐는지 확인하는 절차입니다. 접속이 안 된다는 이유로 DB를 곧바로 공개하거나 모든 출발지에 포트를 열기보다는, 애플리케이션의 접근 경로에 맞는 허용 범위를 점검합니다.
TCP 포트 연결 성공은 DB 로그인이나 SQL쿼리의 실행과 다릅니다. 인증 오류라면 사용 계정과 현재 자격 증명을 확인하고, DB 이름 오류나 권한 오류라면 연결 문자열과 필요한 작업 권한을 나눠 봅니다. TLS 사용 환경에서는 인증서 검증 설정도 함께 유지합니다.
요약: 주소·네트워크·인증·권한을 분리해야 불필요한 설정 변경을 줄일 수 있습니다.
기존 연결 정리와 업무 단위 검증
설정을 적용할 때는 연결 풀도 확인합니다. 연결 풀은 이미 만든 DB 연결의 reconntection을 지원합니다. 프로세스가 새 설정을 읽었더라도 기존 연결이 남는지는 제품과 적용 방식에 따라 다르므로, 재배포·설정 재로딩·연결 풀 재생성 중 필요한 방법을 선택합니다. 모든 환경에서 재시작이 필수라고 단정할 수는 없습니다.
전환 중 기존 DB와 복원 DB 양쪽에 쓰기가 나뉘지 않도록 웹 요청뿐 아니라 배치와 작업 큐의 쓰기도 통제합니다. 업무에서 허용한 점검 시간에 읽기 검증을 먼저 수행하고, 승인된 테스트 데이터로 쓰기와 재조회를 확인합니다. 실제 운영 데이터를 임의로 수정하는 방식은 피합니다.
확인 기록에는 적용한 호스트와 시각, 실행 단위별 결과, 새 DB의 세션·접속 기록 등 확보 가능한 증거를 연결합니다. 화면이 열렸다는 결과만으로는 캐시 응답인지 DB 조회인지 구별하기 어렵습니다. 기존 DB로 되돌릴 계획이라면 새 DB에 쓰기가 시작된 뒤 생긴 데이터 차이의 처리 방법까지 정해야 합니다.
요약: 전환 완료는 주소 변경이 아니라 실행 단위별 실제 접속과 업무 결과로 확인합니다.
자주 묻는 질문
기존 DB를 먼저 삭제해야 하나요?
새 DB 연결을 검증하기 전에 기존 DB를 삭제하는 순서는 피하는 편이 좋습니다. 보존 여부와 기간은 복구 계획에 따라 정하되, 보존한 기존 DB에 의도치 않은 쓰기가 계속되지 않는지도 확인합니다.
SELECT 1이 성공하면 검증이 끝나나요?
해당 연결에서 간단한 SQL이 실행된다는 뜻입니다. 목표 DB에 접속했는지 확인한 다음, 애플리케이션 계정으로 필요한 테이블 조회와 승인된 쓰기 작업까지 구분해 점검합니다.
사내 DNS 별칭을 쓰면 애플리케이션 설정은 그대로 둬도 되나요?
별칭을 통해 연결하는 구성이라면 별칭의 대상 변경으로 전환할 수 있는지 검토할 수 있습니다. 다만 DNS 캐시, 기존 연결, TLS 호스트명 검증 조건을 함께 확인해야 하며, 별칭 변경만으로 모든 연결이 즉시 이동한다고 보장할 수는 없습니다.
결론
RDS 복원 작업의 마지막 확인 대상은 콘솔 상태가 아니라 애플리케이션의 실제 접속입니다. 복원 목적과 데이터 시점을 정하고, 새 엔드포인트를 실행 설정과 대조한 뒤 연결 경로를 점검합니다. 이어서 웹·배치별 적용 결과와 업무 데이터를 확인하면, 어디까지 복구했고 무엇이 남았는지 구분할 수 있습니다.