Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
8年以上前投稿 修正あり

MySQL 5.7以後のレプリケーションのデフォルト値(MySQL High Availabilityより)

MySQL 5.7以降のレプリケーション関連のデフォルト値について、変更点および考慮事項についてご紹介します。

原文
MySQL Replication Defaults After 5.7 | MySQL High Availability (English)
翻訳依頼者
D98ee74ffe0fafbdc83b23907dda3665 B5aa4f809000b9147289650532e83932
翻訳者
B5aa4f809000b9147289650532e83932 taka-h
翻訳レビュアー
D98ee74ffe0fafbdc83b23907dda3665 doublemarket 0deae06ab5d86b39feeec2e23a30b88a yoku0825
原著者への翻訳報告
未報告


免責事項

この記事はMatt Lord氏によるMySQL High Availabilityの投稿「MySQL Replication Defaults After 5.7」(2016/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。


大多数の人たちにとって、デフォルトあるいは「そのまま使える」設定から得られる体験がその製品に対する体験となるので、大多数の場合においてデフォルトの設定が良いことは我々にとっては非常に重要です。これは常に大変な課題で、なぜならば、関連するハードウェアの設定、利用するソフトウェア、アプリケーションがどのように利用されるか、などの複合的な要素の掛け合わせがあるからです。しかし、これには間違いなく力を注ぐ価値があります。Morgan Tockerと私はMySQL 5.7のサーバーのデフォルト値を改善するのに膨大な時間を費やし、この取り組みを前に推し進め続けています

この取り組みの全体的なゴールは次の通りです。

  • 簡単: 大多数のユーザーには、不要なチューニングなしに簡単にうまく動作するようにします。
  • 相互運用性: MySQLのレプリケーションは他のMySQL製品(UtilitiesFabricGroup Replicationなど)と追加で再構成することなく動作するようにします。
  • セキュリティーおよび永続性: デフォルトの挙動は、もともとの性能や他の要素に対し、データの完全性、一貫性およびアクセスの安全性を持つようにします。
  • サポート: 上記は多くの潜在的な問題を取り除くのに役立っていますが、問題をより簡単にデバッグできるように追加の情報を提供するようにします。

ここでレプリケーション固有のデフォルト値を改善するにあたって最初に考えていたことをお伝えし、これによってコミュニティーのフィードバックをいただきたいと思います。このフィードバックが我々にとっては本当に大事なのです!ここにその内容を記します。

  1. log-bin : バイナリログはデフォルトで有効化されるようにします。これは、MySQLのレプリケーションやポイントインタイムリカバリ、そして最近一般的に使われるようになったデータ処理コンポーネント(例えば、KafkaImparaSpark)とのインテグレーションにおいてとても重要な役割を果たすためです。
  2. binlog-row-image = MINIMAL : 行ベースのバイナリログはMySQL 5.7以降ではデフォルトとなります。行イメージを最小限(minimal)とすることで、この変更によるディスクIO、ディスク容量、そしてネットワークIOに対する潜在的なオーバーヘッドを少なくすることができます。最小限のイメージはMySQLのレプリケーションおよびポイントインタイムリカバリの基本的な要件を満たしており、理にかなったデフォルト値です。
  3. binlog-rows-query-log-events = ON : このオプションを使うと何がレプリケーションされるのかを、データベース管理者がより簡単に理解できるようになり、ステートメントベースレプリケーションから行ベースレプリケーションに移行する上での共通の悩みの1つが軽減されます。
  4. log-bin-trust-function-creators = TRUE : この設定バイナリログが有効化されているときのストアドプログラムの制約を排除します。
  5. gtid-mode = ON : グローバルトランザクションID(GTID)は最近のレプリケーション環境で必要とされています。たとえばFabricGroup Replicationなどがそれに該当し、一般的にはそれらによってレプリケーションはよりシンプル、そしてよりロバストになります。我々はその動作を改善し、MySQL 5.7におけるアップグレードパスを改善しましたので、これをがデフォルトのレプリケーションモードとなるよう進めていきます。
  6. enforce-gtid-consistency = ON: この設定によってレプリケーショングループ内で意図しないデータ不整合を引き起こしうるSQL文を実行しないようにすることができます。これはGTIDベースのレプリケーションを利用するときには論理的、技術的に必要となります。
  7. expire-logs-days = 90: この設定はバイナリログの保持期限のデフォルト値を指定します。90日はかなり安全な設定です(起動時とバイナリログがフラッシュされたときに削除が行われます)。レプリケーションあるいはリカバリに必要なくなったバイナリログに使われる無駄なディスク容量消費が増えるのを防ぎます。
  8. max-binlog-size = 1G: この設定は各バイナリログのサイズのおおよその上限値(トランザクションの境界は考慮されログをまたいで分断はされません)です。これは--expire-logs-daysオプションと共に利用することで効果を発揮し、過度そして不要なディスク使用を防ぎ、あるファイルシステム上で単一ファイルが肥大化することで発生する潜在的な問題(今日では滅多に起きなくなりましたが)が起きないようにします。
  9. master-info-repository = TABLE: この設定ACIDおよびMVCCの機能をバイナリログのメタデータにも提供するものです。これは一般的にクラッシュセーフかつ高信頼なレプリケーションに必要となるものです。我々はデフォルトで正確かつ安全にそして良いパフォーマンスで動くようにしたいと考えており、これはその重要な例の1つです。
  10. relay-log-info-repository = TABLE: この設定は上記の--master-info-repositoryでマスターについて述べたのと同じ恩恵をスレーブ側に提供するものです。我々はレプリケーションをクラッシュセーフにしたいと思っています。パフォーマンスを良くする為に、正確さ、一貫性、信頼性を犠牲にしたい方々にとっては、そのようにする選択肢もまだ提供しています。再度となりますが、我々は正確さよりも性能を好む傾向がある従来のMySQLの傾向から脱し、多くの歴史的なMySQLの「トラブルの元となっているもの(gotchas)」を取り除きます。
  11. relay-log-recovery = ON: この設定はスレーブがクラッシュした時のレプリケーションの一貫性をもたせるもので、破損している可能性があるリレーログが適用されないようにすることで実現されます。これもデフォルトでレプリケーションをクラッシュセーフにする為の取り組みの1つです。
  12. log-slave-updates = ON: この設定は様々なレプリケーションチェーンの構成で正しい動作をするようにするもので、今日では標準的となったものです。
  13. slave-exec-mode = IDEMPOTENT: この設定は、レプリケーションが伝播する過程で不必要な停止を発生させずに、トランザクション完了時にマスターとスレーブが一貫性のある状態であるようにするものです。簡潔に要点をまとめると、データがトランザクションの実行前に一致していなかった箇所で発生したエラーは、トランザクションの実行後にマスターとデータの一貫性がある場合に限り無視し、次に進みます(例えば、同じキーおよび行がトランザクション開始時に既にスレーブに存在した時)。
  14. slave-parallel-type = LOGICAL_CLOCK: この設定はスレーブでの並列実行に最適な並列化手法を提供します。「スレーブの時間差」はMySQLのデータベース管理者が商用環境で対処しなければならない共通の問題の1つで、デフォルトの設定ではこの問題を可能な限り制限します。
  15. slave-parallel-workers = 8: この設定LOGICAL_CLOCKベースの並列化が設定されている場合に、非同期にデータの変更が適用される為に発生する一時的なレプリケーションの差異(「スレーブの時間差」)の大多数のケースの発生を抑止します。
  16. slave-preserve-commit-order = ON: スレーブがマルチスレッドで動作している場合、このオプションはトランザクションがスレーブのリレーログに現れる順番通り外部に見えるようになるようにし(マルチスレッドが有効化されていない場合は何の影響もありません)、スレーブがマスターがなったことのない状態と絶対にならないようにします。簡単にいえば、これによりスレーブが読取りをスケールアウトするのに適したようになり、これは現在MySQLでは標準的です。これはマルチスレッド実行で発生するギャップおよび他の潜在的な不整合の問題の発生を防ぎます。
  17. slave-rows-search-algorithms = 'INDEX_SCAN,HASH_SCAN': この変更すなわちHASH_SCANの選択肢への追加 は、行ベースのイベントを適用するときに行を特定するのに利用可能なインデックスがないテーブル(主キーがないあるいは他のユニークインデックスがないテーブルの場合)にトランザクションを実行する場合に、選択可能な最善のパフォーマンスを提供できるようにします。HASH_SCANアルゴリズムを利用すると、そのようなケースでフルテーブルスキャンを避け、代わりに生成されたハッシュを利用して該当する行を探すようになります。
  18. slave-type-conversions = ALL_NON_LOSSY: この設定はデータの一貫性が保たれている限りスレーブの実行が先に進むことを許容するようにします。これによりレプリケーションが不必要に停止することを回避します(我々が注意しなければならないのは最終的にデータに一貫性があることです)
  19. sync-master-info = 1000: この設定のデフォルト値を10,000から1,000にしたのは、バイナリログデータに記録された値とmysql.slave_master_infoシステムテーブルに表示される値との不一致を制限するためです。ステータス監視をする場合は、従来からあるSHOW MASTER STATUSコマンドは継続して利用できます。
  20. sync-relay-log = 1000: この設定のデフォルト値を10,000から1,000にしたのはスレーブがクラッシュしたときにロストする可能性のあるイベント数を制限するためです。これによって--relay-log-recoveryが有効になっている際のリカバリ時間が短縮されます。
  21. plugin-load = group_replication.so: ここで詳細は述べませんが、MySQL Group Replicationが全ての新規のMySQL Serverインスタンスで利用できるようにすることがゴールです。

ご意見を募集しています!気軽にコメントしていただいても良いですし、私に直接emailを送っていただいても、私とtwitterでディスカッションを始めていただいても構いません。MySQLをご利用いただきありがとう

訳注

MySQL 5.7および対応するMySQL 5.6の日本語マニュアルは下記となります。 メジャーバージョンが異なりますので、参考としてご利用ください。

変数名           MySQL 5.7    MySQL 5.6(日本語)
log-bin en ja
binlog-row-image en ja
binlog-rows-query-log-events en ja
log-bin-trust-function-creators en ja
gtid-mode en ja
enforce-gtid-consistency en ja
expire-logs-days en ja
max-binlog-size en ja
master-info-repository en ja
relay-log-info-repository en ja
relay-log-recovery en ja
log-slave-updates en ja
slave-exec-mode en ja
slave-parallel-type en -
slave-parallel-workers en ja
slave-preserve-commit-order en -
slave-rows-search-algorithms en ja
slave-type-conversions en ja
sync-master-info en ja
sync-relay-log en ja

次の記事
SYS.SESSIONをSHOW PROCESSLISTの代わりに使う(MySQL Server Blogより)
前の記事
default_password_lifetimeのアップデート

Feed small 記事フィード

新着記事Twitterアカウント