GA

2014/09/29

MySQL 5.7.5のコンパイルにはBoostが必要になった

実際には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 .
..
-- BOOST_VERSION_NUMBER is #define BOOST_VERSION 104100
CMake Warning at cmake/boost.cmake:200 (MESSAGE):
  Boost minor version found is 41 we need 55
Call Stack (most recent call first):
  CMakeLists.txt:466 (INCLUDE)


-- Could not find (the correct version of) boost.

CMake Error at cmake/boost.cmake:37 (MESSAGE):
  You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>

  This CMake script will look for boost in $lt;directory>.  If it is not there,
  it will download and unpack it (in that directory) for you.

  If you are inside a firewall, you may need to use an http proxy:

  export http_proxy=http://example.com:80

Call Stack (most recent call first):
  cmake/boost.cmake:203 (COULD_NOT_FIND_BOOST)
  CMakeLists.txt:466 (INCLUDE)


-- Configuring incomplete, errors occurred!


$ rpm -qa | grep boost
boost-date-time-1.41.0-18.el6.x86_64
boost-iostreams-1.41.0-18.el6.x86_64
boost-wave-1.41.0-18.el6.x86_64
boost-1.41.0-18.el6.x86_64
boost-system-1.41.0-18.el6.x86_64
boost-thread-1.41.0-18.el6.x86_64
boost-program-options-1.41.0-18.el6.x86_64
boost-python-1.41.0-18.el6.x86_64
boost-regex-1.41.0-18.el6.x86_64
boost-signals-1.41.0-18.el6.x86_64
boost-serialization-1.41.0-18.el6.x86_64
boost-devel-1.41.0-18.el6.x86_64
boost-graph-1.41.0-18.el6.x86_64
boost-math-1.41.0-18.el6.x86_64
boost-filesystem-1.41.0-18.el6.x86_64
boost-test-1.41.0-18.el6.x86_64


というわけで、前述のURLの通りにcmakeにオプションを渡してやる。

$ cmake -DDOWNLOAD_BOOST=1 -DWITH_BOOST=/tmp/boost
-- Running cmake version 2.8.11.1
..
-- MySQL 5.7.5-m15
-- Packaging as: mysql-5.7.5-m15-Linux-x86_64
-- Local boost dir LOCAL_BOOST_DIR-NOTFOUND
-- Local boost zip LOCAL_BOOST_ZIP-NOTFOUND
-- Downloading boost_1_55_0.tar.gz to /tmp/boost
-- [download 0% complete]
..
-- cd /tmp/boost; tar xfz /tmp/boost/boost_1_55_0.tar.gz
-- BOOST_VERSION_NUMBER is #define BOOST_VERSION 105500
-- BOOST_INCLUDE_DIR /tmp/boost/boost_1_55_0
..
-- Build files have been written to: /home/yoku0825/mysql-5.7.5-m15

おお、通った。

というわけで誰かmysql-buildにパッチ投げてください。。(Issue上げただけで力尽きた)


【2014/09/28 16:46 PDT】
結局書きました。
https://github.com/kamipo/mysql-build/pull/13

2014/09/26

MySQL 5.7.5のInnoDB undo log truncationを試してみた

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

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


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

とりあえずinnodb-undo-tablespacesを2以上にすればOK。暗黙のデフォルトは0(=共有テーブルスペース上にUNDOテーブルスペースを作る)
1だとUNDOログ領域はibdata1上には作られなくなるものの、今回追加されたシュリンクの機能は使えない。
これで起動すると


# cd /usr/local/mysql
[root@v157-7-154-209 mysql]# ll data
total 652604
-rw-rw---- 1 mysql mysql        56 Sep 22 16:43 auto.cnf
-rw-rw---- 1 mysql mysql     87754 Sep 22 16:43 bin.000001
-rw-rw---- 1 mysql mysql   1230997 Sep 22 16:43 bin.000002
-rw-rw---- 1 mysql mysql  83893472 Sep 22 16:45 bin.000003
-rw-rw---- 1 mysql mysql        39 Sep 22 16:43 bin.index
-rw-rw---- 1 mysql mysql      3260 Sep 22 16:43 error.log
-rw-rw---- 1 mysql mysql  12582912 Sep 22 16:44 ibdata1
-rw-rw---- 1 mysql mysql 268435456 Sep 22 16:45 ib_logfile0
-rw-rw---- 1 mysql mysql 268435456 Sep 22 16:43 ib_logfile1
-rw-rw---- 1 mysql mysql  12582912 Sep 22 16:43 ibtmp1
drwx------ 2 mysql mysql      4096 Sep 22 16:44 mysql
-rw-rw---- 1 root  root          5 Sep 22 16:43 mysqld_safe.pid
-rw-r--r-- 1 root  root          9 Sep 22 16:44 mysql_upgrade_info
drwx------ 2 mysql mysql      4096 Sep 22 16:44 performance_schema
-rw-rw---- 1 mysql mysql       682 Sep 22 16:44 slow.log
drwx------ 2 mysql mysql      4096 Sep 22 16:44 tpcc
-rw-rw---- 1 mysql mysql  10485760 Sep 22 16:44 undo001
-rw-rw---- 1 mysql mysql  10485760 Sep 22 16:44 undo002
-rw-rw---- 1 mysql mysql         5 Sep 22 16:43 hostname.pid

