MySQL ClickPipe は MariaDB をサポートしていますか？
サポートされていない MariaDB の部分行イベントが原因でパイプが失敗するのはなぜですか？
binlog_row_event_fragment_threshold 設定を引き上げ、断片化される行の変更を減らすこともできます。ただし、この値は max_allowed_packet 未満にしてください。断片化されていない単一の binlog イベントが max_allowed_packet を超えると、代わりにレプリケーションストリームが失敗します (パイプが max_allowed_packet の binlog エラーで失敗するのはなぜですか？を参照) 。
非対応の MariaDB の COMPRESSED カラムが原因で、パイプが失敗するのはなぜですか？
COLUMN_FORMAT COMPRESSED) を使用しているカラムが 1 つ以上あることを意味します。これらの値は binlog から復元できないため、該当するテーブルは CDC (変更データキャプチャ) ではレプリケートできません。
これを解決するには:
- 圧縮されたカラムをソース側で非圧縮の型に変更する (またはそのテーブルをパイプから削除する) :
- テーブルまたはパイプを再同期する
MySQL ClickPipe は PlanetScale、Vitess、または TiDB をサポートしていますか？
レプリケーションはどのように管理されますか？
GTID と FilePos の両方のレプリケーションをサポートしています。Postgres とは異なり、オフセットを管理するためのスロットはありません。代わりに、MySQL サーバーで十分な binlog の保持期間を設定する必要があります。binlog 内のオフセットが無効になった場合 (たとえば、mirror が長時間 Paused のままだった場合や、FilePos レプリケーションの使用中にデータベースのフェイルオーバーが発生した場合) 、パイプを再同期する必要があります。非効率なクエリによってインジェストが遅れ、保持期間を超えてしまう可能性があるため、宛先テーブルに応じて materialized view を必ず最適化してください。
また、アクティビティのないデータベースでは、ClickPipes がより新しいオフセットに進めないままログファイルがローテーションされることもあります。定期的に更新される heartbeat table をセットアップする必要がある場合があります。
初期ロードの開始時に、開始位置となる binlog オフセットを記録します。CDC (変更データキャプチャ) を進めるには、初期ロードの完了時点でもこのオフセットが有効である必要があります。大量のデータを取り込む場合は、適切な binlog の保持期間を必ず設定してください。テーブルのセットアップ中は、高度な設定で大きなテーブルに対して Use a custom partitioning key for initial load を設定すると、1 つのテーブルを並列にロードできるため、初期ロードを高速化できます。
パイプが max_allowed_packet の binlog エラーで失敗するのはなぜですか？
max_allowed_packet設定よりも大きいことを意味します。serverはこの上限を超えるイベントを送信できないため、binlogストリームの読み取りが中断され、CDC (変更データキャプチャ) が先に進めなくなります。
これは多くの場合、大きなBLOB、TEXT、またはJSONの値を含む行が原因です。解決するには、次の対応を行ってください。
- ログソース側で
max_allowed_packetを増やします。 最大の行変更サイズを上回る値に引き上げてください。通常は最大値の1Gに設定して問題ありません。再起動後も設定が保持されるように、server configuration (例:my.cnfまたは DB パラメータグループ) にも設定してください。 - 単一の行が1Gを超える場合: パイプを再同期します。
パイプが不完全な JSON binlog エラーで失敗するのはなぜですか？
binlog_row_value_options が PARTIAL_JSON に設定されていることを意味します。このオプションを有効にすると、MySQL は JSON カラムの更新を完全なドキュメントではなく、部分差分 (変更されたパスのみ) として記録します。ClickPipes はこれらの部分差分を適用できないため、CDC (変更データキャプチャ) を進行できません。
解決するには:
- ソース側で
PARTIAL_JSONを無効にします。 値を空文字列に戻します:再起動後も設定が維持されるよう、サーバー設定 (例:my.cnfまたは DB パラメータグループ) でもこの値をクリアします。 - パイプを再同期して、クリーンなオフセットからレプリケーションを再開します。
パイプが require_secure_transport エラーで失敗するのはなぜですか？
require_secure_transport が有効になっており、暗号化されていない接続をすべて拒否する一方で、ClickPipe では TLS が無効になっていることを意味します。RDS for MySQL では、これはインスタンスの DB パラメータグループで設定します。Aurora MySQL では、これは DB クラスターパラメータグループの設定であり、インスタンスパラメータグループでは設定できません。どちらも有効化に再起動は必要ありません。また、Aurora MySQL 8.4 ではデフォルトで ON ですが、バージョン 2 および 3 ではデフォルトで OFF です。そのため、問題なくレプリケーションしていたパイプでも、パラメータの変更やバージョンアップグレード後に、パイプ側に変更がなくても失敗し始めることがあります。
解決するには、次のいずれかを実行します。
- パイプで TLS を再度有効にします。 パイプの 設定 で接続設定を開き、TLS を無効化 トグルをオフにします。保存時に証明書エラーが表示される場合は、TLS ホストの設定、ルート CA のアップロード、または証明書検証をスキップする方法について、MySQL への接続時に TLS 証明書の検証エラーが発生するのはなぜですか？を参照してください。
- または、ソースで
require_secure_transportを無効にします。 暗号化されていない接続を環境で許容できる場合は、RDS では DB パラメータグループ、Aurora では DB クラスターパラメータグループで無効にします。
MySQL への接続時に TLS 証明書の検証エラーが発生するのはなぜですか？
x509: certificate is not valid for any names や x509: certificate signed by unknown authority のような証明書エラーが発生することがあります。これは、ClickPipes でデフォルトで TLS 暗号化が有効になっているためです。
これらの問題を解決するには、いくつかの方法があります。
- TLS Host フィールドを設定する - 接続先のホスト名が証明書と異なる場合 (Endpoint Service 経由の AWS PrivateLink でよくあります) は、証明書の Common Name (CN) または Subject Alternative Name (SAN) に一致するように「TLS Host (optional)」を設定してください。
- Root CA をアップロードする - 内部の認証局を使用している MySQL サーバーや、デフォルトのインスタンス単位 CA 構成を使用する Google Cloud SQL の場合に該当します。Google Cloud SQL 証明書へのアクセス方法の詳細については、このセクションを参照してください。
- サーバー証明書を設定する - すべての接続ホスト名を含むようにサーバーの SSL 証明書を更新し、信頼された認証局を使用してください。
- 証明書の検証をスキップする - セルフホストの MySQL または MariaDB では、デフォルト構成で自己署名証明書が作成されますが、ClickPipes ではこれを検証できません (MySQL、MariaDB) 。この証明書を使用すると通信中のデータは暗号化されますが、サーバーのなりすましリスクがあります。本番環境では適切に署名された証明書の使用を推奨しますが、この方法は一時的なインスタンスでのテストや、レガシーなインフラストラクチャへの接続には便利です。