このブログでは、さまざまなMySQL高可用性オプションについて考察します。
ダイナミックなMySQLエコシステムは、MySQLを中心に構築された多くの技術を急速に進化させています。これは、MySQLの高可用性（HA）の側面に関連する技術に特に当てはまるでしょう。 私が2009年にPerconaに入社したとき、こういったHAの技術のいくつかは非常に人気がありましたが、それ以来ほとんどは忘れられています。その同じ期間で、新しい技術が登場しました。読者にいくつかの視点を提供しながら、出来ればより良い選択をする助け�になるように、2017年のMySQL HAの展望をレビューしようと思います。このレビューは3つのパートに分かれています。最初のパート（この記事）は、長年に渡って存在していた技術、すなわちthe …
[さらに読む]TL;DR
とある事情があってInnoDBのAUTO_INCREMENT関連のコードを読んでいた時に、innobase_next_autoincの中でこんなコードになっていることに気が付いた。
2497 if (block >= max_value
2498 || offset > max_value
2499 || current >= max_value
2500 …[さらに読む]
TL;DR
sql_mode=ONLY_FULL_GROUP_BY 依存
別のものを調べている時に /var/log/messages を見てたら、なんかがコア吐いてるのに気が付いた。
Jun 20 04:26:42 archive_host kernel: mysqldump[28611]: segfault at 0 ip 00000030b152859a sp 00007fffd760a358 error 4 in libc-2.12.so[30b1400000+18b000]
Jun 20 04:26:42 archive_host abrtd: Directory 'ccpp-2017-06-20-04:26:42-28611' creation detected
Jun 20 04:26:42 archive_host abrt[28613]: Saved core dump of pid 28611 (/data01/mysqlbin/mysql-5.6.20-linux-glibc2.5-x86_64/bin/mysqldump) to /var/spool/abrt/ccpp-2017-06-20-04:26:42-28611 (2609152 …[さらに読む]
4月にMySQLの日本語コレーションについて語り合う場に呼ばれていろいろ話を聞いてきました。すぐにブログを書こうと思ったんですが、はや2ヶ月経過…。
ときどき、自分がMySQLの文字コードに関して発表する際に、次のようなスライドをいれてるんですが、
MySQL 8.0 でとうとう日本語コレーションが入ることになったのに、なんか期待してたのと違いました。
で、その辺の話を聞きました（2ヶ月も経ってるのでうろ覚え）。
Q. わざわざ日本語ロケール作るんだったら日本人が扱いやすいロケールにしてほしい
…[さらに読む]MySQL Group Replicationは、グループで一つのIDを持つ為、通常のシングルインスタンスと同じようにレプリケーションを組む事が出来ます。4月のInnoDB Clusterリリース以降、MySQLを利用されているお客様から、幾つか質問を受けていたので念の為に挙動を再確認。
環境
複数サーバーを準備出来なかったので,シングサーバーにポートを変更して、2グループ(6サーバー)で先ずはGROUP
REPLICATIONを準備。
mysql> select @@version; +-------------------------------------------+ | @@version | +-------------------------------------------+ | 5.7.18-enterprise-commercial-advanced-log | +-------------------------------------------+ 1 row in set (0.00 sec)
…
[さらに読む]大阪で話した内容とほぼ一緒なのですが、、、MySQL Shell を試してみました。 OSC 2017 Okinawa MySQL の高可用性構成比較 と新機能 Group Replication from Satoshi Mitani OSC Hokkaido も参加したので、これで南は沖縄から北は北海道まで行ったと言える・・・！
MySQL 5.6と同じ方法でMySQL 5.7を起動しようとしたら何も言わずに黙って終了してしまって少しだけハマったのでメモ。
MySQL 5.6では次のようにして起動してました。
# /usr/local/mysql-5.6/bin/mysqld --no-defaults --user=mysql
--basedir=/usr/local/mysql-5.6 --skip-networking --socket=/tmp/mysql56.sock
--log-error=/tmp/my56.err > /tmp/my56.err 2>&1
log-error をつけていても、最初の数行が標準エラー出力に出ちゃうので、log-error と同じファイルにリダイレクトするようにしていました。
同じようにしてMySQL 5.7を起動してみたら、すぐに終了してしまって、しかもエラーを何も出力しません。
# /usr/local/mysql-5.7/bin/mysqld --no-defaults --user=mysql
--basedir=/usr/local/mysql-5.7 --skip-networking --socket=/tmp/mysql57.sock
--log-error=/tmp/my57.err > …[さらに読む]
InnoDB Clusterを構築すると、MySQL Routerの設定ファイルが自動的に作成されます。基本的にはTTLによって構成はキャッシュされますが、metadata cache componentが常にMySQLに接続していて、Group Replicationの状況をモニタリングしています。それにより、構成変更や障害発生時には自動的に検知してアプリケーションを適切なデータベースに振り分けてくれます。
【以下、マニュアル抜粋】
MySQL Router keeps a cached list of the online MySQL servers, or
the topology and state of the configured InnoDB cluster.
Initially, the list is loaded from Router’s configuration file
when Router is started. This list was generated with InnoDB
cluster servers when Router was bootstrapped using the –bootstrap
option.
To keep the cache updated, the metadata cache component keeps an open connection to one of …
[さらに読む]免責事項
この記事はMorgan Tocker氏によるMySQL Server Blogの投稿「MySQL 8.0: Retiring Support for the Query Cache」(2017/5/30)をユーザが翻訳したものであり、Oracle公式の文書ではありません。
MySQLのクエリーキャッシュはパフォーマンスを改善するためにあるが、それは重大なスケーラビリティー上の問題を抱えていて、深刻なボトルネックに簡単になってしまいかねない。
…
[さらに読む]