[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

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)は表示されるのかどうか知らん。
(叩いたことあるはずだけど記憶にない)

2014/09/24

MySQL 4.0からアップグレードするならMySQL 5.0でいったん止まっておく

4.1はどうなんだろう。
もともと何故か、「4.0から上げるならまずは5.0まで上げて、あとはまあラクチン」とか記憶にあったんですが



そそのかされるがままに5.5, 5.1を試したらレプリケーションがぶら下がらなかった。

sys-backup19 [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: xxx.xxx.xxx.xxx
                  Master_User: xxxxxxx
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: xxxx-bin.986
          Read_Master_Log_Pos: 616810342
               Relay_Log_File: mysql-relay.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: xxxx-bin.986
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 616810342
              Relay_Log_Space: 106
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1193
                Last_IO_Error: The slave I/O thread stops because a fatal error is encountered when it try to get the value of TIME_ZONE global variable from master. Error: Unknown system variable 'TIME_ZONE'
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

この理由だけなら、4.1.3以降からなら一気に5.1以降にいけそうでもある。
http://dev.mysql.com/doc/refman/4.1/en/time-zone-support.html

憶えておくためのメモ。

2014/09/22

InfiniDBの止め方

InfiniDBはmysqldだけじゃなくデータを格納する場所があったりmysqldだけじゃなく止めるものがあったりしてよくわからないのが本音。

rpmでインストールしたら/etc/init.d/infinidb stopだけで全部止まるんじゃないかと期待していたけれど、残念ながらそんなことはなかった。。


最初の状態。

# ps auxww | grep Calpont
root     23342  0.0  0.0 121212    20 ?        S    Sep17   0:00 /bin/bash /usr/local/Calpont/bin/run.sh /usr/local/Calpont/bin/ProcMon
root     23343  0.0  0.2 1023764 2980 ?        Sl   Sep17   5:06 /usr/local/Calpont/bin/ProcMon
root     23483  0.0  0.0 121216    20 ?        S    Sep17   0:00 /bin/sh /usr/local/Calpont/mysql//bin/mysqld_safe --defaults-file=/usr/local/Calpont/mysql//my.cnf --datadir=/usr/local/Calpont/mysql/db --pid-file=/usr/local/Calpont/mysql/db/dev-personal-04.pid
mysql    23647  0.0  1.8 691168 18992 ?        Sl   Sep17   0:00 /usr/local/Calpont/mysql/libexec/mysqld --defaults-file=/usr/local/Calpont/mysql//my.cnf --basedir=/usr/local/Calpont/mysql/ --datadir=/usr/local/Calpont/mysql/db --user=mysql --log-error=/usr/local/Calpont/mysql/db/dev-personal-04.err --pid-file=/usr/local/Calpont/mysql/db/dev-personal-04.pid --socket=/usr/local/Calpont/mysql/lib/mysql/mysql.sock --port=3306
root     23679  0.0  0.3 219212  3564 ?        Sl   Sep17   0:31 /usr/local/Calpont/bin/controllernode fg
root     23712  0.0  1.8 170120 18940 ?        Sl   Sep17   0:53 /usr/local/Calpont/bin/ServerMonitor
root     23730  0.0  1.0 177392 10700 ?        Sl   Sep17   0:23 /usr/local/Calpont/bin/workernode DBRM_Worker1 fg


initスクリプトで止めてみる。

# /etc/init.d/infinidb stop
Shutting down InfiniDB Database Platform

# ps auxww | grep Calpont
root     10798  0.0  0.0   2716   168 pts/0    D+   15:11   0:00 grep Calpont
root     23679  0.0  0.3 202824  3716 ?        Sl   Sep17   0:31 /usr/local/Calpont/bin/controllernode fg
root     23712  0.0  2.0 170120 21352 ?        Sl   Sep17   0:53 /usr/local/Calpont/bin/ServerMonitor
root     23730  0.0  1.0 177392 10700 ?        Sl   Sep17   0:23 /usr/local/Calpont/bin/workernode DBRM_Worker1 fg

mysqldとそのラッパー、ProcMonとそのラッパーだけ落ちたっぽい。
残りのプロセスを落とすべく、calpontConsoleを起動してみる。


# cc

Calpont InfiniDB Command Console
   enter 'help' for list of commands
   enter 'exit' to exit the Calpont InfiniDB Command Console
   use up/down arrows to recall commands


Active Alarm Counts: Critical = 0, Major = 2, Minor = 1, Warning = 0, Info = 0

Critical Active Alarms:

InfiniDB> stopSystem
stopsystem   Mon Sep 22 15:13:04 2014

This command stops the processing of applications on all Modules within the Calpont System
           Do you want to proceed: (y or n) [n]: y

   System being stopped now...
**** stopSystem Failure : ProcessManager not Active
Retry or Run 'shutdownSystem FORCEFUL' command

InfiniDB> q
quit   Mon Sep 22 15:13:38 2014
Exiting the Calpont Command Console

# !ps
ps auxww | grep Calpont
root     10812  0.0  0.0 107520   880 pts/0    S+   15:13   0:00 grep Calpont
root     23679  0.0  0.3 202824  3812 ?        Sl   Sep17   0:31 /usr/local/Calpont/bin/controllernode fg
root     23712  0.0  2.0 170120 21360 ?        Sl   Sep17   0:53 /usr/local/Calpont/bin/ServerMonitor
root     23730  0.0  1.0 177392 10700 ?        Sl   Sep17   0:23 /usr/local/Calpont/bin/workernode DBRM_Worker1 fg

ProcessManagerがいないのがむしろいけないらしい。
initスクリプトで一度起動してから、ccでstopSystemを試す。


# /etc/init.d/infinidb start
Starting InfiniDB Database Platform

# !ps
ps auxww | grep Calpont
root     10828  0.0  0.1 121212  1608 pts/0    S    15:14   0:00 /bin/bash /usr/local/Calpont/bin/run.sh /usr/local/Calpont/bin/ProcMon
root     10829  4.0  1.3 1023764 14284 pts/0   Sl   15:14   0:07 /usr/local/Calpont/bin/ProcMon
root     10960  0.0  0.1 121216  1748 pts/0    S    15:14   0:00 /bin/sh /usr/local/Calpont/mysql//bin/mysqld_safe --defaults-file=/usr/local/Calpont/mysql//my.cnf --datadir=/usr/local/Calpont/mysql/db --pid-file=/usr/local/Calpont/mysql/db/dev-personal-04.pid
mysql    11124  0.2 10.8 681708 110576 pts/0   Sl   15:14   0:00 /usr/local/Calpont/mysql/libexec/mysqld --defaults-file=/usr/local/Calpont/mysql//my.cnf --basedir=/usr/local/Calpont/mysql/ --datadir=/usr/local/Calpont/mysql/db --user=mysql --log-error=/usr/local/Calpont/mysql/db/dev-personal-04.err --pid-file=/usr/local/Calpont/mysql/db/dev-personal-04.pid --socket=/usr/local/Calpont/mysql/lib/mysql/mysql.sock --port=3306
root     11161  0.0  0.9 153660  9752 pts/0    Sl   15:14   0:00 /usr/local/Calpont/bin/controllernode fg
root     11188  0.1  0.9 153736 10040 pts/0    Sl   15:14   0:00 /usr/local/Calpont/bin/ServerMonitor
root     11201  0.0  1.6 177328 16996 pts/0    Sl   15:15   0:00 /usr/local/Calpont/bin/workernode DBRM_Worker1 fg
root     11680  0.0  0.0 107520   880 pts/0    S+   15:17   0:00 grep Calpont

# cc

Calpont InfiniDB Command Console
   enter 'help' for list of commands
   enter 'exit' to exit the Calpont InfiniDB Command Console
   use up/down arrows to recall commands


Active Alarm Counts: Critical = 0, Major = 2, Minor = 1, Warning = 0, Info = 0

Critical Active Alarms:

InfiniDB> stopSystem
stopsystem   Mon Sep 22 15:18:31 2014

This command stops the processing of applications on all Modules within the Calpont System
           Do you want to proceed: (y or n) [n]: y

   System being stopped now...
   Successful stop of System

InfiniDB> q
quit   Mon Sep 22 15:18:57 2014
Exiting the Calpont Command Console

# !ps
ps auxww | grep Calpont
root     10828  0.0  0.1 121212  1608 pts/0    S    15:14   0:00 /bin/bash /usr/local/Calpont/bin/run.sh /usr/local/Calpont/bin/ProcMon
root     10829  2.8  1.4 1470336 14512 pts/0   Sl   15:14   0:08 /usr/local/Calpont/bin/ProcMon
root     11928  0.0  0.0 107520   880 pts/0    S+   15:19   0:00 grep Calpont

ProcMonが残った(´・ω・`)
stopSystemとshutdownSystemと両方あって、shutdownSystemの方は全部きれいにおとしてくれた。


# ps auxww | grep Calpont
root     12239  0.0  0.1 121212  1608 pts/0    S    15:21   0:00 /bin/bash /usr/local/Calpont/bin/run.sh /usr/local/Calpont/bin/ProcMon
root     12240  5.8  1.4 1023764 14336 pts/0   Sl   15:21   0:07 /usr/local/Calpont/bin/ProcMon
root     12374  0.0  0.1 121216  1748 pts/0    S    15:21   0:00 /bin/sh /usr/local/Calpont/mysql//bin/mysqld_safe --defaults-file=/usr/local/Calpont/mysql//my.cnf --datadir=/usr/local/Calpont/mysql/db --pid-file=/usr/local/Calpont/mysql/db/dev-personal-04.pid
mysql    12539  0.3 10.8 681708 110576 pts/0   Sl   15:21   0:00 /usr/local/Calpont/mysql/libexec/mysqld --defaults-file=/usr/local/Calpont/mysql//my.cnf --basedir=/usr/local/Calpont/mysql/ --datadir=/usr/local/Calpont/mysql/db --user=mysql --log-error=/usr/local/Calpont/mysql/db/dev-personal-04.err --pid-file=/usr/local/Calpont/mysql/db/dev-personal-04.pid --socket=/usr/local/Calpont/mysql/lib/mysql/mysql.sock --port=3306
root     12569  0.0  0.9 153660  9740 pts/0    Sl   15:21   0:00 /usr/local/Calpont/bin/controllernode fg
root     12604  0.3  0.9 153736 10032 pts/0    Sl   15:21   0:00 /usr/local/Calpont/bin/ServerMonitor
root     12616  0.0  1.6 177328 16996 pts/0    Sl   15:21   0:00 /usr/local/Calpont/bin/workernode DBRM_Worker1 fg
root     12983  0.0  0.0 107520   880 pts/0    S+   15:23   0:00 grep Calpont

# cc shutdownSystem
shutdownsystem   Mon Sep 22 15:23:38 2014

This command stops the processing of applications on all Modules within the Calpont System
           Do you want to proceed: (y or n) [n]: y

   System being shutdown now...
   Successful stop of System


   Successful shutdown of System

# ps auxww | grep Calpont
root     13220  0.0  0.0 107520   880 pts/0    S+   15:24   0:00 grep Calpont


stoipSystemでもshutdownSystemでも、起動は/etc/init.d/infinidb startでOKだった。cc startSystemでもOK。

InfiniDBのデータサイズメモ

ロード前の.tsvファイルの情報。


$ ls | wc
    457     457   13531

$ du -sh .
8.4G    .

$ gzip -l *.gz | sort -k 3 -n | head -2
         compressed        uncompressed  ratio uncompressed_name
            8828777            65857744  86.6% hogelog.tsv

$ gzip -l *.gz | sort -k 3 -nr | head -2
            7788996           179347671  95.7% hogelog.tsv
            7507164           173335810  95.7% hogelog.tsv

$ gzip -l *.gz | awk '{compressed += $1; uncompressed += $2}END{printf("%d\t%d\n", compressed, uncompressed)}'
17863413934     237716864426


非圧縮で200GB、平均すると圧縮率は92.5%…って、compressedの合計とduの結果合わないけどまあいいや。。


これを1テーブルにまとめてInfiniDBに突っ込んだ結果。

mysql> SHOW GLOBAL VARIABLES LIKE '%version%';
+-------------------------+------------------+
| Variable_name           | Value            |
+-------------------------+------------------+
| protocol_version        | 10               |
| version                 | 5.1.73           |
| version_comment         | InfiniDB 4.6.0-1 |
| version_compile_machine | x86_64           |
| version_compile_os      | redhat-linux-gnu |
+-------------------------+------------------+
5 rows in set (0.00 sec)

mysql> SELECT COUNT(*) FROM hogelog;
+------------+
| COUNT(*)   |
+------------+
| 1083798201 |
+------------+
1 row in set (11.26 sec)

mysql> SHOW TABLE STATUS\G
*************************** 1. row ***************************
           Name: hogelog
         Engine: InfiniDB
        Version: 10
     Row_format: Dynamic
           Rows: 2000
 Avg_row_length: 0
    Data_length: 0
Max_data_length: 0
   Index_length: 0
      Data_free: 0
 Auto_increment: NULL
    Create_time: NULL
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_general_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.00 sec)

# pwd
/usr/local/Calpont

# ll
total 64
-rw-r--r-- 1 root  root  17984 Jul  3 05:50 COPYING
drwxr-xr-x 2 root  root   4096 Sep 12 14:32 bin
drwxr-xr-x 3 root  root   4096 Sep 12 14:32 data
drwxrwxrwt 5 root  root   4096 Sep 12 16:18 data1
drwxrwxrwt 2 root  root   4096 Sep 22 04:02 etc
drwxr-xr-x 2 root  root   4096 Sep 12 14:33 lib
drwxr-xr-x 3 root  root   4096 Sep 12 14:34 local
drwxr-xr-x 7 mysql mysql  4096 Sep 20 16:26 mysql
drwxr-xr-x 2 root  root   4096 Sep 12 14:32 post
-rw-r--r-- 1 root  root     28 Jul  3 05:50 releasenum
drwxr-xr-x 2 root  root   4096 Sep 12 14:32 sbin
drwxr-xr-x 3 root  root   4096 Sep 12 14:32 share

# du -sh .
34G     .

# du -sh *
20K     COPYING
23M     bin
5.0M    data
33G     data1
212K    etc
30M     lib
80K     local
105M    mysql
24K     post
4.0K    releasenum
116K    sbin
1.4M    share

# ll data1
total 4198416
drwxr-xr-x 3 root root       4096 Sep 12 14:36 000.dir
-rw-r--r-- 1 root root          0 Sep 16 18:07 OAMdbrootCheck
drwxr-xr-x 2 root root       4096 Sep 22 13:11 bulkRollback
drwxrwxrwt 4 root root       4096 Sep 12 14:32 systemFiles
-rw-r--r-- 1 root root 4294967296 Sep 22 13:11 versionbuffer.cdf


…information_schemaが何の役にも立たないことはわかった。MySQLのdatadirの/usr/local/Calpont/mysql/dbはほとんど空っぽで、data1の下がデータ本体っぽい。VersionBufferっぽいものもここにある。
http://yoku0825.blogspot.jp/2014/09/infinidb-error-122-hy000-cal0006-idb.html


gzipped tsvの4倍くらい、非圧縮テキストファイルの1/6くらいか。ふむふむ。


【2014/09/22 16:16】
MyISAMでも試してみようと思いつつ、インデックスなしの状態で2/3くらい突っ込んだところで80GBに達したのでやめました。。

2014/09/19

mysql_install_dbが生成する.mysql_secretのパスワード形式が5.7で変更になってる

5.7.4をちょこちょこいじっていてふと気付いた。


$ cat ~/.mysql_secret
# The random password set for the root user at Tue Sep 16 18:33:14 2014 (local time):
9dl}uOS35]s4pAa3

…あれ、なんか桁数とバリエーション増えてない?;


358 sub generate_random_password {
359   # On (at least) Linux and Solaris, a "random" device is available, use it:
360   # cat /dev/urandom | LC_ALL=C tr -dc "[:alnum:]" | fold -w 8  | head -1
361   # Without LC_ALL, "tr" may not know the "alnum" character class -
362   # and there are user profiles which do not have this set.
363   #
364   my $password = `cat /dev/urandom | LC_ALL=C tr -dc "[:alnum:]" | fold -w 8  | head -1`;
365   chomp ($password);
366   return $password;
367 }
mysql-5.6.16/scripts/mysql_install_db.pl.in


 382 sub generate_random_password {
 383   # On Linux, Solaris, Max OS X and FreeBSD we have a random device available.
 384   my $randfile = "/dev/urandom";
 385   open(FD, $randfile) || return "";
 386   my $password = "";
 387   my $pass_len = 16;
 388   my $c;
 389   while (length($password) < $pass_len) {
 390     $c = getc(FD);
 391     if ($c =~ /\w/) {
 392       $password .= $c;
 393     }
 394   }
 395   close(FD);
 396   return $password;
 397 }
mysql-5.6.17/scripts/mysql_install_db.pl.in


 385 sub generate_random_password {
 386   # On Linux, Solaris, Max OS X and FreeBSD we have a random device available.
 387   my $randfile = "/dev/urandom";
 388   open(FD, $randfile) || die "Can't open $randfile for reading: $!";
 389   my $password = "";
 390   my $pass_len = 16;
 391   my $got_special= 0;
 392   my $got_num= 0;
 393   my $got_upper= 0;
 394   my $c;
 395   do
 396   {
 397     while (length($password) < $pass_len) {
 398       $c = getc(FD);
 399       if ($c =~ /\w/ || $c =~ /[,.!\$\@\{\}\=\-\+\#\[\]\(\)]/) {
 400         $password .= $c;
 401         if ($c =~ /[0-9]/)
 402         { $got_num = 1; }
 403         if ( $c =~ /[A-Z]/ )
 404         { $got_upper = 1; }
 405         if ($c =~ /[,.!\$\@\{\}\=\-\+\#\[\]\(\)]/)
 406         { $got_special= 1; }
 407       }
 408     }
 409     if ($got_special == 0 || $got_num == 0 || $got_upper == 0)
 410     {
 411       $got_special= 0;
 412       $got_num= 0;
 413       $got_upper= 0;
 414       $password= "";
 415     }
 416   } while(length($password) < $pass_len);
 417   close(FD);
 418   return $password;
 419 }
mysql-5.7.4-m14/scripts/mysql_install_db.pl.in
Σ(゚д゚lll) やっぱ増えてるー!?


記号が入るようになっているので、rpmでMySQLをインストールしたあとに先頭が"#"でないことをチェックしてパスワードを書き換えているような場合は来年あたりハマるかも知れません。
めんどくさい。

2014/09/17

cpimportを使ってInfiniDBにデータをロードするシンタックスだけメモ

速度比較とかしてないし、明らかにこっちの方が速かったのでたぶん調べない。シンタックスだけメモ。テーブルは予めmysqlコマンドラインクライアントから作っておく。


# /usr/local/Calpont/bin/cpimport d1 t1 -s "\t" -e 1000000000 < ./fifo
Locale is : C
Column delimiter : \t

Using table OID 3013 as the default JOB ID
Input file(s) will be read from : STDIN
Job description file : /usr/local/Calpont/data/bulk/tmpjob/3013_D20140917_T173443_Job_3013.xml
Log file for this job: /usr/local/Calpont/data/bulk/log/Job_3013.log
2014-09-17 17:34:43 (24078) INFO : successfully loaded job file /usr/local/Calpont/data/bulk/tmpjob/3013_D20140917_T173443_Job_3013.xml
2014-09-17 17:34:43 (24078) INFO : Job file loaded, run time for this step : 1.10977 seconds
2014-09-17 17:34:43 (24078) INFO : PreProcessing check starts
2014-09-17 17:34:47 (24078) INFO : PreProcessing check completed
2014-09-17 17:34:47 (24078) INFO : preProcess completed, run time for this step : 3.65073 seconds
2014-09-17 17:34:47 (24078) INFO : No of Read Threads Spawned = 1
2014-09-17 17:34:47 (24078) INFO : No of Parse Threads Spawned = 3
2014-09-17 17:34:47 (24078) INFO : Reading input from STDIN to import into table d1.t1...
2014-09-17 17:36:41 (24078) INFO : Number of rows with errors = 18.  Row numbers with error reasons are listed in file /tmp/hoge/data/d1.tbl.Job_3013_24078.err
2014-09-17 17:36:41 (24078) INFO : Number of rows with errors = 18.  Exact error rows are listed in file /tmp/hoge/data/d1.tbl.Job_3013_24078.bad
2014-09-17 17:36:42 (24078) INFO : For table d1.t1: 19680191 rows processed and 19680173 rows inserted.
2014-09-17 17:36:42 (24078) INFO : Bulk load completed, total run time : 120.018 seconds

-sでフィールドセパレーターを指定。省略時は"|"らしい。
-eで無視するパースエラーの数を指定する。暗黙のデフォルトは10。この状態だと11回目のパースエラーが発生した状態でcpimportがまるっとアボートする。
-rで読み込みスレッド, -wでパーサースレッドの数を指定。12コアのマシン(HTで24スレッド)で8, 8くらいが良さそうだった。200MB/sくらい出てたからとりあえず十分。

2014/09/16

MySQL 5.7で追加されたALTER TABLE .. RENAME INDEX

5.7.5が来る前に、5.7.4までのおさらい。

mysql57> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `org_index` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql57> ALTER TABLE t1 RENAME INDEX org_index TO renamed_index;
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql57> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `renamed_index` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)


これで、index_hogehoge_01なんて情報量ゼロのインデックスを見つけてもすぐに直せますね!


LOAD DATA INFILEで複数ファイルを食わせるのにちょっとだけ有効なTIPS

LOAD DATA INFILEで複数のファイルを順番(じゃなくてもいいけど)食わせる場合を考える。

↓こんなかんじ


$ ll *.tsv
-rw-rw-r-- 1 mysql mysql 541810051 Sep 16 10:51 20140912.tsv
-rw-rw-r-- 1 mysql mysql 523910384 Sep 16 10:52 20140913.tsv
-rw-rw-r-- 1 mysql mysql 513351897 Sep 16 10:53 20140914.tsv
-rw-rw-r-- 1 mysql mysql 513221906 Sep 16 10:54 20140915.tsv


無圧縮なファイルなら、シェルでぐるんぐるん回すのが便利。

$ for f in *.tsv ; do
> mysql -sse "LOAD DATA INFILE $f INTO TABLE .." && gzip $f
> done


成功したらgzip圧縮とかそのまんま書けるのでラク。
ただし、圧縮ファイルだと"展開" => "LOAD DATA INFILE" => "再圧縮"とか書くのはちょっと面倒だしなんかイヤだ。
あと、InfiniDBはある程度(100万行くらいだっけ?)まとめてLOAD DATA INFILEに食わせた方がデータの構築とかいっぺんに出来て速いとかそんな感じだった気がする(infinidb_use_import_for_batchinsert= 1の場合。0(MySQLのLOAD DATA INFILEをそのまま使う)場合はよく知らない)

という訳で、mkfifoを使ってます。


$ ll *.tsv.gz
-rw-rw-r-- 1 mysql mysql  2778925 Sep 12 18:04 20140722.tsv.gz
-rw-rw-r-- 1 mysql mysql  6775101 Sep 12 18:04 20140723.tsv.gz
-rw-rw-r-- 1 mysql mysql  7715720 Sep 12 18:04 20140724.tsv.gz
-rw-rw-r-- 1 mysql mysql  7811469 Sep 12 18:04 20140725.tsv.gz
-rw-rw-r-- 1 mysql mysql  8329598 Sep 12 18:05 20140726.tsv.gz
-rw-rw-r-- 1 mysql mysql  8256156 Sep 12 18:05 20140727.tsv.gz
-rw-rw-r-- 1 mysql mysql  8081465 Sep 12 18:05 20140728.tsv.gz
-rw-rw-r-- 1 mysql mysql  7881025 Sep 12 18:05 20140729.tsv.gz
-rw-rw-r-- 1 mysql mysql  7496167 Sep 12 18:06 20140730.tsv.gz
-rw-rw-r-- 1 mysql mysql  7934078 Sep 12 18:06 20140731.tsv.gz

$ mkfifo /tmp/fifo

$ zcat *.tsv.gz > /tmp/fifo


別のターミナルから

$ mysql -sse "LOAD DATA INFILE /tmp/fifo INTO TABLE .."

どうせLOAD DATA INFILEに失敗したらTRUNCATEして入れなおすからこれで十分。

InfiniDBのERROR 122 Bulkload Read Failed.

気持ちよくLOAD DATA INFILEしてたら急に現れたこんなやつ。

mysql> LOAD DATA INFILE '/data/tmp/fifo' INTO TABLE vegelog;
ERROR 122 (HY000): PM1 : Bulkload Read (thread 0) Failed for Table d1.t1.  Terminating this job.


ちなみにError 122はHandler層でのエラーらしい。

$ /usr/local/Calpont/mysql/bin/perror 122
OS error code 122:  Disk quota exceeded
MySQL error code 122: Internal (unspecified) error in handler

結論だけ書くと、テーブルのスキーマと食わせてたtsvファイルが完全に一致していなかった。
MySQLのLOAD DATA INFILEを使ってやると勝手にtruncationされて入る…んだけど、スキーマちゃんと調整しました。


mysql> SELECT @@infinidb_use_import_for_batchinsert; -- これがONだとLOAD DATA INFILEを/usr/local/Calpont/bin/cpimportにマップしてくれるので無効にする。
+---------------------------------------+
| @@infinidb_use_import_for_batchinsert |
+---------------------------------------+
|                                     1 |
+---------------------------------------+
1 row in set (0.00 sec)

mysql> SET SESSION infinidb_use_import_for_batchinsert= 0; 
Query OK, 0 rows affected (0.00 sec)

mysql> LOAD DATA INFILE '/data/tmp/fifo' INTO TABLE vegelog;
Query OK, 17208325 rows affected, 2076 warnings (5 min 35.09 sec)
Records: 17208325  Deleted: 0  Skipped: 0  Warnings: 2050

mysql> show warnings;
+---------+------+--------------------------------------------------------------------------------+
| Level   | Code | Message                                                                        |
+---------+------+--------------------------------------------------------------------------------+
| Warning | 1262 | Row 5397 was truncated; it contained more data than there were input columns   |
| Warning | 1262 | Row 5406 was truncated; it contained more data than there were input columns   |
| Warning | 1262 | Row 59575 was truncated; it contained more data than there were input columns  |
..
| Warning | 1261 | Row 329176 doesn't contain data for all columns                                |
| Warning | 1261 | Row 329176 doesn't contain data for all columns                                |
| Warning | 1261 | Row 329176 doesn't contain data for all columns                                |
+---------+------+--------------------------------------------------------------------------------+
64 rows in set (0.00 sec)

はふん。

InfiniDBにロードしている時に ERROR 122 (HY000): CAL0006: IDB-2008: The version buffer overflowed. と言われた

fifoファイル使ってごりごり流してたら怒られた。

mysql> LOAD DATA INFILE '/data/tmp/fifo' INTO TABLE infinidb_table
ERROR 122 (HY000): CAL0006: IDB-2008: The version buffer overflowed. Increase VersionBufferFileSize or limit the rows to be processed.

VersionBufferFileSizeを上げるのはいいんだけど、どれくらいが適正なのか、何をするパラメーターなのか、そもそもどこで設定するのかとかいろんな情報が出てこなくて困った。

とりあえず上げ方。


$ /usr/local/Calpont/bin/calpontConsole

InfiniDB> getSystemConfig
getsystemconfig   Tue Sep 16 11:35:41 2014

System Configuration

SystemName = calpont-1
SoftwareVersion = 4.6.0
SoftwareRelease = 1
ParentOAMModuleName = pm1
StandbyOAMModuleName = unassigned
NMSIPAddr = 0.0.0.0
ModuleHeartbeatPeriod = 10
ModuleHeartbeatCount = 3
DBRootCount = 1
DBRoot1 = /usr/local/Calpont/data1
DBRMRoot = /usr/local/Calpont/data1/systemFiles/dbrm/BRM_saves
ExternalCriticalThreshold = 90
ExternalMajorThreshold = 80
ExternalMinorThreshold = 70
MaxConcurrentTransactions = 1000
SharedMemoryTmpFile = /usr/local/Calpont/data1/systemFiles/dbrm/CalpontShm
NumVersionBufferFiles = 0
VersionBufferFileSize = 2
OIDBitmapFile = /usr/local/Calpont/data1/systemFiles/dbrm/oidbitmap
FirstOID = 3000
TransactionArchivePeriod = 10

InfiniDB> setSystemConfig VersionBufferFileSize 4
setsystemconfig   Tue Sep 16 11:36:10 2014

   Successfully set VersionBufferFileSize = 4

InfiniDB> exit   Tue Sep 16 11:36:11 2014
Exiting the Calpont Command Console

ところでこれ、再設定したあと再起動とか要るのか要らないのかもよくわからん。

ちなみに、1でダメで2に変えてもまだダメだったので4に変えたところ。



【2014/09/16 12:34】
512まで上げても改善の兆しが見られなかったので/etc/init.d/infinidb restartで再起動したら上手くいった。

# /etc/init.d/infinidb restart
Shutting down InfiniDB Database Platform
Starting InfiniDB Database Platform

# cc

Calpont InfiniDB Command Console
   enter 'help' for list of commands
   enter 'exit' to exit the Calpont InfiniDB Command Console
   use up/down arrows to recall commands


Active Alarm Counts: Critical = 0, Major = 0, Minor = 0, Warning = 0, Info = 0

Critical Active Alarms:

InfiniDB>
InfiniDB> getSystemConfig VersionBufferFileSize
getsystemconfig   Tue Sep 16 12:27:45 2014

   VersionBufferFileSize = 512

再起動しても揮発せずに残ってるのね。ってかmysqld(だけでいいのかわからんけど)の再起動が必要って言ってよ。。


【2014/09/16 19:25】
ざっと見、InnoDBでいうところのInnoDB Buffer Pool Sizeに近いんだかどうなんだかよく判らないような感じで、1~4Gくらいまで上げても良さそうなこと書いてあるけど、だったら初期値の1は何なんだ。。

http://infinidb.co/community/how-to-change-location-of-temp-directory


【2014/09/17 16:11】

ファイル見つけた。

# pwd
/usr/local/Calpont/data1

# ll
total 4198416
drwxr-xr-x 3 root root       4096 Sep 12 14:36 000.dir
-rw-r--r-- 1 root root          0 Sep 16 18:07 OAMdbrootCheck
drwxr-xr-x 2 root root       4096 Sep 17 16:02 bulkRollback
drwxrwxrwt 4 root root       4096 Sep 12 14:32 systemFiles
-rw-r--r-- 1 root root 4294967296 Sep 17 16:10 versionbuffer.cdf

2014/09/11

コンソールからMySQLでCOUNT .. GROUP BYするついでに視覚化してみる

想定しているのはこんなクエリー。


mysql56> SELECT DATE_FORMAT(timestamp, '%Y-%m') AS month, COUNT(*) AS count FROM tweets GROUP BY 1;
+---------+-------+
| month   | count |
+---------+-------+
| 2010-08 |     3 |
| 2010-09 |    90 |
| 2010-10 |    21 |
..
| 2014-07 |   608 |
| 2014-08 |   575 |
| 2014-09 |   276 |
+---------+-------+
50 rows in set (0.09 sec)


全文検索のテスト用にtweets.csvを食わせるSQL のエントリーで書いたそのまんまのDDLでtweets.csvを食わせたテーブル。
コンソールから作業していてこんなクエリーを叩いてもちょっと味気がなかったので、ひねってみた。


mysql56> SELECT DATE_FORMAT(timestamp, '%Y-%m') AS month, COUNT(*) AS count, CONCAT(REPEAT('+', COUNT(*) / 100), REPEAT('=', (COUNT(*) % 100) / 10), REPEAT('-', COUNT(*) % 10)) AS bar FROM tweets GROUP BY 1;
+---------+-------+----------------------------+
| month   | count | bar                        |
+---------+-------+----------------------------+
| 2010-08 |     3 | ---                        |
| 2010-09 |    90 | +=========                 |
| 2010-10 |    21 | ==-                        |
..
| 2014-07 |   608 | ++++++=--------            |
| 2014-08 |   575 | ++++++========-----        |
| 2014-09 |   276 | +++========------          |
+---------+-------+----------------------------+
50 rows in set (0.09 sec)

別に役に立ちはしないんだけど、人に説明するときにやって見せるとちょっと「おおお」と言われることが多い。

2014/09/08

MyISAMなテーブルに一括でmyisamchkをかける方法

2014年も半分以上過ぎたというのにMyISAMとか言わない。

myisamchkはテーブル名または.MYIファイル名を引数に取れるので、

$ find ./ -name "*.MYI" -exec myisamchk --silent -rq {} \;

datadirにcdしてこれだけでMyISAMなテーブルを順番にmyisamchkできる。


あー、InnoDBつかいたーい。