「MySQLのフェイルオーバーテストをする」と聞いてぼんやり思ったこと
TL;DR 負荷をかけながらフェイルオーバーテストをするなら、負荷クライアント側で「どの書き込みが成功したのか」のログは必ず取っておく でないと、フェイルオーバー起因でデータロストが発生するのかしないのかのチェックができない フェイルオーバーシナリオ スイッチオーバー(手動での切り替え)を含めてざっと思いつくのはこれくらい。 スイッチオーバー mysqldの正常終了 mysqldの異常終了、特に、mysqld_safeやsystemdがmysqldを再起動させてしまう環境 mysqldのハングアップ カーネルパニック ファイルシステムのハングアップ 電プチ スイッチオーバー たぶんHAソリューションを作る時にちゃんとテストするからこれはそんなに問題にならない気がするけれど、(レプリケーションベースのソリューションの場合)「レプリケーション遅延が起こってる時のスイッチオーバー」で何が起こるか
MySQL 8.0.17のCLONE INSTANCE FROMを使うとすごく楽にレプリケーションスレーブが作れる
TL;DR 日々の覚書: MySQL 8.0.17でついにCloneプラグインが入った で紹介した CLONE LOCAL DATA は現在のdatadirをローカルのファイルシステムに一貫性のある形でコピーするステートメントだった これをスレーブになるサーバーに転送してやってももちろん良いんだけど、そこまで一括でやってくれる CLONE INSTANCE FROM のステートメントも存在する スレーブ増やすのが捗る CLONE INSTANCE FROM を使うためには、データのコピー元（ ドキュメント 上では ドナー(Donor) ）とコピー先（同 レシピエント(Recipient) ）それぞれのMySQLでCloneプラグインが有効化されていないといけない。 donor> INSTALL PLUGIN clone SONAME 'mysql_clone.so'; recipient>
日々の覚書: utf8mb4_0900_ai_ci の速度をどう見るか
TL;DR MySQL 8.0からデフォルトの照合順序が latin1_swedish_ci から utf8mb4_0900_ai_ci になった さすがに latin1 をそのまま使っているとは思えないけれど、 utf8mb4 だけで見てもデフォルトは utf8mb4_general_ci から utf8mb4_0900_ai_ci に変更になっている 「思ったよりは遅くならない」と見るか、「そんなに遅くなるのか」と見るかは人による気がする まずは等価比較。 それぞれ10億回繰り返しているので、1回当たりの時間はナノ秒単位になる。 あと、データは保管せずただ比較しているだけなので、単純にCPU勝負のワークロードになる。 mysql80 8> SELECT BENCHMARK(1000000000, '1' = '1' COLLATE utf8mb4_0900_ai_ci) AS utf8
default_collation_for_utf8mb4 なんてパラメーターが追加になっていた
何このパラメーター、と思ったら、 utf8mb4 のデフォルトコレーションが utf8mb4_general_ci (MySQL 5.7とそれ以前) から utf8mb4_0900_ai_ci (MySQL 8.0)に変わったことに対する経過措置っぽかった。 これを utf8mb4_general_ci にセットしておくと、コレーションを指定せずに utf8mb4 を使った時に今まで通り utf8mb4_general_ci を使ってくれるということ。 mysql80 13> SELECT @@default_collation_for_utf8mb4; +---------------------------------+ | @@default_collation_for_utf8mb4 | +---------------------------------+ | utf8mb4_g
MySQL 8.0.4におけるデフォルト認証形式の変更
Incompatible Change: The caching_sha2_password and sha256_password authentication plugins provide more secure password encryption than the mysql_native_password plugin, and caching_sha2_password provides better performance than sha256_password. Due to these superior security and performance characteristics of caching_sha2_password, it is now the preferred authentication plugin, and is also the def
MySQLから大量のレコードをちまちま削除するメモ
「ちまちま削除する」なので、トランザクションでAll or Nothingを保証したい場合は使えない。 id をプライマリーキー（ただしサロゲートキーかどうかは問わない）、 hoge, last_update が本来消し込みに使いたいカラムだとする。 プライマリーキー（またはユニークキー）がないテーブルのことは考えない。 KEY(hoge, last_update) がある場合 ターゲットのプライマリーキーを取り出して DELETE .. WHERE id IN .. の形に落とし込む 行ロックに落とし込める idの型を選ばない（varcharだろうと使える） 自前でINリストを作るのが面倒ならGROUP_CONCATという手もあるけどその場合は group_concat_max_len に注意 DELETE の方でもとの条件をANDしておくのを忘れると事故ることがある。。 けどあんまりI
「MySQL 5.8に欲しい機能は？」って中の人がブログ書いてる件を3か月遅れで
Oracle MySQLの中の人、コミュニティーチームの Morgan Tocker のブログに、"MySQL 5.8に欲しい機能は？" とかいう、どストレートな記事がある。このエントリーはこのブログ…に寄せられた主に コメント の紹介。ブログ本文はタイトルがほぼ説明してるので。 記事自体は2015/09/14のものでちょっと古い（MySQL 5.7がRC2になったから、MySQL 5.8のプランを練ってる、みたいな書き方）んだけれど、出揃ったコメントが結構バラエティーに富んでいて、みんな本当に欲しいものが何なのかちょっと気になる。 CTE（共通テーブル式、WITH句）と窓関数！ https://bugs.mysql.com/bug.php?id=16244 あとこのへん http://www.slideshare.net/MarkusWinand/modern-sql CHECK制約！
MySQL 8.0のDROP TABLEがアトミックになっているっぽい件
MySQL 5.7とそれ以前で、「存在するテーブルと存在しないテーブルを一緒にDROP TABLE」しようとすると mysql57> CREATE TABLE t1 (num int); Query OK, 0 rows affected (0.01 sec) mysql57> CREATE TABLE t3 (num int); Query OK, 0 rows affected (0.01 sec) mysql57> SHOW TABLES; +--------------+ | Tables_in_d1 | +--------------+ | t1 | | t3 | +--------------+ 2 rows in set (0.00 sec) mysql57> DROP TABLE t1, t2, t3; ERROR 1051 (42S02): Unknown table '
MySQL 8.0.1でutf8mb4_ja_0900_as_csが導入された
Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 | MySQL Server Blog （ユーザーによる日本語訳: 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst）で言及されていた日本語用の照合順序 utf8mb4_ja_0900_as_cs 。 mysql80> SHOW COLLATION LIKE 'utf8%ja%'; +-----------------------+---------+-----+---------+----------+---------+ | Collation | Charset | Id | Default | Compiled | Sortlen | +-----------------------+-
AWS上でMySQL5.7動作環境を最速で作る方法(MySQL::Sandbox使用)
@sakaik さんの連載（？）を読んでいたらやたら楽しそうで俺もなんかビルドしたくなってたまらなくなったので。 - MySQLをビルドする on AWS Red Hat 7.3 - sakaikの日々雑感～(T)編 - ふたつのバージョンのMySQLを同時に動かす on AWS Red Hat 7.3 - sakaikの日々雑感～(T)編 - MySQL 5.7 のビルドにトライ ～ 5.6とは大違い - sakaikの日々雑感～(T)編 - MySQL 5.7 を t2.micro でもビルドできた！ - sakaikの日々雑感～(T)編 - AWS上でMySQL5.7動作環境を最速で作る方法(Generic binaries使用) - sakaikの日々雑感～(T)編 タイトルからわかるように、最後のエントリーに対抗してみました。 先に書いておくと、MySQL::Sandboxのイン
MySQLのCOUNTを速くする（？）SQL1本ノック その1
この記事は MySQL Casual Advent Calendar 2016 の19日目の記事です。 「MySQLのCOUNTが遅いなー」って言うと、「トリガーでサマリーテーブル作ったら？」と言われること、多くありませんか？ 特に @soudai1025 に言われる率が高い気がしています（個人の感想です） 個人的にはトリガーよりは同じトランザクションの中でカウンターテーブル（サマリーテーブルと違うもののつもりで言ってるけど、世の中でいうサマリーテーブルの中にはこの形式が含まれるかも知れない）をUPDATEする方が好き（だって、トリガーはブラックボックスになるんだもの）なんですが、頭の体操ということでトリガーで組んでみましょう。 サンプルテーブルはこんな感じ。 mysql57> SHOW CREATE TABLE game_score\G *************************
MySQL Routerつらくない（yumでインストールして動かしてみた編）
この記事は MySQL Fabric＆Routerつらくない Advent Calendar 2015 の3日目です。 昨日 の時点で、CentOS 6.6でMySQL Routerを試すには自前ビルドしないといけないことが判明しました。つらい だが俺にはDockerがある。CentOS 6.6の上でCentOS 7.1のコンテナー動かせばいいじゃん。systemdとか動かなそうだけど取り敢えず試すだけだからこういう時に便利ですよね！ つらくない！ $ sudo docker run -it centos:centos7 bash # yum install -y http://dev.mysql.com/get/mysql57-community-release-el7-7.noarch.rpm # yum install -y mysql-router .. Installed: my
MySQL Routerはつらくない。何故ならまだ触っていないからだ。
この記事は MySQL Casual Advent Calendar 2015 の1日目です。 MySQL Fabric＆Routerつらくない Advent Calendar 2015 の1日目でもあります。 さて…昨年あんなにも MySQL Fabric関連のブログ を書いたのに、少なくとも2015/12/1現在、MySQL Fabricがちっとも流行ってないのは何故だろうとか考えてみました。 Fabric対応コネクターが必要 MySQL 5.6以上かつGTIDが必要 バッキングストア（mysqlfabricデーモンが情報をストアするためのmysqld）を自前で冗長化しないといけない ググったら 「MySQL Fabric つらい」 とかサジェストされる やっぱり1ですかね。いや、あるにはあるんですが、俺（と、俺の勤めている会社）の利用可能な範囲になくて、Connecto/J, Con
MySQLのrootのパスワードを忘れてしまった…やその類似ケースを、mysqldを停止せずに何とかするメモ
MySQLのrootのパスワードを忘れてしまった…やその類似ケースを、mysqldを停止せずに何とかするメモ MySQLのrootパスワード忘れた、をググると、--skip-grant-tables を有効にして再起動せよ、というのにぶち当たるのが普通なんですが、カジュアルに再起動する訳にいかないことってあるじゃないですか。 そんなときのTIPS。 まず、ダミーのデータディレクトリをmysql_install_dbで作ります。これはrpmで入れた環境なので、/usrはbasedirです。 $ cd /usr $ bin/mysql_install_db --no-defaults --datadir=/home/mysql/dummy ここに、パスワードを変えたいMySQLのmysql.userテーブルをコピーします。少なくともMySQL 5.7.8現在、mysql.userはまだMyIS
Amazon RDS for MariaDBでできそうなこと、できなさそうなこと
TL;DR * Amazon RDS の MariaDB - Amazon Relational Database Service の方が詳しいですたぶん。 * InnoDBじゃなくてXtraDBが使いたい場合はアリです。 * スレッドプールが使いたい場合もアリです。 * サードパーティーなプラグインは使えなくなっています。残念。 * 単にユーザーとして観測できる範囲で調べて推測しているだけなので、違ったらごめんなさい。 MariaDB 10.0で使えるプラグインの一覧はinformation_schema.all_pluginsで参照できる。 mysql> SELECT plugin_name FROM ALL_PLUGINS order by 1; +-----------------------------+ | plugin_name | +--------------------
MySQL 5.7.9のinnodb_default_row_formatがまた何か企んでいるようです
MySQL 5.7.9では innodb_default_row_format というサーバー変数が追加される（らしい。5.7.9はリリース前なので試せない） オンライン変更可能なグローバル変数なので、`SET GLOBAL innodb_default_row_format= ..'で変更も可能。暗黙のデフォルトは"Dynamic"。 名前と値から察せられる通り、kamipoさん の悲願をかなえる類のもの…なんだけれども、 MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる これ、 The innodb_file_format configuration option is ignored if a table is created
論理削除Casual Talks #ronsakucasual でMySQLで論理削除する話をしてきた
論理削除 Casual Talks #1 : ATND に行ってきました。 アプリケーション方面では色々あるし、DBAから見ても良いことはないはず…と思ってましたが、 *ちゃんとMySQLの都合に沿ってやれば* 意外と忌避する理由もないことにふと気付きました。途中で3回くらいテーマ変更して最終的にこの形に落ち着いたカタチです。はふん。 ごめんなさい、当日流していたスライドに致命的な誤り（5.5以降ではなく、5.5以降 *ではない*）がありました。。まとめてくれた方ごめんなさい…＞＜ DBAっぽく、という背景があったので、「論理削除？ それUPDATEじゃん」というのが割と前提にあります。「DELETEじゃなくてUPDATEなんだから、削除とか言わずにスーパー非表示フラグでいいじゃん、システム的に *ちゃんとMySQLの都合に沿ってやれば* はそこまで変わらないし」というのが個人の見解です。
mysqldumpじゃないよ、mysqlpumpだよ in MySQL 5.7.8 （新機能編）
TL;DR MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。 ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は mysql40dump のようなラッパーを何かしら作る必要があります（レプリケーションの情報はテーブルに保存されていてそれはダンプに含まれるから
MySQL 5.7.8でまたsql_modeがちょっと変わるらしい
STRICT_TRANS_TABLESが暗黙のデフォルトになったことが俺の中で有名なMySQL 5.7ですが、MySQL 5.7.8でまたちょっと変更になるらしい。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.7 Server SQL Modes 5.7.4から5.7.7の間までは、STRICT_{TRANS|ALL}_TABLESは "5.6までのSTRICT_{TRANS|ALL}_TABLES" + "ERROR_FOR_DIVISION_BY_ZERO" + "NO_ZERO_DATE" + "NO_ZERO_IN_DATE" でした。 これが5.7.8からもとに戻ります。STRICT_TRANS_TABLESは5.6までのSTRICT_TRANS_TABLESと同じ効果を持つようになり、同時に暗黙のデフォルトにERROR_FOR_DIVI
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 TL;DR kamipo traditionalですら完全に防ぎきれないアレがあるので、そこを気にするなら出来る限りさっさとMyISAMからInnoDBに引っ越しましょう。 これらの記事を読んだ人向けです。 ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々 Javaでkamipo traditionalを有効にする - その手の平は尻もつかめるさ アプリでミスって不正なデータが入るくらいだった500になったほうがマシ。というのが個人的な考えです。 +激しく同意+ さて、激しく同意したところで、kamipo traditionalでは倒せないMyISAMという名の化け物の話をしたいと思います。 kamipo tr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
