mysql5.6→5.7パラメータめもです。
今更感ありすみませんが少し調べた内容の備忘録です。
(最新情報はご自分で確認されることを推奨します)
・RemovedとDeprecated(消えたのと非推奨になったもの)
RemoveをCtrl+fしたところ以下のあたりがなくなるパラメータ。
Deprecatedは非推奨になったもの
(もともと使ってなくて5.7でふえて5.7で消えるみたいなのも多かった)
パラメータ名 | ステータスとバージョンなど |
---|---|
thread_concurrency | innodb_thread_concurrencyに変わった |
innodb_additional_mem_pool_size | Removed 5.7.4 |
innodb_log_checksum_algorithm | Removed 5.7.9 |
innodb_optimize_point_storage | Removed 5.7.6 |
innodb_use_sys_malloc | Removed 5.7.4 |
innodb_create_intrinsic | Removed 5.7.6 |
innodb_support_xa | Deprecated 5.7.10 |
innodb_file_format_check | Deprecated 5.7.7 |
innodb_file_format_max | Deprecated 5.7.7 |
innodb_large_prefix | Deprecated 5.7.7 |
innodb_locks_unsafe_for_binlog | Deprecated 5.6.3 |
いままで使っていて多少影響があったのは上から2つくらい(たぶん)
・変化があったらしきもの(順不同)
binlog_error_action:IGNORE_ERROR -> ABORT_SERVER
バイナリーログの書き出しに失敗した時の動作を指定できるオプション。
バイナリーログに書き出しができなければmysqldがまるっと落ちるようなデフォルトに。
バイナリログ出さない運用とかほぼしないから気にしなくてよさそう。
「詳解MySQL5.7」
innodb_file_format:Antelope->Barracuda
要するに論理バックアップ(mysqldump)して入れなおすと将来Antelopeが廃止されても安心
innodb_buffer_pool_dump_at_shutdown:OFF->ON
innodb_buffer_pool_dump_at_startup:OFF->ON
バッファプールの暖機運転しなくても初回起動時遅いということがなくなるだけなので気にしなくていい
停止時に遅くないようにinnodb_buffer_pool_dump_pctで工夫されてる模様
innodb_large_prefix:OFF->ON
複合インデックスの最初または最後のカラムの容量がBarracudaでは増えてるがそれを有効に使うためにこの有効化が必要で
将来は廃止され常にオンになる予定のパラメータ
innodb_purge_threads:1->4
パージスレッドのデフォルト値が増えてる。CPUコアの多いマシンでは有効。削除がらみの処理がが早くなるのかなくらいしかわからない。
innodb_strict_mode:OFF->ON
無効な組み合わせでテーブルを作ろうとしたときに警告を発してテーブルが作られずに終了する仕組みの有効化
無効になるケース↓
innodb_file_per_table=0で圧縮テーブルを作成しようとした
innodb_file_format=Antelopeで圧縮テーブルを作成しようとした
圧縮テーブルでないのにKEY_BLOCK_SIZEが指定された
32KBあるいは64KBのページサイズで圧縮テーブルを作成しようとした
ちょっと気になるやつ
binlog_format:STATEMENT->ROW
MIXEDが安牌と思っていたので私は5.6までは明示的にMIXEDにしてる。がGTIDが有効だとROWにする情報を最近よく見る。
このパラメータで下手をうつとレプリケーション時のデータの整合性にかかわる現象がおきてた記憶があり要注意と思う。
RDSはGTID無効だった気がするので見直してみる。→無効でした。
innodb_autoinc_lock_mode:1->2
1よりも2の方が並列性能高いんだけど、SBR(ステートメントベースレプリケーション)で2にするとデータがズレることがあるよ! ということで1になっていたのが、
RBR(行ベースレプリケーション)になるので安心して2にできるということらしい。だがGTIDつかわないbinlog_formatROW以外なら1にしないとダメそう。
transaction_isolation:REPEATABLE-READ -> READ-COMMITTED
トランザクションで更新された情報がどの時点で見えるようになるか的なものの設定値。
まあzabbixのDBとかはそんなに気にしなくて大丈夫そう。課金とかだとちょっとシビアに確認が必要なのかもしれない。
binlog_gtid_recovery_simplified:OFF->ON
simplified_binlog_gtid_recoveryだったのが名前が変わったらしい。
クラッシュリカバリするときにONだと新しいバイナリログからGTIDイベントを検索するらしい。
OFFだと古いバイナリログ走査するのに時間かかるということみたい。
GTID使ってないならOFFとか勝手にやってくれるかは確認できてない。
innodb_log_file_size
もし指定してなかったらデフォルト値が変わるので古いの移動しないとmysqlが起動しなくなる気がする。RDSの挙動は不明。
RDSの注意書き抜粋
InnoDB バッファープールサイズの不整合
現在のところ、MySQL 5.7 には、InnoDB バッファプールサイズの管理方法にバグがあります。MySQL 5.7 が innodb_buffer_pool_size パラメーターの値を大きな値に調整し、それにより InnoDB バッファプールが大きくなりすぎ、過度のメモリを使用する可能性があります。この影響により、MySQL データベースエンジンは実行を停止するか、MySQL データベースエンジンが起動できなくなる場合があります。この問題は、使用できるメモリが少ない DB インスタンスクラスでより多く発生します。
この問題を解決するには、innodb_buffer_pool_size パラメーターの値を、innodb_buffer_pool_instances パラメーターの値と innodb_buffer_pool_chunk_size パラメーターの値の積の倍数に設定します。たとえば、次の例に示すように、innodb_buffer_pool_size パラメーターの値を innodb_buffer_pool_instances および innodb_buffer_pool_chunk_size パラメーターの積の 8 倍に設定します。
RDSに関してはGTID(グローバルトランザクションID)は無効なままなのでそれがらみのパラメータに関してあんまり気にする必要はない認識。
バージョン固有のパラメータを無視させるにはmy.cnfに書くときあたまにloose-
つけるといいです。
http://blog.kamipo.net/entry/2013/02/07/234050
参考:
https://yoku0825.blogspot.jp/2015/01/mysql-57.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html
「詳解MySQL5.7」
https://www.amazon.co.jp/dp/4798147400/
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.KnownIssuesAndLimitations
http://blog.kamipo.net/entry/2013/02/07/234050