こんなかんじ。$datadir/undo{連番} がUNDOログ領域。何番まで作られるかはinnodb-indo-tablespacesで決まる。
これを肥大化させるようにしばらくトラフィックをかけて


# ll data/undo00*
-rw-rw---- 1 mysql mysql 239075328 Sep 22 17:39 data/undo001
-rw-rw---- 1 mysql mysql 230686720 Sep 22 17:39 data/undo002

これを


mysql> SELECT @@innodb_max_undo_log_size;
+----------------------------+
| @@innodb_max_undo_log_size |
+----------------------------+
|                 1073741824 |
+----------------------------+
1 row in set (0.02 sec)

mysql> SET GLOBAL innodb_max_undo_log_size= 10 * 1024 * 1024;
Query OK, 0 rows affected (0.02 sec)

mysql> SET GLOBAL innodb_undo_log_truncate= 1;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%undo%';
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_max_undo_log_size | 10485760 |
| innodb_undo_directory    | .        |
| innodb_undo_log_truncate | ON       |
| innodb_undo_logs         | 128      |
| innodb_undo_tablespaces  | 2        |
+--------------------------+----------+
5 rows in set (0.00 sec)

こうじゃ!


# ll data/undo00*
-rw-rw---- 1 mysql mysql 239075328 Sep 22 17:40 data/undo001
-rw-rw---- 1 mysql mysql 230686720 Sep 22 17:40 data/undo002

( ゚д゚) ・・・

(つд⊂)ゴシゴシ


# ll data/undo00*
-rw-rw---- 1 mysql mysql 239075328 Sep 22 17:40 data/undo001
-rw-rw---- 1 mysql mysql 230686720 Sep 22 17:40 data/undo002

(;゚д゚) ・・・

(つд⊂)ゴシゴシゴシ


# ll data/undo00*
-rw-rw---- 1 mysql mysql 239075328 Sep 22 17:40 data/undo001
-rw-rw---- 1 mysql mysql 230686720 Sep 22 17:40 data/undo002
_, ._
(;゚ Д゚) …!?


減ってないじゃん。何がいけないんだろう。。
と思ったら、innodb_purge_rseg_truncate_frequencyというパラメーターがあるらしい。n回、undoログのパージが呼ばれるとtruncationが炸裂する、みたいな。


mysql> SELECT @@innodb_purge_rseg_truncate_frequency;
+----------------------------------------+
| @@innodb_purge_rseg_truncate_frequency |
+----------------------------------------+
|                                    128 |
+----------------------------------------+
1 row in set (0.00 sec)

-- tpcc_start

# ll data/undo00*
-rw-rw---- 1 mysql mysql  10485760 Sep 22 17:47 data/undo001
-rw-rw---- 1 mysql mysql 230686720 Sep 22 17:47 data/undo002

# ll data/undo00*
-rw-rw---- 1 mysql mysql 10485760 Sep 22 17:47 data/undo001
-rw-rw---- 1 mysql mysql 10485760 Sep 22 17:47 data/undo002

# ll data/undo00*
-rw-rw---- 1 mysql mysql 10485760 Sep 22 17:47 data/undo001
-rw-rw---- 1 mysql mysql 10485760 Sep 22 17:47 data/undo002


おお、トランザクションをかければパージが呼ばれるようになるので、シュリンクが発動する、みたいな。
innodb_buffer_pool_dump_nowみたいにSET GLOBALしたところからバックグラウンドに処理が始まるわけじゃなくて、常に有効で容量が監視されて超えたらtruncationになるわけか。。

てことはあんまり小さいサイズにすると死ねると。

