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

このページでは、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 個までにすることをおすすめします。テーブルのサイズに制限はありません。より多くのテーブルを含むストリームを作成する必要がある場合、ストリームがエラー状態になることがあります。これを回避するには、ソースを複数のストリームに分割することを検討してください。