ストリームを復元する

恒久的に失敗したストリームは、新しいストリームを作成しなくても復元できます。 これを行うには、Datastream がソースからの変更の読み取りを再開しようとする位置を指定します。

ストリーム復元の概要

実行中のストリームで回復不能なエラーが発生すると、ステータスが FAILED_PERMANENTLY に変更されることがあります。このようなエラーではストリームの実行を継続できなくなり、データが失われる可能性があります。

ストリームを再作成して過去のデータをバックフィルするのではなく、エラーを無視して進行中のイベントの読み取りを継続するように設定することで、永続的に失敗したストリームを復元できます。恒久的に失敗したストリームを復元するには、レプリケーションをリセットして、別のレプリケーション位置からの読み取りを開始します。サポートされている各ソースタイプには、レプリケーション位置の独自の定義があります。

• Oracle ソースの場合、レプリケーション位置はデータベース内の REDO ログファイルとこのファイル内のシステム変更番号（SCN）です。
• MySQL ソースの場合、レプリケーション位置はデータベース バイナリログ（binlog）ファイルとこのファイル内の位置です。
• SQL Server ソースの場合、レプリケーション位置はトランザクション ログまたは変更テーブル内のログシーケンス番号（LSN）です。
• PostgreSQL ソース（AlloyDB for PostgreSQL を含む）の場合、レプリケーション位置はレプリケーション スロットのログシーケンス番号（LSN）になります。復元中、ストリームはレプリケーション スロットの最初の LSN から読み取りを開始します。

MySQL または Oracle ソースのストリームを復元する

MySQL または Oracle ソースのストリームを復元するには、次の方法があります。

• 現在の位置から再試行する（推奨）: ストリームが最後に失敗した現在の位置からストリーミングを試みるには、このオプションを選択します。 ログファイルを修正するか、バックアップから復元する必要があります。これが推奨のオプションです。

• 現在の位置をスキップして次の使用可能な位置からストリーミングする: 1 つ以上のログファイルがない場合、これらのファイルをスキップし、次に利用可能なファイルの最初の位置からストリーミングを再開します。不足しているログファイルの変更が失われますが、バックフィルを実行することで復元できます。

• 現在の位置をスキップして最新の位置からストリーミングする: 1 つ以上のログファイルがない場合、これらのファイルをスキップして、最も新しいログファイルの最新の位置からストリーミングを再開します。不足しているログファイルの変更は失われますが、バックフィルを実行することで復元できます。

• 指定のストリーミング ファイルと位置から再開する: このオプションを選択すると、特定のログファイルとログの位置からストリーミングが再開されます。指定したログ位置が消失したログ位置と重なっておらず、直後でもない場合、いくつかの変更が失われる可能性があります。バックフィルを実行することで、これらの変更を復元できます。

恒久的に失敗した、MySQL または Oracle ソースのストリームを復元するには、次の手順を行います。

1. Google Cloud の [ストリーム] ページに移動します。

   [ストリーム] ページに移動

2. 復元するストリームの名前の行で [復元] をクリックします。

3. [復旧戦略を選択] ペインが開きます。オプションを選択します。[指定のストリーミング ファイルと位置から再開する] を選択した場合は、次のように入力します。

   • MySQL ソースの場合: [ファイル名] フィールドのログファイル名と [位置] フィールドのログ位置。位置を指定しないと、指定されたログファイルの最初の位置からストリーミングが再開されます。
   • Oracle ソースの場合: [システム変更番号（SCN）] フィールドのシステム変更番号（SCN）。この項目は必須です。

4. [適用] をクリックします。

5. ストリームが復元されると、[ストリーム] ページの [復元済み] 列にタイムスタンプが表示されます。

PostgreSQL ソースのストリームを復元する

PostgreSQL ソースのストリームを復元するには、レプリケーション スロット名を指定する必要があります。サーバーはこのレプリケーション スロットを使用して、イベントを Datastream に送信します。レプリケーション スロット名は、失敗したストリームに使用されたスロットと同じでも、異なる場合でもかまいません。

• 新しいレプリケーション スロットが別の名前の場合は、新しいレプリケーション スロット名を Datastream で指定します。

• レプリケーション スロット名を指定しない場合、Datastream はソース構成で指定されたレプリケーション スロット名を使用します。

  レプリケーション スロットの詳細については、ソース PostgreSQL データベースの構成をご覧ください。