ともあれちょっと感動した。

MySQL 5.7.5でmysqlスキーマの中身がちょっとだけInnoDB化された

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 |
| help_relation             | MyISAM |
| help_topic                | MyISAM |
| innodb_index_stats        | InnoDB |
| innodb_table_stats        | InnoDB |
| ndb_binlog_index          | MyISAM |
| plugin                    | MyISAM |
| proc                      | MyISAM |
| procs_priv                | MyISAM |
| proxies_priv              | MyISAM |
| servers                   | MyISAM |
| slave_master_info         | InnoDB |
| slave_relay_log_info      | InnoDB |
| slave_worker_info         | InnoDB |
| slow_log                  | CSV    |
| tables_priv               | MyISAM |
| time_zone                 | MyISAM |
| time_zone_leap_second     | MyISAM |
| time_zone_name            | MyISAM |
| time_zone_transition      | MyISAM |
| time_zone_transition_type | MyISAM |
| user                      | MyISAM |
+---------------------------+--------+
28 rows in set (0.00 sec)


5.7.5では

mysql> SELECT @@version;
+---------------+
| @@version     |
+---------------+
| 5.7.5-m15-log |
+---------------+
1 row in set (0.05 sec)

mysql> SELECT table_name, engine FROM information_schema.tables WHERE table_schema= 'mysql';
+---------------------------+--------+
| table_name                | engine |
+---------------------------+--------+
| columns_priv              | MyISAM |
| db                        | MyISAM |
| engine_cost               | InnoDB |
| event                     | MyISAM |
| func                      | MyISAM |
| general_log               | CSV    |
| gtid_executed             | InnoDB |
| help_category             | InnoDB |
| help_keyword              | InnoDB |
| help_relation             | InnoDB |
| help_topic                | InnoDB |
| innodb_index_stats        | InnoDB |
| innodb_table_stats        | InnoDB |
| ndb_binlog_index          | MyISAM |
| plugin                    | MyISAM |
| proc                      | MyISAM |
| procs_priv                | MyISAM |
| proxies_priv              | MyISAM |
| server_cost               | InnoDB |
| servers                   | MyISAM |
| slave_master_info         | InnoDB |
| slave_relay_log_info      | InnoDB |
| slave_worker_info         | InnoDB |
| slow_log                  | CSV    |
| tables_priv               | MyISAM |
| time_zone                 | InnoDB |
| time_zone_leap_second     | InnoDB |
| time_zone_name            | InnoDB |
| time_zone_transition      | InnoDB |
| time_zone_transition_type | InnoDB |
| user                      | MyISAM |
+---------------------------+--------+
31 rows in set (0.00 sec)


:(;゙゚'ω゚'): おいmysql_install_dbとmysql_upgradeしか触らないようなテーブルじゃまいか。

engine_cost, server_cost, gtid_executedが新設テーブルですね。

MySQL 5.7.5のオフラインモードはgraceful shutdownの夢を見るか

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 offline_mode= 1で有効化
* オフラインモードだと、Super_privを持っていないユーザーは接続できない
* Super_privを持っていないユーザーのセッションは、トランザクションが終了次第コネクションを切断される
という機能。

http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_offline_mode


tpcc_startをかけながら、以下のコマンドでドン。

mysql> SHOW PROCESSLIST; SET GLOBAL offline_mode= 1; SHOW PROCESSLIST;
+----+------+-----------+------+---------+------+----------------+------------------------------------------------------------
------------------------------------------+
| Id | User | Host      | db   | Command | Time | State          | Info
                                          |
+----+------+-----------+------+---------+------+----------------+------------------------------------------------------------
------------------------------------------+
|  7 | root | localhost | NULL | Query   |    0 | starting       | SHOW PROCESSLIST
                                          |
|  8 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 997 WHERE w_id = 1
                                          |
|  9 | tpcc | localhost | tpcc | Execute |    0 | Writing to net | UPDATE stock SET s_quantity = 62 WHERE s_i_id = 14040 AND s
_w_id = 1                                 |
| 10 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 1347 WHERE w_id = 1
                                          |
| 11 | tpcc | localhost | tpcc | Execute |    0 | statistics     | SELECT count(*) FROM stock WHERE s_w_id = 1 AND s_i_id = 96
265 AND s_quantity < 19                   |
| 12 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 2773 WHERE w_id = 1
                                          |
| 13 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 2927 WHERE w_id = 1
                                          |
