스트림 복구

새 스트림을 만들지 않고 영구적으로 실패한 스트림을 복구할 수 있습니다. 이렇게 하려면 Datastream이 소스에서 변경사항 읽기를 재개할 위치를 지정하면 됩니다.

스트림 복구 개요

실행 중인 스트림에 복구할 수 없는 오류가 발생하여 상태가 FAILED_PERMANENTLY로 변경될 수 있습니다. 이러한 오류는 스트림이 계속 실행되지 않도록 만들고 데이터 손실을 일으킬 수 있습니다.

이 오류를 무시하도록 설정하여 영구적으로 실패한 스트림을 복구할 수 있으며, 스트림을 다시 만들고 이전 데이터를 백필하는 대신 진행 중인 이벤트를 계속 읽을 수 있습니다. 영구적으로 실패한 스트림을 복구하려면 다른 복제 위치에서 읽기를 시작하도록 복제를 재설정합니다. 지원되는 각 소스 유형은 복제 위치에 대한 자체 정의를 포함합니다.

Oracle 소스의 경우 복제 위치는 데이터베이스의 재실행 로그 파일이고 이 파일의 시스템 변경 번호(SCN)입니다.
MySQL 소스의 경우 복제 위치는 데이터베이스 바이너리 로그(binlog) 파일이고 이 파일의 위치입니다.
SQL Server 소스의 경우 복제 위치는 트랜잭션 로그 또는 변경 테이블의 로그 시퀀스 넘버(LSN)입니다.
PostgreSQL 소스(PostgreSQL용 AlloyDB 포함)의 경우 복제 위치는 복제 슬롯에 있는 로그 시퀀스 넘버(LSN)입니다. 복구 중 스트림은 복제 슬롯의 첫 번째 LSN에서 읽기를 시작합니다.

MySQL 또는 Oracle 소스의 스트림 복구

MySQL 또는 Oracle 소스의 스트림을 복구할 때 사용할 수 있는 옵션은 다음과 같습니다.

현재 위치에서 재시도(권장): 스트림이 실패한 현재 위치에서 스트리밍을 시도하려면 이 옵션을 선택합니다. 로그 파일을 수정하거나 백업에서 먼저 복구해야 합니다. 이 옵션은 권장 옵션입니다.
현재 위치를 건너뛰고 사용 가능한 다음 위치에서 스트리밍: 하나 이상의 로그 파일이 누락된 경우 이러한 파일을 건너뛰고 사용 가능한 후속 파일의 첫 번째 위치에서 스트리밍을 재개하려면 이 옵션을 선택합니다. 누락된 로그 파일의 변경사항이 손실되지만 백필을 수행하여 이를 복구할 수 있습니다.
현재 위치를 건너뛰고 최근 위치에서 스트리밍: 하나 이상의 로그 파일이 누락된 경우 이러한 파일을 건너뛰고 최신 로그 파일에 있는 최근 위치에서 스트리밍을 재개하려면 이 옵션을 선택합니다. 누락된 로그 파일의 변경사항이 손실되지만 백필을 수행하여 이를 복구할 수 있습니다.
원하는 스트리밍 파일 및 위치에서 재개: 특정 로그 파일 및 로그 위치에서 스트림을 재개하려면 이 옵션을 선택합니다. 지정된 로그 위치가 손실된 로그 위치와 겹치거나 즉시 이어지지 않으면 일부 변경사항이 손실될 수 있습니다. 백필을 수행하여 이러한 변경사항을 복구할 수 있습니다.

MySQL 또는 Oracle 소스의 영구적으로 실패한 스트림을 복구하려면 다음 단계를 수행합니다.

Google Cloud의 스트림 페이지로 이동합니다.

스트림 페이지로 이동
복구하려는 스트림의 이름이 있는 행에서 복구를 클릭합니다.
복구 전략 선택 창이 열립니다. 옵션을 선택합니다. 원하는 스트리밍 파일 및 위치에서 다시 시작을 선택한 경우 다음을 입력합니다.
- MySQL 소스: 파일 이름 필드의 로그 파일 이름 및 위치 필드의 로그 위치. 위치를 지정하지 않으면 표시된 로그 파일의 첫 번째 위치에서 스트림이 재개됩니다.
- Oracle 소스: 시스템 변경 번호(SCN) 필드의 시스템 변경 번호(SCN)입니다. 필수 입력란입니다.
적용을 클릭합니다.
스트림이 복구되면 스트림 페이지의 복구됨 열에 타임스탬프가 표시됩니다.

PostgreSQL 소스의 스트림 복구

PostgreSQL 소스의 스트림을 복구하려면 복제 슬롯 이름을 제공해야 합니다. 서버는 이 복제 슬롯을 사용하여 Datastream에 이벤트를 전송합니다. 복제 슬롯 이름은 실패한 스트림에 사용된 슬롯과 동일하거나 다를 수 있습니다.

새 복제 슬롯의 이름이 다르면 Datastream에 새 복제 슬롯 이름을 제공합니다.
복제 슬롯 이름을 제공하지 않으면 Datastream이 소스 구성에 지정된 복제 슬롯 이름을 사용합니다.

