Openflow Connector for MySQL:メンテナンス¶
注釈
このコネクタは、 Snowflakeコネクタ規約 に従うものとします。
このトピックでは、コネクタの再インストールや、ロードのための開始バイナリログ位置の設定など、 Openflow Connector for MySQL の維持に重要なメンテナンスの考慮事項とベストプラクティスについて説明します。
これらの操作は多くの場合、 スナップショットでの増分複製 と一緒に使用されます。
コネクタを再インストールする¶
このセクションでは、コネクタを再インストールし、同じテーブルのデータを再度スナップショットせずに複製し続ける方法について説明します。新しいコネクタが同じランタイムにインストールされている場合や、新しいランタイムに移動された場合をカバーします。
警告
コネクタが再インストール前に停止した位置と同じ CDC ストリーム位置から複製を続行するには、ソースデータベースは以前のコネクタが停止し、新しいコネクタが開始されてからの時間をカバーするのに十分な長さのバイナリログを保持する必要があります。MySQL サーバーの binlog_expire_logs_seconds パラメーターが十分に高いことを確認し、再インストール時間を最小限に抑えます。
binlog_expire_logs_seconds の値はコネクタの再インストールに予想される時間よりも長くする必要があります。通常、1日は86400秒で十分ですが、再インストールする時間を確保するには、もっと長い時間が適切な場合があります。
前提条件¶
コネクタパラメーターのコンテキスト値を確認してメモします。同じランタイムでコネクタを再インストールする場合は、既存のコンテキストを再利用できます。新しいインスタンスが別のランタイムにある場合は、すべてのパラメーターを再入力する必要があります。
既存のコネクタで進行中のすべての FlowFiles の処理を終了し、コネクタを停止します。
Snowsight にサインインします。
ナビゲーションメニューで Ingestion » Openflow を選択します。
Openflow ペインで Runtimes タブを選択します。
コネクタを含むランタイムを選択します。
コネクタを選択します。
Snapshot Load グループで一番上のプロセッサー Set Tables for Replication を停止します。
Incremental Load グループで一番上のプロセッサー Read MySQL CDC Stream を停止します。
Merge Task Schedule CRON パラメーターの値を変更した場合、
* * * * * ?に返します。そうでないと、次回のスケジュールされた実行までキューが空になりません。コネクタのすべての FlowFiles が処理され、すべてのキューが空になるまで待機します。すべての FlowFiles が処理されると、コネクタのプロセッサーグループの Queued 値がゼロになります。元のコネクタのキューにアイテムが残っている場合、新しいコネクタの開始時にデータギャップが生じる可能性があります。
コネクタ内のすべてのプロセッサーとコントローラーサービスを停止します。
注意
既存のコネクタはランタイムにとどまることができ、停止したままである限り、新しいインスタンスに干渉しません。
コネクタの新しいインスタンスを作成します。元のコネクタと同じランタイムを使用している場合は、既存のパラメーターコンテキストを保持し、設定を再利用できます。
別のランタイムにインストールする場合、または以前のパラメーターコンテキストを削除した場合は、 Openflow Connector for MySQL の設定 で説明されているとおり、テーブル名とパターンなどの構成設定を新しいパラメーターコンテキストに入力します。
MySQL Ingestion Parametersコンテキストに移動し、次のパラメーターを設定します。Ingestion Typeパラメーターをincrementalに設定します。懸念事項の詳細については、 スナップショットなしの増分複製を有効にする をご参照ください。Starting Binlog PositionパラメーターをEarliestに設定します。詳細と考えられる問題については、 バイナリログ位置からのロードを指定する をご参照ください。
新しいコネクタを起動します。
使用上の注意¶
新しいコネクタは、元のコネクタによって作成された既存の宛先テーブルを使用しますが、新しいジャーナルテーブルを作成します。
バイナリログ位置からのロードを指定する¶
Openflow Connector for MySQL コネクタでは、 MySQL バイナリログが読み取られる開始位置を選択できます。デフォルトでは、コネクタは最新の利用可能な位置から読み取ります。または、ソースインスタンスで利用可能な最も古い位置を選択することもできます。コネクタを再インストールする場合は、最も古い位置から開始することを選択するのが一般的です。これにより、新しいインスタンスは既存のテーブルをキャッチして、それぞれを再度スナップショットすることなく、複製を継続することができます。
実行中のコネクタを最新の位置から最も古い位置に切り替えると、利用可能なバイナリログ全体の再読み取り、再処理、および再適用が発生することに注意してください。
警告
バイナリログの再読み取り中は、影響を受ける宛先テーブルの列とデータが、すべてのイベントが再処理およびマージされるまで、ソースと同期されなくなる可能性があります。
次のパラメーターはスナップショットのロードを制御します。 Ingestion Parameters コンテキストで入手できます。
パラメーター |
説明 |
|---|---|
バイナリログ開始位置 |
|
状態のテーブルを再読み取り |
|
コネクタがバイナリログの再読み取りを終了したかどうかを判断するには、以下の手順を実行します。
Openflowキャンバスに移動します。
Incremental Load プロセスグループを開きます。
Read MySQL CDC Stream という名前の一番上のプロセッサーを右クリックし、 View state を選択します。
状態の項目を比較します。
binlog.position.rewind: バイナリログの再読み取りが開始される前に、プロセッサーが読み取った最新の位置。
binlog.position.dml: プロセッサーによって読み取られた現在の最新位置。この値が上記のrewind値よりも低い限り、プロセッサーはバイナリログを再読み取りし続けます。
使用上の注意¶
実行中のコネクタが最も古い位置からの読み取りに切り替えられ、実行を開始した後は、プロセスを再構成またはキャンセルできず、現在の読み取り位置が開始前の位置に到達するまで続行されます。
実行中のコネクタの最も早い位置に切り替えると、再処理されるテーブルは既存のジャーナルを終了し、新しいジャーナルテーブルを作成します。
バイナリログに、ソースデータベースでドロップされて再作成された以前のテーブルのイベントが含まれている場合、ストリームの再読み取りにより、現在の宛先ですべてのイベントが再処理されます。コネクタは、同じ名前を共有している場合、以前のソーステーブルと現在のソーステーブルを区別できません。