Datastream を使用する場合の一般的なベスト プラクティス

Datastream で信頼性の高いレプリケーションを維持し、ダウンタイムを最小限に抑えるには、ストリームとソース データベース全体に運用上のベスト プラクティスを適用します。これらのプラクティスは、ストリームのソース データベースの切り替え、指標アラートの構成、レイテンシのトラブルシューティング、ストリームごとのテーブル上限の計画に役立ちます。

ストリームのソース データベースを変更する

場合によっては、ストリームのソース データベースを変更する必要があります。たとえば、プライマリ データベース インスタンスではなくレプリカからレプリケートするようにストリームを変更する必要がある場合があります。

  1. レプリカ インスタンスの接続プロファイルを作成します。
  2. 作成したレプリカの接続プロファイルと、宛先の既存の接続プロファイルを使用して、ストリームを作成します。
  3. 履歴バックフィルを無効にしてストリームを開始します。ストリームが開始されると、バイナリログのデータのみが取得されます。
  4. 省略可。ストリームの実行後、ストリームを変更して自動バックフィルを有効にします。
  5. プライマリ インスタンスからの読み取り用のストリームを一時停止します。
  6. 省略可。プライマリ インスタンスからデータをストリーミングしていたストリームを削除します。
  7. 省略可。プライマリ インスタンスの接続プロファイルを削除します。

Datastream でのアラートとモニタリング

Datastream ダッシュボードには、多くの情報が表示されます。この情報は、デバッグに役立ちます。詳細については、Cloud Logging で確認できるログをご覧ください。

Datastream アラート

Datastream にはデフォルトのアラートが設定されていません。たとえば、[概要] タブの [アラート ポリシーを作成] リンクをクリックして、データの更新速度指標のアラート ポリシーを作成できます。残りの指標については、次の手順を行います。

  1. Google Cloud コンソールで、[ アラート] ページに移動します。

    アラートに移動

  2. [ポリシーを作成] をクリックします。

  3. [指標を選択] プルダウンをクリックします。

  4. [フィルタ] フィールドに「Datastream」と入力します。

  5. 省略可: 使用可能なすべての指標を表示するには、[アクティブ] フィルタを無効にする必要があります。

  6. [Datastream Stream] で、モニタリングする指標を検索します。

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

  8. 省略可: [フィルタを追加] セクションと [データを変換] セクションに必要な詳細を入力します。[次へ] をクリックします。

  9. [Configure alert trigger] セクションに必要な情報を入力します。[次へ] をクリックします。

  10. [通知を構成してアラートを確定する] セクションで通知を構成します。

  11. アラートを確認し、準備ができたら [ポリシーを作成] をクリックします。

    これらの各手順を完了する方法の詳細については、アラート ポリシーを作成するをご覧ください。

次の Datastream の指標にアラートを作成することをおすすめします。

  • データの更新頻度
  • ストリームのサポートされていないイベント数
  • ストリームの合計レイテンシ

これらの指標のいずれかに関するアラートは、ストリームまたはソース データベースの問題を示している可能性があります。

レイテンシについて

Datastream には、レプリケーション レイテンシの把握に役立つ次の指標が用意されています。

  • データの更新速度: データがソースに commit された時間と、Datastream によってデータが読み取られた時間の差。この指標が高い場合は、Datastream がソースで生成されるよりも遅い速度でデータを読み取っていることを示します。これは、ソースまたはソースへのネットワーク接続に問題がある可能性があることを示します。
  • システム レイテンシ: Datastream がイベントを処理するのにかかる時間。イベントがソースから読み取られてから宛先に書き込まれるまでの時間。
  • 合計レイテンシ: エンドツーエンドのレプリケーション ラグ。データがソースに commit されてから宛先に書き込まれるまでの合計時間を表します。

データの更新速度が高い場合は、次のような原因が考えられます。

  • ソースの過負荷: ソース データベースで、Datastream が読み取れる速度よりも速くログ（バイナリログファイル、REDO ログファイル、WAL ファイル）が生成されています。
    • MySQL/Oracle のアクション: maxConcurrentCdcTasks パラメータを増やして、より多くのログを並行して読み取ります。
    • PostgreSQL のアクション: チャーン率の高いテーブルを独自の専用ストリームに分離します。
    • SQL Server のアクション: maxConcurrentCdcTasks パラメータを増やして、より多くの変更テーブルを並行して読み取ります。
  • ソースリソースの不足: ソース データベース サーバー自体で、CPU 使用率が高い、メモリやディスク I/O のボトルネックが発生しているなどの問題が発生しています。
    • 対応: ソース インスタンスが正常であることを確認します。CPU/RAM の使用率を確認します。PostgreSQL の場合は、logical_decoding_work_mem パラメータの値を増やすことを検討してください。Oracle の場合は、十分なシステム グローバル領域（SGA）が割り当てられていることを確認してください。
  • ネットワーク容量の問題: 送信元と Google Cloudの間の ping 時間が長い、または帯域幅が飽和している。
    • アクション: VPN または Cloud Interconnect の帯域幅とレイテンシをモニタリングします。
  • 単一の大規模なトランザクション: 数百万行に対する UPDATE などの大規模なバッチジョブにより、レイテンシが一時的に急増することがあります。
    • 対応: これは想定どおりの動作です。Datastream が大規模なイベントを処理するまで待ちます。今後は、大規模なバッチジョブを小さなチャンクに分割することを検討してください。

システム レイテンシが高い場合は、Datastream または宛先内で問題が発生している可能性があります。

  • 対応: Cloud Logging で永続的な行レベルのエラー（invalid input for type json など）を確認します。データ型または制約エラーが原因でストリームが再試行ループに入っている場合は、ソースでデータを手動で修正する必要があります。明らかなエラーがない場合は、Google サポートにお問い合わせください。

1 つのストリームで処理できるテーブルの数はいくつですか？

1 つのストリームに含めるテーブルの数は 10,000 までにすることをおすすめします。テーブルのサイズに制限はありません。より多くのテーブルを含むストリームを作成する必要がある場合、ストリームがエラー状態になることがあります。これを回避するには、ソースを複数のストリームに分割することを検討してください。