| 14 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE stock SET s_quantity = 5 WHERE s_i_id = 89835 AND s_
w_id = 1                                  |
| 15 | tpcc | localhost | tpcc | Query   |    0 | starting       | commit
                                          |
| 16 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE order_line SET ol_delivery_d = '2014-09-20 16:29:37'
 WHERE ol_o_id = 2310 AND ol_d_id = 2 AND |
| 17 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 3326 WHERE w_id = 1
                                          |
| 18 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 1965 WHERE w_id = 1
                                          |
| 19 | tpcc | localhost | tpcc | Execute |    0 | optimizing     | SELECT count(*) FROM stock WHERE s_w_id = 1 AND s_i_id = 78
08 AND s_quantity < 12                    |
| 20 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 4738 WHERE w_id = 1
                                          |
| 21 | tpcc | localhost | tpcc | Sleep   |    0 |                | NULL
                                          |
| 22 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 925 WHERE w_id = 1
                                          |
| 23 | tpcc | localhost | tpcc | Sleep   |    0 |                | NULL
                                          |
| 24 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 1413 WHERE w_id = 1
                                          |
| 25 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 3134 WHERE w_id = 1
                                          |
| 26 | tpcc | localhost | tpcc | Execute |    0 | Writing to net | INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_numbe
r, ol_i_id, ol_supply_w_id, ol_quantity,  |
| 27 | tpcc | localhost | tpcc | Execute |    0 | updating       | UPDATE warehouse SET w_ytd = w_ytd + 1808 WHERE w_id = 1
                                          |
+----+------+-----------+------+---------+------+----------------+------------------------------------------------------------
------------------------------------------+
21 rows in set (0.03 sec)

Query OK, 0 rows affected (0.02 sec)

+----+------+-----------+------+---------+------+-------------+---------------------------------------------------------------
---------------------+
| Id | User | Host      | db   | Command | Time | State       | Info
                     |
+----+------+-----------+------+---------+------+-------------+---------------------------------------------------------------
---------------------+
|  7 | root | localhost | NULL | Query   |    0 | starting    | SHOW PROCESSLIST
                     |
| 11 | tpcc | localhost | tpcc | Killed  |    0 | System lock | SELECT count(*) FROM stock WHERE s_w_id = 1 AND s_i_id = 32770
 AND s_quantity < 19 |
| 15 | tpcc | localhost | tpcc | Killed  |    0 | starting    | commit
                     |
+----+------+-----------+------+---------+------+-------------+---------------------------------------------------------------
---------------------+
3 rows in set (0.00 sec)


オフラインモードに設定したあと、クエリー(not トランザクション)が終了したタイミングでクライアントは切断される。 切断されたクライアントで更に操作をしようとすると、フツーにError: 2006 "MySQL Server has gone away"が出力される(wait_timeoutとかで切断されたときといっしょ)

..
payment 3:1
2006, HY000, MySQL server has gone away
payment 3:1
2006, HY000, MySQL server has gone away
..

tpcc_startは起動時にセッション確保してそのままずっとそれでトラフィックをかけ続けるので、セッションをつなぎ直さないので、これがどばーとで続ける。
新しくつなぎ直そうとすると、


# mysql -utpcc -p tpcc
Enter password:
ERROR 1917 (HY000): The server is currently in offline mode

# mysql -uroot -p tpcc
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 30
Server version: 5.7.5-m15-log MySQL Community Server (GPL)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

SUPERでないユーザーはError: 1917でエラーが返り、スーパーユーザーはそのまま接続できる。max_connection= 1みたいに2セッションしかメンテ用に使えないとか(スーパーユーザー全体で+1セッションなので、1本スーパーユーザーで入ると他のスーパーユーザーも入れない)そんなこともない。

オフラインモードに入れてもポートのLISTENはそのままなので、TCPで3306を叩くだけの死活監視は生きてしまうことくらいがアレだけど、LVSとか手前で切り離せばそれでもたぶんOK。

mysqladmin pingはエラーを出力するけど戻り値は0だった。FR出そうかな。


# mysqladmin -utpcc -p ping
Enter password:
mysqladmin: connect to server at 'localhost' failed
error: 'The server is currently in offline mode'

# echo $?
0


# mysqladmin -uroot -p ping
Enter password:
mysqld is alive

# echo $?
0

MySQL 5.7.5で実装された オンラインでのInnoDBバッファプールサイズ変更(サイズ縮小編)

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

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