복제 슬롯에 대한 자세한 내용은 소스 PostgreSQL 데이터베이스 구성을 참조하세요.

로그 위치 손실과 새 복제 슬롯의 첫 번째 LSN 사이에 발생한 소스에 대한 변경 이벤트는 모두 손실됩니다. 백필을 수행하여 이러한 변경사항을 복구할 수 있습니다.

PostgreSQL 소스의 영구적으로 실패한 스트림을 복구하려면 다음 단계를 수행합니다.

Google Cloud의 스트림 페이지로 이동합니다.

스트림 페이지로 이동
복구하려는 스트림의 이름이 있는 행에서 복구를 클릭합니다.
새 복제 슬롯 정의 창이 열립니다.
복제 슬롯 이름 필드에 스트림이 복구할 새 복제 슬롯의 이름을 입력합니다. 동일한 이름을 사용하여 복제 슬롯을 다시 만들었거나 소스를 구성할 때 지정한 슬롯을 재사용하려면 이 필드를 비워 둡니다.
적용을 클릭합니다.
스트림이 복구되면 스트림 페이지의 복구됨 열에 타임스탬프가 표시됩니다.

스트림 세부정보 페이지에서 영구적으로 실패한 스트림을 복구할 수도 있습니다. 이렇게 하려면 스트림에 대한 세부 정보를 확인할 때 스트림 복구를 클릭합니다.

SQL Server 소스의 스트림 복구

SQL Server 소스의 스트림을 복구할 때 옵션은 다음과 같습니다.

사용 가능한 첫 번째 위치에서 재개: 로그가 잘렸거나 변경 테이블에서 일부 레코드가 누락되었고 사용 가능한 첫 번째 이벤트에서 재개하려면 이 옵션을 선택합니다. 누락된 이벤트가 손실되지만 백필을 수행하여 이를 복구할 수 있습니다.
원하는 로그 시퀀스 번호(LSN)에서 재개: 트랜잭션 로그 또는 변경 테이블의 특정 LSN에서 스트림을 재개하려면 이 옵션을 선택합니다. 지정된 LSN이 Datastream이 검색할 수 있는 마지막 LSN과 겹치거나 즉시 이어지지 않으면 일부 이벤트가 손실될 수 있습니다. 백필을 수행하여 이러한 이벤트를 복구할 수 있습니다.

트랜잭션 로그와 변경 테이블 모두의 LSN에는 20개의 16진수 문자가 포함되어 있지만 트랜잭션 로그의 경우 구분자로 구분됩니다. 예를 들면 다음과 같습니다.
- 트랜잭션 로그의 LSN: 0000123C:0000BA78:0004
- 변경 테이블의 LSN: 0000123C0000BA780004

SQL Server 소스의 영구적으로 실패한 스트림을 복구하려면 다음 단계를 수행합니다.

Google Cloud의 스트림 페이지로 이동합니다.

스트림 페이지로 이동
복구하려는 스트림의 이름이 있는 행에서 복구를 클릭합니다.
복구 전략 선택 창이 열립니다. 옵션을 선택합니다.
적용을 클릭합니다.
스트림이 복구되면 스트림 페이지의 복구됨 열에 타임스탬프가 표시됩니다.

수동 장애 조치 시나리오에서 MySQL 소스에 스트림 복구 사용

수동 장애 조치를 수행하고 스트림 복구를 사용하여 유지보수 또는 기본 인스턴스 장애 발생 시 스트림을 처음부터 다시 만들지 않을 수 있습니다. 일반적으로 Datastream은 바이너리 로그 연속성을 손상시키므로 복제본에 대한 장애 조치를 지원하지 않지만, 다음 단계를 따라 스트림을 복구하고 변경 데이터가 캡처되도록 할 수 있습니다.

기본 인스턴스에 대한 모든 쓰기를 중지합니다.
데이터 최신 상태 측정항목이 0으로 설정되었는지 확인합니다. 즉, Datastream이 모든 변경사항을 캡처했고 소스에서 읽을 새 이벤트가 없습니다. 자세한 내용은 스트림 모니터링을 참조하세요.
새 데이터베이스 인스턴스로 장애 조치합니다.
필요한 경우 스트림의 연결 프로필을 새 데이터베이스 인스턴스로 업데이트합니다(예: 데이터베이스 호스트 이름 또는 IP 주소를 변경해야 할 수 있음). 자세한 내용은 연결 프로필 수정을 참조하세요.
CDC 연속성을 보장하기 위해 장애 조치 인스턴스의 특정 위치에서 스트림을 복구합니다.

다음 단계

스트림 상태에 대한 자세한 내용은 스트림 수명 주기를 참조하세요.
스트림 정보를 확인하는 방법은 스트림 보기를 참조하세요.
스트림을 모니터링하는 방법은 스트림 모니터링을 참조하세요.
스트림의 백필을 관리하는 방법은 스트림 객체의 백필 관리를 참조하세요.
기존 스트림을 삭제하는 방법은 스트림 삭제를 참조하세요.