このトピックでは、PolarDBクラスターのバイナリログ機能を有効にする方法について説明します。
背景
PolarDBは、MySQLと互換性のあるクラウドネイティブデータベースです。 デフォルトでは、PolarDBはバイナリログよりも高度なredoログを使用します。 ただし、PolarDBでは、バイナリログ機能を有効にして、MySQLエコシステムとの互換性を高めることができます。 バイナリログ機能を有効にすると、データベースをElasticsearchや データのクエリと分析を容易にしますAnalyticDB。 また、PolarDB for MySQLクラスターからApsaraDB RDS for MySQLインスタンスへ、ApsaraDB RDS for MySQLインスタンスからPolarDB for MySQLクラスターへ、またはPolarDB for MySQLクラスター間でデータを同期できます。
制限事項
PolarDBクラスターが2019 4月5日以降に作成された場合は、バイナリログ機能を直接有効にできます。 PolarDBクラスターが2019 4月5日より前に作成されている場合は、バイナリログ機能を有効にする前に、クラスターのマイナーバージョンを最新バージョンに更新してください。 マイナーバージョンの更新方法については、「マイナーバージョンの更新」をご参照ください。
課金
バイナリログはクラスターストレージ容量を占有します。 使用したストレージリソースに対して課金されます。 詳細については、「ストレージ料金の概要」をご参照ください。
使用上の注意
デフォルトでは、バイナリログ機能は無効になっています。 バイナリログ機能を有効にすると、クラスターは自動的に再起動します。 ほとんどの場合、クラスターの再起動タスクが完了するまでに5分かかります。 クラスターの再起動中、サービスが約40秒間中断される場合があります。 リカバリ時間の長さは、データ量とテーブルの数によって異なります。 この操作をオフピーク時に実行し、アプリケーションがデータベースサービスに自動的に再接続できることを確認することをお勧めします。
バイナリログ機能を有効にすると、クラスターの書き込みパフォーマンスに悪影響を及ぼします。 ただし、読み取りパフォーマンスには影響しません。 ほとんどの場合、パフォーマンスへの影響は10% 以内ですが、極端なワークロードでは40% に増加する可能性があります。 詳細については、このトピックのFAQセクションを参照してください。
Data Transmission Service (DTS) などのサービスを使用してバイナリログをプル、サブスクライブ、またはレプリケートする場合は、PolarDBクラスターのプライマリエンドポイントを使用することを推奨します。 これにより、プライマリエンドポイントはバイナリログを生成するプライマリノードを指すため、互換性と安定性が保証されます。 プライマリエンドポイントのクエリ方法については、「クラスターのエンドポイントの管理」トピックの「エンドポイントとポートの表示」をご参照ください。
バイナリログ機能を有効にした後、大規模なトランザクションをコミットすると、他のトランザクションのコミッションがブロックされ、クラスターの再起動と構成変更期間に影響を与える可能性があります。
このトピックで説明するloose_polar_log_binパラメーターはグローバルパラメーターです。 セッションレベルのバイナリログ機能を有効にするには、sql_log_binパラメーターを設定します。
説明sql_log_binパラメーターを使用して、セッションレベルのバイナリログ機能を有効または無効にできます。 デフォルトで、この機能は無効化されています。 この機能を有効にするには、クォータセンターに移動し、polardb SQL _log_binパラメーターのアクセス許可クォータ名を見つけ、[操作] 列の [適用] をクリックします。
DTSを使用してApsaraDB RDSインスタンスからPolarDBクラスターにデータを移行すると、バイナリログ機能が自動的に有効になります。
バイナリログの有効化
既存のクラスターのバイナリログ機能の有効化
クラスターのバイナリログ機能を有効にすると、クラスターは自動的に再起動します。 ほとんどの場合、クラスターの再起動タスクが完了するまでに5分かかります。 クラスターの再起動中、サービスが約40秒間中断される場合があります。 リカバリ時間の長さは、データ量とテーブルの数によって異なります。 この操作をオフピーク時に実行し、アプリケーションがクラスターに自動的に再接続できることを確認することをお勧めします。
PolarDB コンソールにログインします。
コンソールの左上隅で、管理するクラスターがデプロイされているリージョンを選択します。
クラスターを見つけて、クラスターIDをクリックします。
次のいずれかの方法を使用して、バイナリログ機能を有効にします。
方法 1：
クラスターの左側のナビゲーションウィンドウで、[バイナリログ] をクリックします。
[今すぐ有効にする] をクリックします。
[バイナリログの有効化] ダイアログボックスで、[有効なメソッド] パラメーターを [今] または [スケジュール済み] に設定します。
[スケジュール] を選択した場合、バイナリログ機能を有効にする時点を指定します。
[OK] をクリックします。
方法2: loose_polar_log_binパラメーターを設定して、バイナリログを有効にします。
クラスターの左側のナビゲーションウィンドウで、 を選択します。
loose_polar_log_binパラメーターを見つけて、パラメーター値を変更します。 詳細については、「クラスターとノードパラメーターの設定」トピックの「パラメーターの変更」セクションをご参照ください。
説明MySQL 5.6を実行するPolarDB For MySQLクラスターの場合、パラメーター値をON_WITH_GTIDに変更します。
MySQL 5.7またはMySQL 8.0を実行するPolarDB For MySQLクラスターの場合、パラメーター値をONに変更します。
クラスター作成時のバイナリログ機能の有効化
クラスターの作成時にバイナリログ機能を有効にするには、[バイナリログの有効化] セクションの [有効化] を選択します。 詳細については、「Enterprise Editionクラスターの購入」および「サブスクリプションクラスターの購入」をご参照ください。
バイナリログファイルの保持
保持ポリシー
バイナリログファイルでは、次の保持ポリシーがサポートされています。
バイナリログ機能が有効になっている場合、バイナリログファイルはデフォルトで3日間保持されます。 保存期間が3日を超えるバイナリログファイルは自動的に削除されます。
説明2023年11月23日より前に購入されたPolarDB For MySQLクラスターの場合、バイナリログファイルはデフォルトで2週間 (14日間) 保持されます。
2024年1月17日より前に購入されたPolarDB For MySQLクラスターの場合、バイナリログファイルはデフォルトで1週間 (7日間) 保持されます。
バイナリログ機能が無効になっている場合、既存のバイナリログファイルは永続的に保持されます。
保持期間の変更
バイナリログファイルの保持期間を変更しても、接続が中断されたり、クラスターの再起動が必要になりません。
ただし、保持期間の変更によりテラバイトなどの大量のバイナリログファイルをパージする必要がある場合、書き込み操作中に短時間の例外が発生する可能性があります。 大量のバイナリログが存在する場合は、オフピーク時に保存期間を変更することを推奨します。 保持期間を徐々に短くすることもできます。 このようにして、バイナリログの一部のみが毎回クリアされます。 これにより、ビジネスオペレーションへの影響が軽減されます。
クラスターでバイナリログ機能が有効になっている場合は、次の操作を実行して、バイナリログの保持期間を変更します。
PolarDB for MySQL V5.6クラスター: loose_expire_logs_hoursパラメーターの値を変更します。 このパラメーターの有効値: 0〜2376。 単位：時間。 デフォルト値: 72。 値0は、バイナリログファイルが自動的に削除されないことを示します。
PolarDB for MySQL 5.7または8.0クラスター: binlog_expire_logs_secondsパラメーターの値を変更します。 このパラメーターの有効値: 0〜4294967295。 単位は秒です。 デフォルト値: 259200 値0は、バイナリログファイルが自動的に削除されないことを示します。
説明これら2つのパラメーターの値を変更しても、クラスター内の履歴バイナリログはすぐには消去されません。 次のいずれかの方法を使用して、即時パージをトリガーできます。
バイナリログファイルの回転を待ちます。 アクティブなバイナリログファイルが
max_binlog_sizeで設定された最大サイズに達すると、新しいバイナリログファイルが作成され、すべての履歴バイナリログファイルが自動的に削除されます。特権アカウントを使用してflush binary logsコマンドを実行します。
クラスターを再起動します。 履歴バイナリログファイルは、クラスターの再起動後に消去されます。
クラスターのバイナリログ機能が無効になっていて、バイナリログファイルを削除する場合は、次の手順を実行します。 loose_expire_logs_hoursまたはbinlog_expire_logs_secondsパラメーターを小さい値に設定し、バイナリログの有効期限が切れて自動的に消去されるのを待ちます。 次に、バイナリロギング機能を無効にします。
バイナリログの取得と表示
mysqlbinlogツールを使用して、バイナリログを表示および解析できます。 詳細については、「PolarDB For MySQLクラスターのバイナリログのリモート取得と解析」をご参照ください。
よくある質問
バイナリログファイルはどのくらいの期間保持されますか?
クラスターのバイナリログ機能を有効にすると、バイナリログファイルはデフォルトで3日間保持されます。 保存期間が3日を超えるバイナリログファイルは自動的に削除されます。
説明2023年11月23日より前に購入されたPolarDB For MySQLクラスターの場合、バイナリログファイルはデフォルトで2週間 (14日間) 保持されます。
2024年1月17日より前に購入されたPolarDB For MySQLクラスターの場合、バイナリログファイルはデフォルトで1週間 (7日間) 保持されます。
クラスターのバイナリログ機能を無効にすると、既存のバイナリログファイルは永続的に保持されます。
説明パラメーターを変更して、クラスターのバイナリログファイルの保持期間を変更できます。 バイナリログファイルの保存期間を変更する方法については、このトピックのバイナリログの保存セクションを参照してください。
バイナリロギング機能を無効にできますか?
はい、バイナリログ機能を無効にできます。 機能を無効にするには、loose_polar_log_binパラメーターをOFFに設定します。
説明バイナリログ機能を無効にすると、既存のバイナリログファイルは永続的に保持されます。 この機能を無効にする前に、バイナリログの保持期間を短縮することをお勧めします。 これにより、不要になったバイナリログがクリアされます。
バイナリログが占有するストレージ容量を減らすにはどうすればよいですか?
loose_expire_logs_hoursまたはbinlog_expire_logs_secondsパラメーターを小さい値に設定して、バイナリログが占有するストレージ容量を減らすことができます。
バイナリログ機能を有効にした後、クラスターのパフォーマンスはどのように影響しますか?
バイナリログ機能を有効にすると、INSERT、UPDATE、DELETEなどの書き込み操作のパフォーマンスのみが影響を受けます。 SELECTステートメントのパフォーマンスは影響を受けません。 ほとんどの場合、バイナリログ機能のパフォーマンスへの影響は10% 以内ですが、極端なワークロードでは40% に増加する可能性があります。
バイナリログ機能を有効にすると、クラスターは自動的に再起動します。 再起動プロセスが完了するまでにどれくらい時間がかかりますか?
ほとんどの場合、再起動タスクの完了には5分かかります。 クラスターの再起動中、サービスが約40秒間中断される場合があります。 リカバリ時間の長さは、データ量とテーブルの数によって異なります。 この操作をオフピーク時に実行し、アプリケーションがデータベースサービスに自動的に再接続できることを確認することをお勧めします。
バイナリログをリモートで取得して表示する方法?
詳細については、「PolarDB For MySQLクラスターのバイナリログのリモート取得と解析」をご参照ください。
DMSを使用してインデックスの追加などのテーブルスキーマを変更して、ロックフリーDDL操作を実行できないのはなぜですか。
テーブルをロックせずにDMSを使用してテーブルスキーマを変更するには、まずバイナリログ機能を有効にする必要があります。 デフォルトでは、この機能は無効になっています。 バイナリログ機能を有効にしない場合は、オンラインDDLを使用してテーブルスキーマを変更できます。
バイナリログ機能を有効にした後、Canalを使用してPolarDB for MySQLクラスターに加えられた変更をキャプチャできますか?
はい。バイナリログ機能を有効にした後、Canalを使用してPolarDB for MySQLクラスターに加えられた変更をキャプチャできます。
SHOW BINARY LOGSステートメントを実行してバイナリログのファイルサイズを照会すると、クラスタのパフォーマンスに影響がありますか。いいえ。
SHOW BINARY LOGSステートメントは、クラスターのパフォーマンスへの影響が最小限のデータベース管理操作です。 ステートメントの実行後、データはデータベースに書き込まれません。 したがって、データベースの読み取りおよび書き込みパフォーマンスは、INSERT、UPDATE、およびDELETEステートメントなどのデータ書き込み操作のように影響を受けません。