# mysqladmin -r -i 2 ex | grep Innodb_rows_inserted
..
| Innodb_rows_inserted                          | 19837                                              | -- 前のエントリーの続きで、バッファプール80GBでtpcc_startでトラフィックかけてる
| Innodb_rows_inserted                          | 18892                                              |
| Innodb_rows_inserted                          | 18198                                              |
| Innodb_rows_inserted                          | 17974                                              |
| Innodb_rows_inserted                          | 4293                                               | -- このへんでSET GLOBAL
| Innodb_rows_inserted                          | 1261                                               |
| Innodb_rows_inserted                          | 1160                                               |
| Innodb_rows_inserted                          | 1669                                               |
| Innodb_rows_inserted                          | 1207                                               |
| Innodb_rows_inserted                          | 744                                                |
| Innodb_rows_inserted                          | 1274                                               |
| Innodb_rows_inserted                          | 964                                                |
| Innodb_rows_inserted                          | 1060                                               |
| Innodb_rows_inserted                          | 1134                                               |
| Innodb_rows_inserted                          | 1197                                               |
| Innodb_rows_inserted                          | 1147                                               |
| Innodb_rows_inserted                          | 1199                                               |
| Innodb_rows_inserted                          | 1261                                               |
| Innodb_rows_inserted                          | 1247                                               | -- まだ終わってないけど、以降は似たような値が続く
..
| Innodb_rows_inserted                          | 2998                                               |
| Innodb_rows_inserted                          | 3325                                               |
| Innodb_rows_inserted                          | 3434                                               |
| Innodb_rows_inserted                          | 2894                               | -- たぶんここでCompleted resizing buffer pool
| Innodb_rows_inserted                          | 902                                |
| Innodb_rows_inserted                          | 559                                |
| Innodb_rows_inserted                          | 765                                |


コマンド。

mysql> SELECT NOW(); SET GLOBAL innodb_buffer_pool_size= 4 * 1024 * 1024 * 1024;
+---------------------+
| NOW()               |
+---------------------+
| 2014-09-18 07:32:19 |
+---------------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_resize%';
+----------------------------------+------------------------------------+
| Variable_name                    | Value                              |
+----------------------------------+------------------------------------+
| Innodb_buffer_pool_resize_status | Withdrawing blocks to be shrunken. |
+----------------------------------+------------------------------------+
1 row in set (0.00 sec)

mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_resize%';
+----------------------------------+----------------------------------------------------+
| Variable_name                    | Value                                              |
+----------------------------------+----------------------------------------------------+
| Innodb_buffer_pool_resize_status | Completed resizing buffer pool at 140918  7:41:30. |
+----------------------------------+----------------------------------------------------+
1 row in set (0.00 sec)

10分かかったけど特にブロックもなく(ただし、innodb_lock_wait_timeout= 1にしてるから、それでタイムアウトしたトランザクションはあった)ある程度想像通り。


----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- ------memory-usage----- ---load-avg---
  date/time   |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw | used  buff  cach  free| 1m   5m  15m
