oinume journal

Scratchpad of what I learned

Problems when updating MySQL from 5.7 to 8.0

Introduction

I updated MySQL from 5.7 to 8.0. There were some problems when updating. This is just a memo how to solve the problems.

InnoDB deprecated file format parameters

These parameters are deprecated in 8.0.

  • innodb_file_format
  • innodb_file_format_check
  • innodb_file_format_max
  • innodb_large_prefix

ref: MySQL :: WL#7704: InnoDB: Remove deprecated file format parameters in 8.0

Query cache parameters are deprecated

These parammeters are deprecated in 8.0.

  • query_cache_limit
  • query_cache_size

ref: https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/

innodb_support_xa

innodb_support_xa is deprecated as well.

ref: MySQL :: WL#8843: Deprecate and remove the parameter innodb_support_xa

Can't create users with GRANT

You can't create users with GRANT operation. For example, you need to change

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES ON db.* TO 'user'@'%' IDENTIFIED BY 'yourpassword'

like this:

CREATE USER IF NOT EXISTS 'user'@'%' identified by 'yourpassword';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES ON db.* TO 'user'@'%';

ref: How to grant all privileges to root user in MySQL 8.0 - Stack Overflow

default-authentication-plugin

The default value of default-authentication-plugin is caching_sha2_password. If your MySQL driver doesn't support the authentication method, you'll get an error this authentication plugin is not supported. mysql_native_password is the default value in MySQL 5.7 so you can specify it like this:

default-authentication-plugin = mysql_native_password

Other problems I've faced with

TABLE_NAMES from information_schema

My program executes following query.

SELECT table_name FROM information_schema.tables WHERE table_schema = 'mydb';

+------------------------------------+
| TABLE_NAME                         |
+------------------------------------+
| event_log_email                    |
| following_teacher                  |
| goose_db_version                   |
| lesson                             |
| lesson_status_log                  |
| m_country                          |
+------------------------------------+

The result of the query is TABLE_NAME in 8.0 although it was table_name in 5.7. As a result, I changed my query like this:

SELECT TABLE_NAME AS table_name FROM information_schema.tables WHERE table_schema = 'mydb';

mysqldumpで特定のレコードだけエクスポートする

忙しい人向けまとめ

  • mysqldumpの--whereオプションを使うと特定のレコードだけmysqldumpできる
  • --whereにはLIMIT句も指定できる
  • --whereオプションで大量のデータから一部だけをmysqldumpすることが可能

本文

mysqldump、データだけエクスポートしたりCREATE TABLEだけエクスポートできたり細かいところまで気が利いているなぁと思うツール。今日知ったのは --whereでdumpするレコードを限定できるよ、ということ。さらに、--whereにはLIMITも指定できるので、「特定の条件にマッチするレコード100件だけ」みたいなエクスポートもできる。

以下、具体例。

$ mysql -u <user> -p<password> <database>

mysql> CREATE TABLE hoge (
  id INT NOT NULL,
  name VARCHAR(255) NOT NULL,
  PRIMARY KEY (id)
);

mysql> INSERT INTO hoge VALUES (1, 'foo'), (2, 'bar'), (3, 'baz');

こんな感じでレコードを作って、--where 'id=1'を指定してmysqldumpしてみる。

$ mysqldump -u<user> -p<password> <database> hoge --where 'id=1'

