MySQL binlogを遅いディスクに置くことはできますか？
マスターサーバーには450 GBのnvmeスペースしかないため、binlogは2日間しか保持されていなくても、多くのスペースを使用しています。
MySQL binlogをより遅いディスク（リモートディレクトリなど）に書き込むと、MySQLのパフォーマンスが低下しますか？
バイナリロギングは、ステートメントまたはトランザクションが完了した直後であるが、ロックが解除される前、またはコミットが実行される前に行われるため、ログを低速のディスクに配置すると影響が及ぶ可能性があると想像する他のトランザクションは現在のトランザクションがログに記録されるまで遅延されるため。
バイナリログを最速のストレージに保存しますが、レプリケーションに必要なログのみを保持することで、フラッシュドライブのログの量を減らします。
マニュアルで概説されているように、自動化してより頻繁に ログをパージする手順 を実行し、スレーブがそれらを処理したために不要になったすべてのログを削除できます。
各スレーブサーバーで、
SHOW SLAVE STATUSを使用して、読み取っているログファイルを確認します。
SHOW BINARY LOGSを使用して、マスターサーバー上のバイナリログファイルのリストを取得します。すべてのスレーブの中で最も古いログファイルを特定します。これがターゲットファイルです。すべてのスレーブが最新の場合、これはリストの最後のログファイルです。
削除しようとしているすべてのログファイルのバックアップを作成します。 （このステップはオプションですが、常に推奨されます。）
ターゲットファイルを除くすべてのログファイルをパージします。
たとえば監査目的で、より多くのログを保持したい場合は、ステップ4でそれらのログを低速の（回転）ディスクにコピーしてから、PURGE BINARY LOGS TOまたはPURGE BINARY LOGS BEFORE MySQLステートメントを使用してフラッシュドライブからログを削除します。
から MySQLマニュアル：
デフォルトでは、バイナリログは書き込みごとにディスクに同期されます（
sync_binlog=1）。 sync_binlogが有効でなく、オペレーティングシステムまたはマシン（MySQLサーバーだけでなく）がクラッシュした場合、バイナリログの最後のステートメントが失われる可能性があります。これを防ぐには、sync_binlogシステム変数を有効にして、N個のコミットグループごとにバイナリログをディスクに同期させます。セクション5.1.8「サーバーシステム変数」を参照してください。 sync_binlogの最も安全な値は1（デフォルト）ですが、これも最も低速です。
上記の引用の太字部分は、遅いストレージがINSERTレートに上限を設けることを意味します。部分的な緩和策として、binlogは順次書き込まれるため、シークの待ち時間は発生しません。
専用のbinlogデバイスの例として単一の7200 RPMディスクを使用すると、平均回転遅延は約4.1ミリ秒で、1秒あたり約250の書き込みI/Oを期待できます。これは明らかにディスク側にNVRAM /ライトバックキャッシュがないことを前提としています。そのようなキャッシュが存在する場合、同期された書き込みはすぐにキャッシュに吸収されます。
また、binlogの同期を無効にして、基本的に問題をレイテンシに制限されたものからスループットに制限されたものに変換できることにも注意してください。ただし、それがデータの整合性にとって何を意味するかを必ず理解してください。