新しいストリームを作成しなくても、恒久的に失敗したストリームを復元できます。これを行うには、Datastream がソースからの変更の読み取りを再開する位置を指定します。
ストリーム復元の概要
実行中のストリームで回復不能なエラーが発生し、その状態が FAILED_PERMANENTLY に変更される場合があります。このようなエラーにより、ストリームの実行を続行できなくなり、データが失われる可能性があります。
ストリームを再作成して履歴データをバックフィルするのではなく、エラーを無視して進行中のイベントを読み続けるように設定することで、恒久的に失敗したストリームを復元できます。完全に失敗したストリームを復元するには、レプリケーションをリセットして、別のレプリケーション位置から読み取りを開始します。サポートされている各ソースタイプには、レプリケーション位置の独自の定義があります。
- Oracle ソースの場合、レプリケーション位置はデータベース内の REDO ログファイルとこのファイルのシステム変更番号（SCN）になります。
- MySQL ソースの場合、レプリケーション位置はデータベース バイナリログ（binlog）ファイルとこのファイル内の位置です。
- PostgreSQL ソース（AlloyDB for PostgreSQL を含む）の場合、レプリケーション位置はレプリケーション スロットのログシーケンス番号（LSN）になります。復元中、ストリームはレプリケーション スロットの最初の LSN から読み取りを開始します。
MySQL または Oracle ソースのストリームを復元する
MySQL または Oracle ソースのストリームを復元するには、次の方法があります。
現在の位置から再試行する（推奨）: このオプションを選択すると、ストリームが最後に失敗した現在の位置からストリーミングが試行されます。まず、ログファイルを修正するか、バックアップから復元する必要があります。これが推奨のオプションです。
現在の位置をスキップして次の使用可能な位置からストリーミングする: 1 つ以上のログファイルがない場合、これらのファイルをスキップし、次に利用可能なファイルの最初の位置からストリーミングを再開します。不足しているログファイルの変更が失われますが、バックフィルを実行することで復元できます。
現在の位置をスキップして最新の位置からストリーミングする: 1 つ以上のログファイルがない場合、これらのファイルをスキップして、最も新しいログファイルの最新の位置からストリーミングを再開します。不足しているログファイルの変更は失われますが、バックフィルを実行することで復元できます。
指定のストリーミング ファイルと位置から再開する: このオプションを選択すると、特定のログファイルとログの位置からストリーミングが再開されます。指定したログ位置が消失したログ位置と重なっておらず、直後でもない場合、いくつかの変更が失われる可能性があります。バックフィルを実行することで、これらの変更を復元できます。
恒久的に失敗した、MySQL または Oracle ソースのストリームを復元するには、次の手順を行います。
Google Cloud の [ストリーム] ページに移動します。
復元するストリームの左側にあるチェックボックスをオンにします。
[復元] をクリックします。
[復元戦略の選択] ペインが開きます。オプションを選択します。[選択したストリーミング ファイルと位置から再開する] を選択した場合は、次のように入力します。
- MySQL ソースの場合: [ファイル名] フィールドのログファイル名と [位置] フィールドのログ位置。位置を指定しないと、指定されたログファイルの最初の位置からストリーミングが再開されます。
- Oracle ソースの場合: [システム変更番号（SCN）] フィールドのシステム変更番号（SCN）。この項目は必須です。
[適用] をクリックします。
ストリームが復元されると、[ストリーム] ページの [復元済み] 列にタイムスタンプが表示されます。
PostgreSQL ソースのストリームを復元する
PostgreSQL ソースのストリームを復元するには、レプリケーション スロット名を指定する必要があります。サーバーはこのレプリケーション スロットを使用して、イベントを Datastream に送信します。レプリケーション スロット名は、失敗したストリームで使用されているスロット名と同じでも異なっていてもかまいません。
- 新しいレプリケーション スロットの名前が異なる場合は、新しいレプリケーション スロットの名前を Datastream に渡します。詳細については、PostgreSQL ソースのストリームを復元するをご覧ください。
- レプリケーション スロット名を指定しない場合、Datastream はソース構成で指定されたレプリケーション スロット名を使用します。詳細については、ソース PostgreSQL データベースの構成をご覧ください。
ログの位置を失ってから新しいレプリケーション スロットの最初の LSN までに発生したソースの変更イベントは失われます。バックフィルを実行することで、これらの変更を復元できます。
恒久的に失敗した、PostgreSQL ソースのストリームを復元するには、次の手順を行います。
Google Cloud の [ストリーム] ページに移動します。
復元するストリームの左側にあるチェックボックスをオンにします。
[復元] をクリックします。
[新しいレプリケーション スロットの定義] ペインが開きます。
[レプリケーション スロット名] フィールドに、ストリームの復元を試みる新しいレプリケーション スロットの名前を入力します。同じ名前を使用してレプリケーション スロットを再作成した場合、またはソースの構成時に指定したスロットを再利用する場合は、このフィールドを空のままにしておくことができます。
[適用] をクリックします。
ストリームが復元されると、[ストリーム] ページの [復元済み] 列にタイムスタンプが表示されます。
[ストリームの詳細] ページから、恒久的に失敗したストリームを復元することもできます。これを行うには、ストリームに関する詳細情報を表示する際に、[ストリームを復元] をクリックします。
手動フェイルオーバー シナリオで MySQL ソースのストリーム復元を使用する
手動フェイルオーバーを行い、ストリーム復元を使用して、メンテナンスやプライマリ インスタンスの障害時にストリームがゼロから再作成されないようにできます。一般に、Datastream はバイナリログの継続性を損なうため、レプリカへのフェイルオーバーをサポートしていませんが、次の手順に従ってストリームを復元し、変更データが確実にキャプチャされるようにできます。
- プライマリ インスタンスへの書き込みをすべて停止します。
- データの更新頻度指標が 0 に設定されていることを確認します。これは、Datastream がすべての変更をキャプチャし、ソースから読み取る新しいイベントがないことを意味します。詳細については、ストリームのモニタリングをご覧ください。
- 新しいデータベース インスタンスにフェイルオーバーします。
- 必要に応じて、ストリームの接続プロファイルを新しいデータベース インスタンスに更新します（たとえば、データベース ホスト名や IP アドレスの変更が必要になることがあります）。詳細については、接続プロファイルの変更をご覧ください。
- フェイルオーバー インスタンスの特定の位置からストリームを復元して CDC の継続性を確保します。