MySQL CDCからBigQueryへ：定期同期が見落とすものと、binlogがそれを回避する方法

MySQL CDCからBigQueryへ：定期同期が見落とすものと、binlogがそれを回避する方法 MySQL CDC同期は削除と中間更新を見落とします。binlogベースのChange Data Captureがどのように機能するか、MySQLの設定要件、およびBigQueryへの確実なロード方法を学びましょう。 2026年8月25日 ほとんどのMySQLからデータウェアハウスへのパイプラインは、同じパターンで実行されます。スケジュールされたジョブが行を選択し、以前の状態と比較し、差分を書き込みます。これは機能しますが、機能しなくなる時があります。 定期同期が見落とすもの SELECTベースの同期は、現在存在するデータしか見ることができません。2回の実行の間に存在して削除された行があったことを知る方法がなく、1回の変更で複数回更新された行の中間状態を見る方法もなく、変更された数行を見つけるためだけに大規模なテーブルをスキャンするたびに、本番データベースに実質的な負荷がかかります。 CDCが異なること Change Data Captureは、MySQLがレプリケーションのために内部的に使用するのと同じメカニズムであるMySQLのバイナリログ（binlog）から直接読み取ります。すべてのINSERT、UPDATE、DELETEは、ログに書き込まれた順序で、完全な行の状態とともにキャプチャされます。比較によって推測されるものはありません。バッチジョブがいつ実行されるかに依存するものはありません。 これは速度に関するものではありません。1時間に1回実行されるCDCパイプラインは、1分に1回実行されるバッチ同期よりも根本的に信頼性が高くなります。なぜなら、最新のスナップショットだけでなく、発生したすべてのものをキャプチャするからです。 MySQL側で真である必要があること binlog経由のCDCには、実際の前提条件があります。 ROWフォーマットでのバイナリロギング、およびFULL行イメージ。 binlog_row_imageがFULLに設定されていない場合、DELETEおよびUPDATEイベントは、変更を適用するために必要なものだけではなく、完全な変更前後の状態を運びません。これは、完全な行を必要とするダウンストリームコンシューマーにはしばしば不十分です。 binlog_row_value_optionsはPARTIAL_JSONであってはなりません。 PARTIAL_JSONの場合、JSON列への更新は、JSON値内の変更された部分のみをログに記録し、完全な値は記録しません。ソースと比較するまで気づきにくい、サイレントな問題です。 レプリケーションユーザーは、binlogを読み取り、監視するためにREPLICATION SLAVEおよびREPLICATION CLIENT権限、さらに初期スナップショットのためにSELECT、RELOAD、SHOW DATABASES権限が必要です。 データベースに接続されているすべてのレプリケーションクライアント（CDC接続を含む）に、一意のserver-idが必要です。既存のレプリカとの衝突は、デバッグが困難なサイレントな障害を引き起こします。 ダウンタイムをカバーするのに十分なbinlog保持期間。 MySQLは、設定可能なウィンドウ（デフォルトで30日）後にbinlogファイルをパージします。CDC接続がそれよりも長くオフラインの場合、停止した時点から再開できなくなります。新しい初期スナップショットが必要になります。 設定方法 GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'your_user'; FLUSH PRIVILEGES; 次にbinlog設定を確認します。 SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'binlog_row_image'; これらのいずれかが正しく設定されていない場合は、my.cnfに記述し、MySQLを再起動して適用する必要があります。 完全なコネクタドキュメント（すべて前提条件とトラブルシューティング手順を含む）は、docs.erathos.com/connectors/databases/mysql#cdc-setup にあります。 ここでマネージドプラットフォームがその価値を発揮します。Erathosおよび類似のツールは、スナップショットモードの選択（フル初期スナップショット対binlogのみ）、server-idの割り当てと衝突回避、および接続がキャッチアップする前にbinlogがパージされた場合のリカバリロジックを処理します。これにより、パイプラインを実行する人が新しいソースを接続するたびに、そのロジックを手動で再構築する必要がなくなります。 BigQueryへのロード CDCが変更を正しくキャプチャしたら、宛先側は比較的簡単です。各変更イベントは、BigQueryテーブルの行操作にマッピングされます。正しく行うべき部分はBigQueryへのロードではなく、そこに到達するデータが完全であることを保証することです。時間通りに不完全なデータをロードするパイプラインは、数分遅れることはあっても、決して間違わないパイプラインよりも悪いです。 もしあなたのチームがまだ本番MySQLに対してフルテーブルバッチ同期を実行しているなら、尋ねるべき質問は「これをどうすれば速くできるか」ではありません。「現在何を見ることができていないのか」です。 これを実際に試したい場合は、Erathosアカウントを作成し、数分でCDCを有効にしたMySQLソースを接続できます。