Mysqlをちょっと濃い目に調査することになったので、覚書用にまとめを作成した。
面白そうなものはざったに収集してあるので、MECEになっていないことに注意されたし。
Mysql5.7 新機能・インストール
MySQL 5.7の新機能完全リスト
https://yakst.com/ja/posts/3037
MySQL 5.7の罠があなたを狙っている
http://www.slideshare.net/yoku0825/mysql-57-51945745
MySQL 5.7 をインストールしたら最初に行うセットアップ
http://weblabo.oscasierra.net/mysql-57-init-setup/
MySQL 5.7におけるサーバーのデフォルト値の改善 (MySQL Server Blogより)
https://yakst.com/ja/posts/2733
MySQL 5.7以後のレプリケーションのデフォルト値(MySQL High Availabilityより)
https://yakst.com/ja/posts/3726
MySQL 5.7で削除または廃止予定となる機能について (MySQL Server Blogより)
https://yakst.com/ja/posts/2552
設計時の検討事項、トラブル
MySQLをインストールしたら、必ず確認すべき10の設定
https://yakst.com/ja/posts/200
[Q&A]MySQL開発でやってしまいがちな致命的ミス
https://yakst.com/ja/posts/686
レプリケーション
Mysql HA
冗長化構成についての資料
Best practices for MySQL High Availability
http://www.slideshare.net/bytebot/best-practices-for-mysql-high-availability
HA Proxy
Mysqlのロードバランサ
HAProxy v1.6を使って複数のRDS Read Replilcaに分散させる
http://uorat.hatenablog.com/entry/2016/05/29/173717
マイクロサービス時代のHAProxy
https://yakst.com/ja/posts/3429
MySQL Fabric、Mysql Router
MySQL Fabric・・・Mysqlの自動フェイルオーバーツール Mysql Router・・・Mysqlのロードバランサ
MySQL Fabric&Routerつらくない Advent Calendar 2015
http://qiita.com/advent-calendar/2015/mysql_fabric
MySQL Routerをlocalhostに置いたらどれくらいの遅延になるかを考えるメモと、MySQL Routerは本当につらくなかったのかのまとめ
https://yoku0825.blogspot.jp/2015/12/mysql-routerlocalhostmysql-router.html
MHA for MySQL
Mysqlの自動フェイルオーバーツール
MySQLのMasterフェールオーバのためのMHAのインストールと設定
http://blog.takanabe.tokyo/2016/05/04/2410/
MaxScale
MariaDB社の開発した自動フェイルオーバーツール。ReadWrite Splitting対応。但し、単純に作るとSPFになりそうな予感。
MaxscaleのLimitations and Knownを読んでみた | 俺的備忘録 〜なんかいろいろ〜
https://orebibou.com/2016/04/maxscale%E3%81%AElimitations-and-known%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%81%BF%E3%81%9F/
Mysql replication
MySQL 5.7入門(レプリケーション編)
http://downloads.mysql.com/presentations/20151207_02_MySQL_Replication_for_Beginners.pdf
データのロストは発生するか?
https://yakst.com/ja/posts/3363
※準同期、非同期、同期レプリケーションや、ステートメントベース、行ベースレプリケーションの違いなど詳しい技術情報が記載されている。
GTID有効、準同期(AFTER_SYNC)、行ベースレプリケーションにすべきか。
ステートメントベースレプリケーションの場合、SQL分を転送してINSERT、UPDATEを行う為、複雑なSQLでデータ挿入、更新処理を行っていると、マスターサーバと同じだけスレーブサーバにもデータ処理負荷がかかる。またステートメントベースだと、UUID()、NOW()など非決定的な関数処理の場合、同一データがレプリケーションされていなかった。
ただ行ベースだと更新データをすべてログ転送するため、ネットワーク負荷がかかる。
MIXだとステートメントベースだとトリガーが動作するけど、行ベースだとトリガーが動作しない為、トリガー使う場合には、どちらかに統一しないとスレーブ側の動作が、コントロール出来なくなりそう。
MySQL Fabric、MySQL Routerは宣伝はあるけど、今は遠慮すべきか。。。
DRBD replication
IOデバイス同期システムを使ったレプリケーション
How To Configure Data Replication/Synchronize Using DRBD
https://www.youtube.com/watch?v=oGIpo1SoSdY
How To Configure Data Replication/Synchronize on CentOS 6 Using DRBD
http://imanudin.net/2015/03/22/how-to-configure-data-replicationsynchronize-on-centos-6-using-drbd/
Testing Data Replication/Synchronize on DRBD
http://imanudin.net/2015/03/23/testing-data-replicationsynchronize-on-drbd/
※DRBRだと遅延に応じて、パフォーマンスが2割などがっつり劣化する。
その代わりデータの消失などには強そう。
長い歴史があり、安定しており、設定もすんなり動いた覚えがある。
昔はデータの同期タイミングのずれが大きくなるとサーバダウンしていたが、今はどうか?
Semi-Synchronous replication
Mysql5.7から更新処理にもまともに利用できるようになった準同期レプリケーション
MySQL互換のPercona-Serverで準同期レプリケーションを作る
http://qiita.com/jun_ya/items/05e895b40d32c6acede2
最強のMySQL HA化手法 - Semi-Synchronous Replication
http://nippondanji.blogspot.jp/2009/03/mysql-ha-semi-synchronous-replication.html
MYSQL5.7におけるレプリケーションの改良
http://variable.jp/2015/04/27/mysql5-7%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%AC%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%94%B9%E8%89%AF/
※5.7以前のものはWebシステムのリード最適化には使えたが、データを厳密に扱う業務システムでHA用途に使うには辛かった。
5.6になり、GTIDでレプリケーションしているサーバ全体でトランザクション管理出来るようになり、
5.7で、バイナリログ転送は同期、マスタサーバコミットタイミングで情報をスレーブにも反映するようになり、データの不整合が起こらなくなった。
パフォーマンスチューニング
パラメータ設定など
MySQL 5.7入門(チューニング基礎編)
http://downloads.mysql.com/presentations/20151208_02_MySQL_Tuning_for_Beginners.pdf
MySQLチューニング
http://www.slideshare.net/yoku0825/mysql-31789267
MySQLのメモリー使用量を最適化する設定のベストプラクティス
https://yakst.com/ja/posts/3983
インテル コンパイラーの実力を測る――インテル コンパイラー版MySQLは本当に速いのか?(情報としては古い)
https://osdn.jp/magazine/09/02/18/1117225
(帰ってきた)InnoDBパフォーマンス最適化の基礎
https://yakst.com/ja/posts/65
SQLチューニング
ヤフー社内でやってるMySQLチューニングセミナー大公開
http://www.slideshare.net/techblogyahoo/mysql-58540246
MySQL 5.6と5.7における高度なクエリチューニングのQ&A(The Percona Performance Blogより)
https://yakst.com/ja/posts/2974
MySQLのオプティマイザヒント(MySQL Server Blogより)
https://yakst.com/ja/posts/2781
Optimizer TraceとMySQL 5.7におけるEXPLAIN FORMAT=JSON
https://yakst.com/ja/posts/2568
MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法
https://yakst.com/ja/posts/2462
MYSQLインデックスの基礎 その2 : 2つのクエリの違いとオプティマイザの判断
https://yakst.com/ja/posts/2385
パラメータチューニングツール
MySQL Performance Tuning Scripts and Know-How
http://www.askapache.com/mysql/mysql-performance-tuning/
ベンチマークソフトウェア
ベンチマークソフトウェアと使い方について
SysBench で MySQL の性能測定(ベンチマーク)
https://blog.apar.jp/linux/3350/
残暑なんて吹き飛ばすぐらい熱いベンチマークをやろうぜ!!
http://nippondanji.blogspot.jp/2010/08/blog-post_30.html
MYSQL BENCHMARKING
http://www.fromdual.com/mysql-benchmarking
ベンチマーク結果
MySQL 5.7 read-write benchmarks
https://www.percona.com/blog/2016/05/17/mysql-5-7-read-write-benchmarks/
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較
http://blog.father.gedow.net/2015/10/23/benchmark-of-mysql57-rds-aurora-cloud-sql/
セキュリティ
セキュアでない接続を特定する(MySQL Server Blogより)
https://yakst.com/ja/posts/2991
参考情報
innodb_file_per_tableが有効な時にディスク容量を開放するには
https://yakst.com/ja/posts/68
Linux
プロセスとスレッドの違いとは?
https://yakst.com/ja/posts/39
※Mysqlはスレッド非対応、MariaDB、PersconaDBはスレッド対応。
6万ミリ秒でできるLinuxパフォーマンス分析
https://yakst.com/ja/posts/3601
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング
http://blog.yuuk.io/entry/linux-networkstack-tuning-rfs