(snip)
LOCK TABLES `hoge` WRITE;
/*!40000 ALTER TABLE `hoge` DISABLE KEYS */;
INSERT INTO `hoge` VALUES (1,'foo');
/*!40000 ALTER TABLE `hoge` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
(snip)

id=1のレコードだけmysqldumpされる。では次にORDER BYとLIMITをつけてみる。

$ mysqldump -u <user> -p<password> <database> hoge --where 'id>=2 ORDER BY id DESC LIMIT 1'

(snip)
INSERT INTO `hoge` VALUES (3,'baz');
(snip)

となって、idの降順でソートして1件だけmysqldumpができた。

まとめ

プログラムの動作検証のためにデータをmysqldumpしたいけど、本番データだとレコード数が多くて丸ごとmysqldumpするのがつらい時に--whereをつけると幸せになれるはず。

HerokuでMySQL 5.7系を使う方法

JawsDBというaddonを使うともれなく5.7系のMySQLが使える。2016年9月現在だと5.7.11。

elements.heroku.com

HerokuのデフォルトのデータベースはそもそもPostgreSQLで、MySQLを使いたい場合はこのJawsDBもしくはClearDBの2者択一なんだけど、ClearDBの方は5.5系しか使えない。安定してる5.5を取るか、最新版の5.7のどっちがいいかは悩ましいところだけど...

3ヶ月ぶりに書いたブログ記事がこれかよ...!

MySQL Casual Talks vol.9でしゃべってきた

表題の通りでMySQL Casualで「カジュアルに本番データを開発環境に入れる」というタイトルで発表してきました。

当日はカジュアルウォーターを飲んでしまい発表時に顔が真っ赤になっていましたが、おかげで全く緊張しませんでしたw

自分の発表があったのであまり他の人の話を聞く余裕がなかったのですが、いい感じにまとめられていたのでこれからじっくり読もうと思います。

togetter.com

会場を提供してくれたYahoo!さんありがとうございました!

Amazon RDS for Aurora 東京ローンチ記念セミナー

Auroraの検討を導入していることもあり、11/10のAmazon RDS for Aurora 東京ローンチ記念セミナーに行ってきたのでそのメモ書きと感想。

Debanjan Saha, GM, Amazon Aurora

Auroraチームの人。AuroraはAWS史上最速で成長しているサービスと言っていた。

エンタープライズ顧客の要望リスト

  • 専門家部隊がいなくても運用・管理できる
  • ライセンス管理しなくてもいい

MySQL互換のリレーショナル・データベース

  • 商用DB並のパフォーマンスと可用性
  • OSS DBの使いやすさとコスト効果
  • 3箇所のデータセンターに6つの複製を保持
  • 30秒以内でフェールオーバー
  • 50万 Read IOPS
  • 10万 Write IOPS
  • 64TB Storage - DBに最適化したストレージ

Aurora使っている会社

  • Expedia
  • GE Oil & Gas
  • Alfresco

などなど。

Expedia

  • 現行のSQL Serverベースのアーキテクチャはデータボリュームの増加と共にパフォーマンスの低下が見られた
  • Cassandra + Solrを組み合わせたインデックスは大きなメモリー空間を必要としてコストを押し上げた
  • Auroraはスケーラビリティとパフォーマンス要件を満たし、コストもずっと低かった
  • 平常時25K INSERT/sec (Peak 70K)
  • 平均レスポンスタイムはWrite 30ms, Read 17ms

PG&E

  • 天然ガス+電力の公益企業
  • 電力関係のイベントが起きた際に突発的なトラフィックを処理しなくてはいけないという課題
  • データベースが落ちた時の影響が大きい
  • 遅延のほとんどないRead Replicaを複数持つことができるため、電力化kん京のイベントが起きた際の突発的なトラフィックを処理し、顧客に最新の情報をタイムリーに提供できるようになった

ISCS

  • 保険請求処理
  • Oracle + SQL Serverを通常業務ならびにウェアハウスデータ用に使用
  • コストが大きな支出となっていた
  • 余裕をもたせた状態のAuroraのコストがSQLServerの構成よりも70%やすかった
  • Auroraの連続的なバックアップ機能により、バックアップ処理ウインドウを廃止できた

ThreatStack

  • AWS顧客に対し連続的なセキュリティ監視を提供
  • 脅威分析のために大きく連続したデータストリームを扱う
  • 50万INSERT/sec, 1日の生データは10TB
    • Cassandraからの移行
  • Auroraを時系列データを扱うDBとして使用

Architecture

  • Three AZ and 6 data replica
  • Quoram
  • Peer-to-peer gossip Replication
  • Continuous S3 backup
  • Storage node check and failure and repair

高速なクラッシュリカバリ

  • 最後のチェックポイントからのログを適用する必要がある
  • AuroraはDisk readの一環としてオンデマンドでredo logの適用を行う
    • 並列・分散・非同期で行われる
    • 起動時に実行する必要がない

フェイルオーバー時間

  • Failure Detection(15-30sec), DNS Propagation(5-20sec)
  • Aurora + MariaDB Driverを組み合わせることにより30秒未満でフェイルオーバーできる

バックアップ

  • 通常のデータベースはバックアップウィンドウの時間があるが、Auroraは継続的にバックアップしている
  • DBサイズが大きければ大きいほど時間がかかる

なぜAuroraは速いのか

  • IOを減らす
  • ネットワークパケットを最小限にする
  • 結果をキャッシュしておく

Advanced Monitoring

  • より詳しいOSの統計情報がとれるようになる予定
  • 1秒単位でメトリクス取得可能

お金の話

  • No idle standby instance
  • Single shared storage volume
  • NO POIPs - pay for use I/O (Provisioned IOPSが不要)
  • 21.4% Savings
  • さらにパフォーマンスがいいので、MySQLおり小さいインスタンスでもいいかも

質疑応答

  • MySQLだとデータ量が多いとAlter tableが遅い問題
    • Online DDLについては改善予定(3-6ヶ月以内)
  • r3以外のインスタンスについて
    • t2 instanceについては検討中
    • mやcのタイプはあまり検討していない
  • メモリに乗らないAlter tableはOOMが出る?
    • 大体の問題は対応済み
  • MHAのような数秒単位でのインスタンス入れ替えは可能?
    • できないので、Read replica作ってそこにフェイルオーバーさせる

RDS for MySQLからAuroraへの移行

ラニ吉崎さん

スライド

どのような変化があったか

  • UPDATEの高速化(16.2ms -> 2.84ms)
  • INSERT(2.9ms -> 1.3ms)
  • DELETE(0.8ms -> 1ms)
  • SELECTはあまり変わってない

Migration

  • Amazonの移行ガイドを読む
  • 移行方法
  • SQL_Modeは0にする

SNAPSHOT Migration

  • 120GB: db.r3.4xlarge
    • マイグレーション素養時間:01:37h
    • レプリカ作成所要時間  :00:06h(これは常に6分!!)
  • 1100GB: db.r3.8xlarge
    • マイグレーション素養時間:10:42h
    • レプリカ作成所要時間  :00:06h(これは常に6分!!)

Replication Migration Summary

Cluster & DB Parameters

High CPU / Memory / QueueDepth

  • RDS for MySQL: 60%声から著しい性能劣化
    • Connnection拒否や応答しないなど

今後に期待したいこと

  • Failover order
  • Mandatory Cache purge

ドワンゴがAurora使ってみた(仮)

ドワンゴでの開発

  • 多数のサーバーやネットワーク機器
  • サーバーはHWから自作しようとしてる

AWS導入サービスの増加

  • Dwango Reader
    • アプリケーションレイヤーで水平分割
    • 大量の記事データ

Aurora

  • 空き領域の再利用は効率よく行われている
    • 3.05% -> 2.67%
  • パフォーマンス
    • 最大64TBまでシームレスにサポートされる点の安心感
  • MySQLとの互換性はLDRとしては十分

ウルシステムズの漆原さん

Oracle使ってるようなエンプラからの移行

  • モノリシックなアーキテクチャ
    • 顧客テーブルをみんな参照しているとかw
    • DB変更に弱い。何箇所も影響あり
  • マイクロサービス化でさらなる効果を
    • 特定の技術にロックインされない(でもカオスになる可能性もある)

マイクロサービスについて

  • JSON/REST, HTTP
  • エラー処理
  • キャッシュ
  • サービスモニタリング
  • 統一のログ取得
  • 独立したディプロイ

Aurora活用のステップ

感想

現在開発環境でAuroraを試していて、アプリケーションは一切いじらずに普通に稼働していてMySQLとの互換性の高さを感じている。あとはALTER TABLEした時の挙動とか負荷試験をして問題なければ導入する予定。

Auroraを導入するメリットとしては

  • 事前にディスク容量やIOPSを考える必要がない(勝手に拡張されていく)
  • Master/Slaveは同じデータを見ているので運用が楽になる
    • レプリケーションを考えなくていいので、精神的にもストレスがなさそう
    • Slave(Read Replica)を作るのが一定の時間で終わる
  • コストメリット
    • 事前にEBS容量を確保しなくていいので無駄がない
  • 書き込みが速くなる

などかなぁと思ってる。でで、特にAuroraへの移行の話は参考になって、データ容量が少なければスナップショットからの移行が一番楽そうだなと思っているところ。

とにかくMySQLを利用するような値段でWrite10万IOPS出るようなDBが使えるのはすごい。これはもうFusionIOとかいらなくなる予感がしている。