18-09 07:31:34|  7   1  88   4   0   0|7576k  158M|  60B  711B|   0     0 |  69k   92k|51.8G  136M 67.3G  609M|3.59 8.37 8.50
18-09 07:31:39|  6   1  89   4   0   0|8872k  164M| 222B  600B|   0     0 |  60k   83k|51.9G  136M 67.3G  577M|3.38 8.25 8.46
18-09 07:31:44|  7   1  88   4   0   0|9477k  147M| 276B 1082B|   0     0 |  59k   83k|51.9G  136M 67.2G  577M|3.11 8.11 8.42
18-09 07:31:49|  7   1  88   4   0   0|8838k  145M| 324B  380B|   0     0 |  64k   88k|51.9G  136M 67.2G  566M|2.94 7.99 8.38
18-09 07:31:54|  7   1  88   4   0   0|9045k  145M| 534B  690B|   0     0 |  65k   89k|51.9G  136M 67.2G  569M|2.79 7.88 8.34
18-09 07:31:59|  8   1  87   4   0   0|9562k  152M| 414B  524B|   0     0 |  68k   95k|52.0G  136M 67.1G  607M|2.81 7.79 8.31
18-09 07:32:04|  7   1  88   4   0   0|8458k  154M| 324B 1376B|   0     0 |  68k   93k|52.0G  136M 67.1G  625M|2.74 7.70 8.28
18-09 07:32:09|  8   2  86   4   0   0|9323k  149M| 192B 1059B|   0     0 |  71k   99k|52.0G  136M 67.1G  584M|2.60 7.59 8.24
18-09 07:32:14|  6   1  88   4   0   0|  10M  179M| 462B  526B|   0     0 |  67k   91k|52.0G  136M 67.1G  572M|2.47 7.48 8.20 ### ここでSET GLOBAL
18-09 07:32:19|  7   1  87   4   0   0|  11M  149M|  78B   83B|   0     0 |  73k   98k|52.1G  136M 67.0G  591M|2.35 7.37 8.16
18-09 07:32:24|  2   0  94   3   0   0|3083k  122M| 246B  370B|   0     0 |  68k   78k|52.1G  136M 67.1G  570M|2.33 7.28 8.13
18-09 07:32:29|  1   0  95   3   0   0|2534k  116M| 210B  257B|   0     0 |  68k   76k|52.1G  136M 67.0G  616M|2.22 7.18 8.09
18-09 07:32:34|  1   0  95   3   0   0|3034k  115M| 108B   65B|   0     0 |  64k   72k|52.1G  136M 67.0G  596M|2.12 7.07 8.05
18-09 07:32:39|  1   0  95   3   0   0|2546k  121M| 450B 1102B|   0     0 |  66k   74k|52.1G  136M 67.1G  579M|2.03 6.97 8.01
18-09 07:32:44|  1   0  95   3   0   0|2746k  118M|  54B   22B|   0     0 |  68k   76k|52.1G  136M 67.0G  632M|1.95 6.87 7.97
18-09 07:32:49|  1   0  95   3   0   0|2560k  122M|   0     0 |   0     0 |  64k   72k|52.1G  136M 67.0G  616M|1.87 6.78 7.9
..
18-09 07:41:09|  1   1  93   5   0   0|6458k  302M|  60B  610B|   0     0 |  11k   16k|52.1G  134M 67.1G  580M|1.88 3.00 5.51
18-09 07:41:14|  1   1  94   4   0   0|5389k  299M|  72B  559B|   0     0 |  12k   16k|52.1G  134M 67.1G  566M|1.81 2.97 5.49
18-09 07:41:19|  1   1  94   4   0   0|5843k  299M|  60B  544B|   0     0 |  13k   17k|52.1G  134M 67.1G  571M|1.90 2.97 5.47
18-09 07:41:24|  1   1  94   4   0   0|5178k  312M|  60B  544B|   0     0 |  13k   18k|52.1G  134M 67.1G  576M|1.91 2.95 5.45
18-09 07:41:29|  1   5  94   1   0   0|1595k   42M|  60B  554B|   0     0 |2307  2665 |17.3G  134M 67.1G 35.3G|2.08 2.97 5.45
18-09 07:41:34|  1   1  97   1   0   0|7552k   66M|  60B  548B|   0     0 |2987  3801 |9.81G  134M 67.1G 42.8G|1.99 2.94 5.42 ### ここでCompleted resizing buffer pool
18-09 07:41:39|  0   0  99   0   0   0|  10M   14M|  60B  554B|   0     0 |1004  1337 |9.81G  134M 67.1G 42.8G|1.83 2.89 5.39
18-09 07:41:44|  0   0  99   0   0   0|  10M   14M|  60B  554B|   0     0 |1023  1352 |9.81G  134M 67.2G 42.7G|1.69 2.84 5.36
18-09 07:41:49|  0   0  99   0   0   0|8557k   14M|  60B  554B|   0     0 | 932  1250 |9.81G  134M 67.2G 42.7G|1.55 2.79 5.33
18-09 07:41:54|  0   0  99   0   0   0|9382k   14M|  60B  554B|   0     0 | 950  1275 |9.81G  134M 67.2G 42.7G|1.43 2.75 5.31
18-09 07:41:59|  0   0  99   0   0   0|8710k   13M|  60B  554B|   0     0 | 942  1257 |9.81G  134M 67.2G 42.7G|1.31 2.70 5.28
18-09 07:42:04|  0   0  99   0   0   0|9101k   14M|  60B  554B|   0     0 | 986  1297 |9.81G  134M 67.3G 42.6G|1.21 2.66 5.25
18-09 07:42:09|  0   0  99   0   0   0|8640k   15M|  60B  607B|   0     0 |1243  1673 |9.81G  134M 67.3G 42.6G|1.11 2.61 5.22