ログの位置を失ってから新しいレプリケーション スロットの最初の LSN までに発生したソースの変更イベントは失われます。バックフィルを実行することで、これらの変更を復元できます。

恒久的に失敗した、PostgreSQL ソースのストリームを復元するには、次の手順を行います。

1. Google Cloud の [ストリーム] ページに移動します。

   [ストリーム] ページに移動

2. 復元するストリームの名前の行で [復元] をクリックします。

3. [新しいレプリケーション スロットを定義する] ペインが開きます。

4. [レプリケーション スロット名] フィールドに、ストリームが復元を試みる新しいレプリケーション スロットの名前を指定します。同じ名前を使用してレプリケーション スロットを再作成した場合、またはソースの構成時に指定したスロットを再利用する場合は、このフィールドを空白のままにします。

5. [適用] をクリックします。

6. ストリームが復元されると、[ストリーム] ページの [復元済み] 列にタイムスタンプが表示されます。

[ストリームの詳細] ページから、恒久的に失敗したストリームを復元することもできます。これを行うには、ストリームの詳細情報を表示しているときに [ストリームを復元] をクリックします。

注: Datastream API を使用してストリームを復元する方法については、ストリームの管理をご覧ください。

SQL Server ソースのストリームを復元する

SQL Server ソースのストリームを復元するには、次の方法があります。

• 使用可能な最初の位置から再開する: ログが切り捨てられている場合や、変更テーブルに一部のレコードが欠落している場合に、開始可能な最初のイベントから再開するには、このオプションを選択します。不足しているイベントは失われますが、バックフィルを実行することで復元できます。

• 指定したログ シーケンス番号（LSN）から再開する: トランザクション ログまたは変更テーブル内の特定の LSN からストリームを再開するには、このオプションを選択します。指定した LSN が、Datastream が取得できた最後の LSN と重複していないか、その直後にない場合、一部のイベントが失われる可能性があります。バックフィルを実行することで、これらの変更を復元できます。

  トランザクション ログと変更テーブルの両方の LSN には 20 個の 16 進数文字が含まれますが、トランザクション ログの場合は区切り文字で区切られています。次に例を示します。

  • トランザクション ログの LSN: 0000123C:0000BA78:0004
  • 変更テーブルの LSN: 0000123C0000BA780004

恒久的に失敗した SQL Server ソースのストリームを復元するには、次の操作を行います。

1. Google Cloud の [ストリーム] ページに移動します。

   [ストリーム] ページに移動

2. 復元するストリームの名前の行で [復元] をクリックします。

3. [復旧戦略を選択] ペインが開きます。オプションを選択します。

4. [適用] をクリックします。

5. ストリームが復元されると、[ストリーム] ページの [復元済み] 列にタイムスタンプが表示されます。

手動フェイルオーバー シナリオで MySQL ソースのストリーム復元を使用する

手動フェイルオーバーを行い、ストリーム復元を使用して、メンテナンスやプライマリ インスタンスの障害時にストリームがゼロから再作成されないようにできます。一般に、Datastream はバイナリログの継続性を損なうため、レプリカへのフェイルオーバーをサポートしていませんが、次の手順に従ってストリームを復元し、変更データが確実にキャプチャされるようにできます。

1. プライマリ インスタンスへの書き込みをすべて停止します。
2. データの更新頻度指標が 0 に設定されていることを確認します。つまり、Datastream がすべての変更をキャプチャし、ソースから読み取る新しいイベントがないことを意味します。詳細については、ストリームをモニタリングするをご覧ください。
3. 新しいデータベース インスタンスにフェイルオーバーします。
4. 必要に応じて、ストリームの接続プロファイルを新しいデータベース インスタンスに更新します（たとえば、データベースのホスト名または IP アドレスを変更する必要がある場合があります）。詳細については、接続プロファイルを変更するをご覧ください。
5. フェイルオーバー インスタンスの特定の位置からストリームを復元して、CDC の継続性を確保します。

次のステップ

• ストリームの状態の詳細については、ストリームのライフサイクルをご覧ください。
• ストリームに関する情報を表示する方法については、ストリームを表示するをご覧ください。
• ストリームをモニタリングする方法については、ストリームをモニタリングするをご覧ください。
• ストリームのバックフィルを管理する方法については、ストリームのオブジェクトのバックフィルを管理するをご覧ください。
• 既存のストリームを削除する方法については、ストリームを削除するをご覧ください。