ストリームを復元する

恒久的に失敗したストリームは、新しいストリームを作成しなくても復元できます。 これを行うには、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. ストリームが復元されると、[ストリーム] ページの [Recovered] 列にタイムスタンプが表示されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. ストリームが復元されると、[ストリーム] ページの [Recovered] 列にタイムスタンプが表示されます。

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

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

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

次のステップ