* ストレージへのWriteがゴリゴリ走るのは、バッファプールの縮小はつまるところバッファプールからページがこぼれるのと同じ動作になのでflushが頻発する
* 最終的なfreeは当然バッファプールリサイズが全て終わったあと。
* Last checkpointed atの値から1GBくらい引き離されたところでやってみたけど一応吸収してくれてるぽい。

ある意味想定内だったアレとしては、
* innodb_buffer_pool_instances= 1で(でないとinnodb_buffer_pool_sizeを1GB未満にできないから)
* innodb_log_file_size= 2Gで
* innodb_buffer_pool_size= 80Gから
* innodb_buffer_pool_size= 256Mに変更したら
ハングアップ!

ご利用は計画的にってことですねわかりますん :)

MySQL 5.7.5で実装された オンラインでのInnoDBバッファプールサイズ変更(サイズ拡大編)

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

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

http://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-online-resize.html


しかしバッファプール大きくする時の動作はInnoDBのトラフィック全滅ですか使えNEEEE とか、「オンラインでバッファプールサイズを変えようと思うこと自体負けてる」とか思ってたんですが、やってみると意外と楽しかった。

ブロックされっぷりだけ判ればいいので、mysqladmin exでInnodb_rows_insertedだけ差分表示。

# mysqladmin -r -i 2 ex | grep Innodb_rows_inserted
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 0                   |
| Innodb_rows_inserted                          | 12296               | -- ここからtpcc_start
| Innodb_rows_inserted                          | 19250               |
| Innodb_rows_inserted                          | 13717               |
| Innodb_rows_inserted                          | 5033                |
| Innodb_rows_inserted                          | 4990                |
| Innodb_rows_inserted                          | 5757                |
| Innodb_rows_inserted                          | 5301                |
| Innodb_rows_inserted                          | 4355                |
| Innodb_rows_inserted                          | 4835                |
| Innodb_rows_inserted                          | 4909                |
| Innodb_rows_inserted                          | 5161                |
| Innodb_rows_inserted                          | 5331                |
| Innodb_rows_inserted                          | 4907                |
| Innodb_rows_inserted                          | 5384                |
| Innodb_rows_inserted                          | 5047                |
| Innodb_rows_inserted                          | 5437                |
| Innodb_rows_inserted                          | 4922                |
| Innodb_rows_inserted                          | 5010                |
| Innodb_rows_inserted                          | 4827                |
| Innodb_rows_inserted                          | 5208                |
| Innodb_rows_inserted                          | 5543                |
| Innodb_rows_inserted                          | 4362                |
| Innodb_rows_inserted                          | 5460                |
| Innodb_rows_inserted                          | 4819                |
| Innodb_rows_inserted                          | 4555                |
| Innodb_rows_inserted                          | 4696                |
| Innodb_rows_inserted                          | 5047                |
| Innodb_rows_inserted                          | 5492                |
| Innodb_rows_inserted                          | 511                                           | -- SET GLOBALがここらへん
| Innodb_rows_inserted                          | 0                                             |
| Innodb_rows_inserted                          | 0                                             |
| Innodb_rows_inserted                          | 0                                             |
| Innodb_rows_inserted                          | 0                                             |
| Innodb_rows_inserted                          | 3740                                               | 
| Innodb_rows_inserted                          | 20354                                              | -- ここらへんでCompleted resizing buffer pool
| Innodb_rows_inserted                          | 20937                                              |
| Innodb_rows_inserted                          | 21281                                              |
| Innodb_rows_inserted                          | 21474                                              |
| Innodb_rows_inserted                          | 21752                                              |
| Innodb_rows_inserted                          | 19685                                              |
| Innodb_rows_inserted                          | 21784                                              |
| Innodb_rows_inserted                          | 22009                                              |
| Innodb_rows_inserted                          | 22107                                              |
| Innodb_rows_inserted                          | 21842                                              |
..


実際に叩いたのは↓。

mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                4294967296 |
+---------------------------+
1 row in set (0.00 sec)

mysql> SET GLOBAL innodb_buffer_pool_size= 80 * 1024 * 1024 * 1024;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT NOW();
+---------------------+
| NOW()               |
+---------------------+
| 2014-09-18 07:21:02 |
+---------------------+
1 row in set (0.00 sec)

mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_resize%';
+----------------------------------+----------------------------------------------------+
| Variable_name                    | Value                                              |
+----------------------------------+----------------------------------------------------+
| Innodb_buffer_pool_resize_status | Completed resizing buffer pool at 140918  7:21:11. |
+----------------------------------+----------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               85899345920 |
+---------------------------+
1 row in set (0.00 sec)


