Original post: http://anothermysqldba.blogspot.com/2014/10/rotating-mysql-slow-logs.html

異なるクライアントでの作業中に、私は時々非常に大規模なスローログファイルを渡って実行するために起こる。 が、それらを回転させるべきかについて、いくつかの意見が存在する。 これらの意見の多くは、私も自分のバイナリログをフラッシュすることを好まない、ログローテートとフラッシュlogsコマンドを使用します。 私はロナルドブラッドフォードに同意するのはこのためです …

取り合えず、PerlからCに変わってる。

$ file /usr/mysql/5.6.20/scripts/mysql_install_db
/usr/mysql/5.6.20/scripts/mysql_install_db: a /usr/bin/perl script text executable

$ file /usr/mysql/5.7.5/bin/mysql_install_db
/usr/mysql/5.7.5/bin/mysql_install_db: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

あと、パスが変わってる。今までは./scriptsだったのが./binに(rpmで使ってるぶんには何も変わらないはず) ソースの位置もclient/mysql_install_db.ccになってる。

増えたオプションがいっぱい。

$ /usr/mysql/5.7.5/bin/mysql_install_db --help
..
  --admin-auth-plugin=name
                      Plugin to use for the default admin account.
  --admin-host=name   Hostname part of the default admin …

Transactdの開発過程でMySQLのパフォーマンス問題を調べてみたところ、ほとんどは「クエリーが遅い」といった問題のようでした。また、NoSQLデータベースへの移行理由としても「MySQLが遅いから」といった意見が結構あります。しかし、そのような理由でMySQLからNoSQLに移行しようとしているのなら、「ちょっと待った」です。（他の理由なら別ですが。）

NoSQLに移行すれば何もかもがバラ色というわけではありません。本当に移行する必要があるか、これを読んで考えてみてください。

TransactdはNoSQLですが、 …

ほとんどのNoSQLは、容易なスケーリングと、アクセス頻度の高い処理の高速化を目的として使われます。今回はTransactd 2.0について、スケーリングがどのように実現されるか書きたいと思います。

1. なぜNoSQLか？(SQLの欠点) テーブル間の依存

スケールアウトは、データを分割し別のサーバーに移動することで負荷を分散させます。SQLの場合、特にJOINは、サーバー内でデータを連結するため、あるテーブルだけ外部に移動するといったことができません。この欠点を回避するために、SQLにも関わらずJOINを禁止するといった使い方をするところもあるようです。

…

実際にはLabs版の5.7.4(InnoDB GIS)から必要になってたらしい。5.7.5のリリースノート を"boost"で引っかけると出てきたり、Building MySQL with Boost | MySQL Server Blog に書いてあったりした内容を試したっていうだけのメモ。

（ ´-｀）.oO（MySQL Server Blogには1.55が必要って書いてあるけど、リリースノートにはバージョン特に書いてないなぁ。。cmake/boost.cmakeを見る限り、1.55が決め打ちで必要とされてるぽいけど(1.56ではダメ)


CentOS 6.3の公式リポジトリからyumで突っ込んでみるも、バージョンが1.41なのでやっぱりダメっぽい。

$ cmake .
..
-- …

MySQL 5.7.5では、*UNDOログ領域が共有テーブルスペース上になければ* 使っていない領域をシュリンクさせることが出来るようになったらしい。

まずはUNDOログ領域を共有テーブルスペース上から追い出す設定。これは5.6で既に使える。共有テーブルスペースを作る *前に* やっておかないといけないので注意。

$ vim my.cnf
..
innodb-undo-tablespaces= 2
..

とりあえずinnodb-undo-tablespacesを2以上にすればOK。暗黙のデフォルトは0(=共有テーブルスペース上にUNDOテーブルスペースを作る)
…

MySQL 5.7ではmysqlスキーマのテーブルがいくつかMyISAM => InnoDB化されている。

5.6ではInnoDB統計情報永続化のヤーツと{master|relay-log}_info_repositoryのヤーツだけだったのが、

mysql56> SELECT @@version;
+------------+
| @@version  |
+------------+
| 5.6.20-log |
+------------+
1 row in set (0.00 sec)

mysql56> SELECT table_name, engine FROM information_schema.tables WHERE table_schema= 'mysql';
+---------------------------+--------+
| table_name                | engine |
+---------------------------+--------+
| columns_priv              | MyISAM |
| db                        | MyISAM |
| event                     | MyISAM |
| func                      | MyISAM |
| general_log               | CSV    |
| help_category             | MyISAM |
| help_keyword              | MyISAM |
| …

MySQL 5.7.5の新機能ネタ。

いままでMySQLでgraceful shutdownぽいことをしようとすると、SET GLOBAL max_connections= 1 で接続を制限するくらいしか思いつかなかったけれども(LVSとかでやりくりするのは除く)
* 接続を切断するわけではないので、Connector/Jのコネクションプーリング的なものとかと相性が悪い
* クライアントにはError: 1040 (ER_CON_COUNT_ERROR) "Too many connections" が戻ってしまう
  * しかも、Error: 1040は通常運用でも異常系として発生しうるので、区別してハンドルするのはかなり無理ゲー
と、イマイチgraceful shutdownの夢を見切れなかったけれども。


5.7.5で追加されたオフラインモードが多少なりとも夢を見させてくれるかも知れない。
オフラインモードは
* SET GLOBAL …

MySQL 5.7.5の新機能、オンラインバッファプールサイズ変更について。
今のサイズより大きくする（サイズ拡大編）は別エントリーで。

↑のエントリーにも書いたけど、理屈的には
* バッファプールサイズを今より大きく変更する時には全ブロック
* バッファプールサイズを今より小さく変更する時にはブロックなし
らしい。れつご。

# mysqladmin -r -i 2 ex | grep Innodb_rows_inserted
..
| Innodb_rows_inserted                          | 19837                                              | -- 前のエントリーの続きで、バッファプール80GBでtpcc_startでトラフィックかけてる
| Innodb_rows_inserted                          | 18892 …

MySQL 5.7.5の新機能。
ログ貼ってたら長くなったので、バッファプールサイズを小さくするのは別エントリーへ。

理屈的には、
- バッファプールを大きくするとき
  * innodb_buffer_pool_chunk_size ごとに新しいページを確保しながらゴニョゴニョやる
  * この処理中は *バッファプールへの全てのアクセスがブロックされるよ*
- バッファプールを小さくするとき
  *  …