State of the Dolphin - What's new in MySQL
Document Store、Build in HA / InnoDB Cluster、GISの改良、InnoDB Data Dictionary、CTE / Window Function、etc...
Mercari さんが Oracle Open World で Oracle Cloud の MySQL Analytics で話す予定だそうです！
私は、今年は参加できなそうですが、楽しみです（きっと日本でも話が聞けるでしょう）
MySQL Replication and HA at Facebook
Facebook の松信さんのお話！
facebookでは各リージョンにMySQLサーバは一台。読み取りはリージョン内で完結させる。書き込みはリージョンをまたぐ。書き込みは読み取りよりレイテンシが大きくなる。読み取りが多いサービスなので許容している。書き込みもリージョン内で完結させるとすると（クロスリージョンしない） 、マスターが存在しないリージョンのアプリケーションサーバは、書き込みリクエストを受けることができなくなります。もし、マスターの存在しないリージョンで書き込みを受け付けてしまうと、クロスリージョンで書き込むことになり、書き込みをリージョン内で完結できません。片方のリージョンをアクティブに運用し、他のリージョンはスタンバイとして待機させておくことになるでしょう。
アプリケーションサーバとDBサーバの通信をリージョンをまたぐかどうかは、設計する際に話題になることが多いのですが、頭の中で整理できてなかったので、facebookの事例を聞いて整理できてよかったです。 「あのfacebookでさえ、書き込みはクロスリージョンですよ！」と言いたいと思います（笑）
以下、そこまでやるのぉ！と思ったfacebook 魔改造？たち。
Dependency Replication: スレーブでのレプリケーションの並列度を高めて、レプリケーションを速くする仕組み。トランザクション同士が並列実行できるかどうかを判断するだけでは、マスターと同じレベルの並列度は達成できない。バイナリログからレコードレベルで並列に実行して問題ないトランザクションかを判定するようにパッチを当ててる。
マスターとLBU（semi-sync スレーブ）のレイテンシは書き込みパフォーマンスに直結する。マスターとLBUの間の通信は優先度を高くするため、パケットにタグ付けしてる。
RBR COMPLETE Format: binlog_row_image=MINIMALとFULLの中間。変更前のデータは全てロギングし、変更後は変更があったカラムのみ記録する。情報量は変わらず、容量を削減できる。あと、カジュアルに「マスターがダウンしたら、SplitBrainしないよう複数台で合意形成した上で、CHANGE MASTERして、 カタログを更新してAPの向き先を新マスターに・・・」と仰ってたのが「facebook強い」なと思いました。多くの人は、そこをどうするかで悩んでると思う（笑）
今日の話は、5月のPercona Live でも話された内容・・・ということで、
一部は tombo さんのPercona Liveのレポート にも内容が書いてあります。
