プロシージャの中身のクエリはスロークエリログに落ちない の続き。

Vanilla MySQLだとプロシージャの中身がログに落ちませんが、Percona Server ではスロークエリログが拡張されていて、ログに落ちます。

log_slow_sp_statements で出力の有無を設定します。デフォルトではプロシージャの中身をスロークエリログに出力する設定になってます。

mysql> SHOW GLOBAL VARIABLES LIKE 'log_slow_sp_statements';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| log_slow_sp_statements | …

とあるMySQLのデータベースで、性能劣化した疑いのあるプロシージャがありました。
プロシージャには複数のSELECTやINSERTが含まれています。

どのSQLが遅かったか突き止める方法はあるのでしょうか？
プロシージャに含まれている、各SQLはスロークエリログに落ちるんでしょうか？

試してみます。

テスト用に遅いプロシージャを作ります。

DELIMITER //
CREATE PROCEDURE sample()
BEGIN
  SELECT SLEEP(10);
END
//
DELIMITER ;

ログを出します。

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

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

…

あるクエリがperformance_schemaに記録されなかった。
原因を調べていて１つ記録されない条件を見つけたのでメモ。

まず、問題ないパターン。

mysql> SELECT NOW();
+---------------------+
| NOW()               |
+---------------------+
| 2019-07-30 10:40:47 |
+---------------------+
1 row in set (0.00 sec)

mysql> SELECT SQL_TEXT FROM events_statements_history;
+-------------------------------------------------------------------+
| …

TL;DR

• mysqldが 本当に 刺さって動作を停止している時のためのメモです。重いだけの時に使うものじゃない。
• ざっと見る方法であって、解決方法じゃない。

まずは慌てず騒がずエラーログを見る。クラッシュしてるログが出てるならそれはそれでOK。mysqld_safe とか systemd を使っている場合、 mysqld が自動再起動されているかも知れない。クラッシュリカバリーの真っ最中はプロセスが浮いていても接続できないので、クラッシュリカバリー中だったら見守る。 OOM Killerに殺された場合はエラーログに何も出ずにsyslogだけ吐くので、 /var/log/messages あたりもチラ見しておくと吉。 特にクラッシュはしていないようであれば、 dstat …

TL;DR

• 日々の覚書: MySQL 8.0.17でついにCloneプラグインが入った で紹介した CLONE LOCAL DATA は現在のdatadirをローカルのファイルシステムに一貫性のある形でコピーするステートメントだった
• これをスレーブになるサーバーに転送してやってももちろん良いんだけど、そこまで一括でやってくれる CLONE INSTANCE FROM のステートメントも存在する
• スレーブ増やすのが捗る

CLONE INSTANCE FROM を使うためには、データのコピー元（ ドキュメント 上では …

TL;DR

• MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された
  • CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す
  • CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい
• このへんを読んでおくのが良さげ
  • …

8.0.16でCHECK制約がサポートされました。
CHECK制約については、「yoku0825さんのブログ」や「MySQL Server teamのブログ」で詳しく解説されてます。

さて、「8.0.16でCHECK制約を設定したテーブルをCHECK制約に対応していない8.0.15で操作したらどうなるだろ？」という疑問が湧いたので試してみました。

CHECK制約を作るじゃろ？

mysql> CREATE TABLE check_constraint (pk SERIAL PRIMARY KEY, c1 int, CHECK(c1>0));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO check_constraint VALUES(1, -10);
ERROR 3819 (HY000): Check constraint 'check_constraint_chk_1' is …

MySQL Technology Cafe #4 に参加してきました。

State of the Dolphin - What's new in MySQL
Oracleのプリセールスのえらい人、Philipさんによる、MySQL 8の新機能のオーバビューでした。
Document Store、Build in HA / InnoDB Cluster、GISの改良、InnoDB Data Dictionary、CTE / Window Function、etc...

Mercari さんが Oracle Open World で Oracle Cloud の MySQL Analytics で話す予定だそうです！
私は、今年は参加できなそうですが、楽しみです（きっと日本でも話が聞けるでしょう）

MySQL Replication and HA at Facebook  Facebook の松信さんのお話！

…

MySQLどのようにテーブルスペースを復元しますか？

これは新しい情報ではありませんが、あまり取り上げていませんので、必要な人のためにここで取り上げます。

ibdファイルを紛失すると、データが失われます。 ですから、利用可能なもののコピーがある場合、または他のデータベースから同期している場合でも、それをインポートできます。 どのように/どのようにあなたはテーブルスペースを失いますか？

これはテーブルスペースを回復する簡単な例です。



mysql> Create database demo;

mysql> use demo;

mysql> CREATE TABLE `demotable` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `dts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, …

だから私は最近出てきたこのような状況の後、私はこれについての投稿をしていないことに気づいた。

シナリオは次のとおりです。バックアップは真夜中に行われ、データベースごとにMySQLダンプを使用しました。 それから翌日の午前10時にデータベースがクラッシュしました。 電話をかける前に一連のイベントが発生しましたが、MyISAMテーブルとIBDファイルがテーブルスペースにないデータベースのバージョンに到達しました。

そのため、オプション1、バックアップから復元すると深夜になり、何時間ものデータを失うことになります。 オプション2、私たちは何千ものibdファイルを再インポートしてすべてを保存します。 …