ログの具合が悪いのか何なのか、エラーログにresize startedとresize completedを吐いてくれなかったので代用。
80GBの拡張でおおよそ10秒ちょいのブロック。。
これなら、オフラインにしてサイズ変えて起動してinnodb_buffer_pool_load_at_startupするのに比べて無茶苦茶早く済む。
ちょっとマジですかイケそうじゃないですか。

おまけにdstat。

# dstat -taml 5
----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- ------memory-usage----- ---load-avg---
  date/time   |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw | used  buff  cach  free| 1m   5m  15m
18-09 07:19:07|  0   0 100   0   0   0|   0     0 |1038B 7824B|   0     0 |  87   103 |2615M  142M 66.0G 51.1G|   0 1.49 5.27 
18-09 07:19:12|  0   0 100   0   0   0|   0     0 |1260B   10k|   0     0 |  94   109 |2615M  142M 66.0G 51.1G|   0 1.46 5.24
18-09 07:19:17|  0   0 100   0   0   0|1797k    0 | 492B 1935B|   0     0 | 381   238 |2619M  145M 66.0G 51.1G|   0 1.44 5.21 ### mysqldの起動がこのへん
18-09 07:19:22|  0   0 100   0   0   0|   0    18k|1176B 1831B|   0     0 | 160   235 |2619M  145M 66.0G 51.1G|   0 1.42 5.19
18-09 07:19:27|  0   0 100   0   0   0|  19k   13k| 306B  397B|   0     0 |  75    85 |2619M  145M 66.0G 51.1G|   0 1.39 5.16
18-09 07:19:32|  0   0 100   0   0   0|   0    19k| 246B 1557B|   0     0 |  80    84 |2616M  145M 66.0G 51.1G|   0 1.37 5.13 ### このへんでtpcc_start
18-09 07:19:37|  0   1  99   0   0   0| 592k   34k| 474B  987B|   0     0 |1031   845 |3231M  145M 66.0G 50.5G|   0 1.35 5.10
18-09 07:19:42|  1   0  99   0   0   0| 474k   11M| 330B 3324B|   0     0 | 651   731 |3507M  145M 66.0G 50.2G|   0 1.32 5.08
18-09 07:19:47|  0   0 100   0   0   0| 582k   13M| 174B 1327B|   0     0 | 906  1099 |3532M  145M 66.0G 50.2G|   0 1.30 5.05
18-09 07:19:52|  0   0 100   0   0   0| 627k   13M| 204B  965B|   0     0 | 911  1119 |3558M  145M 66.0G 50.2G|   0 1.28 5.02
18-09 07:19:57|  0   0 100   0   0   0| 646k   13M| 246B  498B|   0     0 | 862  1097 |3581M  145M 66.0G 50.2G|   0 1.26 4.99
18-09 07:20:02|  0   0 100   0   0   0| 525k   13M|1332B  687B|   0     0 | 968  1198 |3604M  145M 66.0G 50.1G|   0 1.24 4.97 ### ここらへんでSET GLBOAL
18-09 07:20:07| 43  11  44   2   1   0|  78M   26M| 240B 1512B|   0     0 |  63k  187k|6545M  145M 66.3G 47.0G|1.12 1.45 5.02
18-09 07:20:12| 30   7  55   7   1   0|  60M  227M|  36B  121B|   0     0 |  94k  181k|7662M  145M 66.4G 45.8G|1.19 1.46 5.00 ### ここらへんでCompleted resizing buffer pool
18-09 07:20:17| 15   4  71   9   1   0|  36M  276M|  24B   81B|   0     0 | 101k  140k|7662M  145M 66.6G 45.7G|1.42 1.50 4.99
18-09 07:20:22| 11   3  77   9   1   0|  27M  230M| 198B  208B|   0     0 |  83k  112k|7664M  145M 66.6G 45.6G|1.79 1.58 5.00
..


おもしろーい :)

2014/09/25

MariaDB 5.5.39のALTER TABLEでprogressが表示されてた

ほへー。

MariaDB [hoge]> ALTER TABLE t1 DROP c1, DROP c2, DROP c3, DROP c4, DROP c5, DROP c6, DROP c7, DROP c8, DROP c9, DROP c10;
Stage: 1 of 2 'copy to tmp table'   57.5% of stage done

ちなみにMyISAM。InnoDB(XtraDB)は表示されるのかどうか知らん。
(叩いたことあるはずだけど記憶にない)