この記事は Perl Advent Calendar 2021 と MySQL Advent Calendar 2021 の3日目の記事です。 Perl Advent Calendar 2021 の1日目2日目が @hkoba さんのいい話だった流れを遮って、突然のユルいプログラム紹介です。 MySQL Advent Calendar 2021 の2日目は @meijik さんでした。 俺はMySQLが好きでPerlも好きなので、MySQL関連の何かがPerlで書かれているとちょっと嬉しくなります。 Perlはそんなに得意ではないですが、MySQLに絡んでいれば大体何となくわかるものです。 innotop がそれを教えてくれました(俺が %hash=(); @hash{"hoge", "fuga"}= qw{ a b } の記法を知ったのはinnotopが使っていたからです… ) 逆に、P
TL;DR 負荷をかけながらフェイルオーバーテストをするなら、負荷クライアント側で「どの書き込みが成功したのか」のログは必ず取っておく でないと、フェイルオーバー起因でデータロストが発生するのかしないのかのチェックができない フェイルオーバーシナリオ スイッチオーバー(手動での切り替え)を含めてざっと思いつくのはこれくらい。 スイッチオーバー mysqldの正常終了 mysqldの異常終了、特に、mysqld_safeやsystemdがmysqldを再起動させてしまう環境 mysqldのハングアップ カーネルパニック ファイルシステムのハングアップ 電プチ スイッチオーバー たぶんHAソリューションを作る時にちゃんとテストするからこれはそんなに問題にならない気がするけれど、(レプリケーションベースのソリューションの場合)「レプリケーション遅延が起こってる時のスイッチオーバー」で何が起こるか
TL;DR MySQL 5.6とそれ以前のはなし。5.7とそれ以降はこの初期設定は入っていない。 MySQL 5.6でもインストール方法によっては存在しないし mysql_secure_installation を使った場合はこの設定は消されるし、MySQL 5.7とそれ以降だろうと5.6からインプレースアップグレードやmysqlスキーマまで含めたフルリストアでアップグレードした場合は設定は残っているだろう 昔のMySQLは test というスキーマを mysql_install_db で作ってしまって、しかもこのスキーマは全アカウントに対して(ストアド以外の)読み書き権限がある GRANT USAGE しかないアカウントでも平気で CREATE TABLE も INSERT も一通りできる ついでに言うと test スキーマだけじゃなくて test_1 スキーマにも同じことができる。 t
とりあえず8.0.26で実験する。 INSERT IGNORE INTO といえば、キー重複エラーを握りつぶして複数のINSERTを「先勝ち」であるかのように振る舞わせるのに使われることが多いやつ。 mysql80 10> CREATE TABLE t2 (pk int PRIMARY KEY); Query OK, 0 rows affected (0.02 sec) mysql80 10> INSERT INTO t2 VALUES (1); Query OK, 1 row affected (0.01 sec) mysql80 10> INSERT INTO t2 VALUES (1); ERROR 1062 (23000): Duplicate entry '1' for key 't2.PRIMARY' mysql80 10> INSERT IGNORE INTO t2 VALU
準同期レプリケーションで、でかいテーブルをDROP TABLEした時の死にポイント on 5.7.34 TL;DR dict_sys のmutexを取るのでDDL系は死ぬし新しくテーブルキャッシュを作れないのでテーブルキャッシュが枯渇すると死ぬ ROLLBACK も dict_sys のmutexを取るので死ぬ。 COMMIT はできる。 実はGroup Replicationまたは準同期レプリケーションを使っていると、更新系DMLの中に dict_sys を使う処理が追加されるのでこっちはいきなりDMLが刺さる。 試したのは5.7.34だけ。他のバージョンの動作は知らない。この動作は単純にunlink中のmutexの話なので、バッファプールの大小にはよらない。【2022/08/01 11:21】この実験は単純にunlinkを遅延させて測っているだけなので、バッファプールの大小はまた別の問
TL;DR Setting up the development environment の通りに ~やるつもりがない人または~ やっても上手くいかなかった人向け ほら、テストしたいバージョンがいろいろある人とかさ Setting up the development environment は一通り目を通しておいた方が良い気がします。 Percona Toolkitのテストは MySQL::Sandbox っぽいスクリプトを内包していて、バイナリをポンと置いて環境変数をセットするだけで、3つくらいの mysqld を起動してそれに対してテストを走らせてくれます。 というわけでまずは mysqld 実行ファイルが必要。PXCのテストをするつもりでないなら吊るしのMySQLでも良い。ただし INSTALL_LAYOUT=STANDALONE を想定しているので、rpmでインストールするのはダ
2024 ( 22 ) 9月 ( 2 ) 8月 ( 2 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 東京都オープンデータカタログサイトのCSVを使ってLOAD DATA LOCAL INFILEの練習をする サイボウズさんの開運研修
innodb_autoinc_lock_mode = 1 vs 2 でバルクインサートが競合した時のAUTO_INCREMENTの挙動が違うはなし TL;DR innodb_autoinc_lock_mode のデフォルトはMySQL 8.0で2になった(5.7とそれ以前は1) innodb_autoinc_lock_mode= 2だとステートメントベースのレプリケーションではアンセーフだ 、というのはよく語られるけど INSERT INTO .. SELECT .. や LOAD DATA .. でauto_incrementで連番を払い出すようなステートメント同士が競合すると、1と2で差が出る SELECT LAST_INSERT_ID() からの、SELECT .. WHERE id > その値 みたいなクエリーを使っている時は気を付けた方が良い鴨 MySQL localhost:
TL;DR MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい このへんを読んでおくのが良さげ MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.13 Clone Plugin Limitations mysql
TL;DR information_schema.tables ( SHOW TABLE STATUS はここから値を持って生きている)の値は information_schema_stats_expiry 秒間更新されない なので SET SESSION information_schema_stats_expiry = 0 とかするとほぼ今まで通りの挙動になる See also, MySQL Bugs: #91038: AUTO_INCREMENT does not increase automatically mysql80 111566> SHOW TABLE STATUS\G *************************** 1. row *************************** Name: t1 Engine: InnoDB Version: 10 Row_
TL;DR なんか SELECT * FROM t1 WHERE CONCAT('',c1 * 1) != c1 であぶりだせるらしいけどなんで? と聞かれたのでその解説。 俺は↑のやり方初めて聞いた。。 個人的には WHERE c1 NOT RLIKE '^[0-9][0-9]*$' でいいんじゃない? と思う。 前提(?) 「数値しか入らないはずのカラムに文字列が入っていてバッチが転けてるので削除しました」 「?? カラムの型は?」 「varchar型です」 「ちょwww」 こんな状態 mysql57 8> SELECT num FROM t1; +----------------------+ | num | +----------------------+ | 1 | | 2 | | 3 | | 4 | | \(^o^)/オワタ | | 0x12345 | | 123hoge456
OPTIMIZE TABLE, ALTER TABLE .. Engine = InnoDB で空き領域が回収できることがわかっている SELECT table_schema, table_name, data_free FROM information_schema.tables WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') ORDER BY data_free DESC; とかで調べましょう 短時間(容量による)のメンテに入れられる オンラインの ALTER TABLE .. Engine = InnoDB では容量があふれそうである(または負荷的に耐えられないのでメンテに入れた方がマシ) MySQL 5.6.17とそれ以降はオンラインでできる(ただしフルテキ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く