MySQL8.0atFBのセミナーに行ってきた
こんにちは。smallpalaceです。
mysql8.0とFacebookの中の人がMySQLどうつかってるか話すセッションのあるセミナに7/5に行ってきましたので備忘録です。
https://eventreg.oracle.com/profile/web/index.cfm?PKwebID=0x560881abcd
ーーー
8で大きく変わったもの
GISをサポートし球面座標で改良されている ユニコードをデフォルトキャラクタセットに、マルチバイトがデフォルトに
目指してるのは大量データを扱うｔころ
Jsonデータ型、アプリケーション開発者に柔軟性を。更新性能最適化、関数を追加してSQLに近い操作
新規、データ分析処理の効率向上
共通テーブル式、WITH句一回つくったものを使いまわす Windows関数、ランキング作成などの分析用とで
アプリケーションの性能拡張性向上 アクセス集中時の対応改善 不可視インデックス パフォーマンススキーマ ヒント区によるセッション変数変更
MySQLサーバの性能拡張性向上
セキュリティの強化 SQLロールの実装、 ログファイルの透過的暗号化 バイナリログは開発中
Window関数 国ごとの売り上げ 国ごとのトップセールスマンの売り上げ 1位以外を出すときに手間がなくなる例の紹介が
Jsonデータ型 インサート時に誤りがあったらバリデーションチェックが入ったり JSONとGeneratedColumns ファンクショナルインデックス カラムとして持つことができる 値の実態はもたないメタデータ 仮想カラムにインデックスを付与することができる
属性情報を更新する
JsonTable関数 目指しているのは、リレーショナルとドキュメントデータベース選ばなくてもハイブリッドとしてつかえるように
MySQLShell 使った操作ができるようになりましたと
データベースの操作ご案内
ROLE SHA256 のキャッシュで毎回セキュアな情報を暗号化
InnoDBのRedログUndoログ
コミュニティ版もOpensslをリンクするようになった
マスタが障害にあったときデータを引き継いで昇格したい グループレプリケーションでできる
InnoDBがついてないMySQLクラスタ（NDBCLUSTER) 1年かけて7.6GA シャーディングロードバランシング、高可用性 インメモリデータベースで共有ディスクで分散型シェアードナッシングアーキクチャ サービス停止することなくローリングアップデートなどが可能 リアルタイム性と高可用性 ノード間でデータを持ち合っている
EnterprizeMonitor、Enterprizebackuo
バックアップが43倍、レストアが80倍の速度に。
ClusterManager ダウンタイムの低下、管理性の向上
サポートもあるよと
ーーー
MySQLatFacebook 松信さん
- UDBという巨大なユーザテーブルのはなし
- どういう機能をなぜつくったのか
- MyRocksというストレージエンジンを使ってるがなぜ作ったのか
- 8.0で何に期待してるか について話す
Facebookは大きなMySQLヘビーユーザで現在は5.1から5.6をつかっている オラクルの5.6に対してパッチを当てて使っている パッチは公開していてオラクルさんに取り入れてもらう MySQLそのものでビジネスをしているわけではないので本家に取り入れてもらったほうがいい
次のアップグレードは8.0の予定 8.0に必要なパッチとそうでないものを評価中 今年中ということではないが検証をすすめている
UDBというメインのユーザデータベース FB上での行動自体を保存しているソーシャルグラフ
シャーディングして情報を管理している たいていの場合は大きなレコードキャッシュ（mecachedのようなもの）
遅ければ遅いほどユーザ体験が遅くなる、性能自体を意識してチューニングしている
自動バックアップや自動F/Oなど定型的な作業はすべて自動化している
ストレージフラッシュにすることでスペースを減らしてる
最初はInnoDB圧縮機能をチューニングしてたがあきらめてMyLocksに移行したという流れがある
運用と開発してつかうチームがいていろんな機能を必要として作ってきた
Btreeだと断片化してくがそのオーバヘッドを減らしたい、勝手にデフラグしてスペースを減らしたい
ALTERTABLE deflugとか機能つくって定期実行など20%くらいのスペースの削減ができたが デフラグするぶん書き込みするのでI/O負荷があるがスペースは減った
InnoDB_dowblewrite、電源おちたときにページ壊れたら修復する機能
2回書くことでメインが壊れても修復できるやつ dowblewriteだと4kbのページが16kbになってしまう。ので実際どこが壊れてる可能性があるかをわかるようにする機能をつけて 壊れたやつはすててほかのスレーブから複製するようにした
それがどのくらい信頼できるかは環境のストレージによる
ロジカルリードアヘッド、ハードディスクドライブのやつ
mysqldumpで論理バックアップをつかっている、1日以内にバックアップが取れないことが問題に。 フルテーブルスキャン、主キーがuidだとランダムになりやすい？
プライマリキー、飛び飛びでバックアップデータよんでる、ハードディスク上では遅い
それを防ぐのにロジカルリードアヘッド、フルバックアップなので物理的な順番でスキャンするのを少数のシーケンシャルリードするようにした
非同期のMySQLクライアント、非同期で投げて後で受け取るとか、 上限値を決めて最大20ユーザで
ユーザ毎のデフォルトセッションvariableごとに処理をわける
耐障害性、sync_binlogを0にしてもほかのスレーブからもってくるようになど
バイナリログを圧縮して送ることをしている、スレーブがたくさんあると何回も圧縮することになるが glibじゃなくzstdつかうとかしている
Flush tables with read lock,重いのでなくていけるようにしてるなど
いくつかは本家にバックポートされてる
BinlogServerというのがインフラの中で大きな役割をもってる
バイナリログというのは重要なものでレプリケーションはこれないと動かない
汎用的なbinlogさーばに保存してく、これがないとれぷりけーしょんつくれない
1週間とか2週間とってく、booking.comもこのへん力入れてるらしい
マスタとスレーブ、スレーブはマスタからよむけどなかったらbinlogサーバからよむ
準同期レプリケーション、コミットしたスレーブの応答を待つのに近いところにないといけない、 FBはそれぞれ５つか６つくらいのくらすたがある
が地域がばらけてる、コミットしたとき必ず数百秒かかってしまうので、ビンログサーバをマスタと同じ近所において そこに書かれたら準同期レプリケーションが成立するかんじで遅れないようになんとかしている
binlogサーバはFBの内部のAPIに依存してるのでオープンソース化が難しいがなんとかしたいと言ってるところ
レベルdbというやつをフォークしてMyRocksというストレージエンジンをつくった
読み取りコストは多少あるが書き込み負荷すくなめでスペースがすくないやつ
昨年完成させて移行した。 MySQLはプラガブルストレージエンジンなので、同じ接続方法でつかえてクライアント変えるコストがない
UDBというメインDBをInnoDBからMyRocksつかってる 圧縮効率がInnoDBよりSpace効率がよく半分の使用ですむのでインスタンスまとめたりでサーバ台数が減る
読み取りのコストが データ移行高速化するために いろんなチューニングオプションをオンラインで
MyRocksへの移行で難しかった部分
どっちのデータも正しいかとか 処理がささったりなどのモニタリングしてく
MyRocksはネクストキーロックギャップロックつかえない、ステートメントベースが使えない (binlogフォーマットが)Rowベースでないと、でも前からそうしていた
スレーブいっことめて複製してSQLデータで複製してく
RocksDBライトオプティマイズで書き込み最適化、早いがデータコミットするとRedoログ、めｍテーブルがいっぱいになると
コンパクションで最適化されたデータファイルがつくられてく
6段階くらいを経てデータファイルがつくられてく
1倍とだとしても何回もかくので何倍かになる（InnoDBよりはすくない）
InnoDBからダンプするときorderbyprimaryとかあるがそれと同様に主キーソートするようにして時間削減した
重要なデータが抜けてないかデータが正しいか RocksDBは新しいのでチェックがいる
件数が違ったらとかGTIDつかうことで同時に同じGTIDをセレクトして同じかチェックするなど MyRocksバックアップというやつをつくって複製した
マスタにするのはCHANGE MASTERにするだけだがクラッシュしないように auditプラグインで別のとこに投げてデータが壊れないことを検証するなどしてた
発展途上でInnoDBほど完成されてない DBA観点から、ダイレクトI/Oが貧弱でbufferdI/Oがリナックスでは十分でなく カーネルがメモリを割り当てるときにストールすることがあるのでその辺を新しいカーネルで修正したり
誰と誰がという関係性、アソシエーション、タイプごとにカラムファミリーがある
レベルごとに圧縮アルゴリズムを指定できる 読み込みを高速化するなどもレベルごとに処理をかえてる
bufferd-I/OよりODirectがやっぱりいいな、とそちらにむかってる
たくさんのファイルを削除するとそこがささってしまうのでそれを高速にやらないようにしている バイナリログトランザクションログとパーティションわけてる
コアファイルをつくるようにしてたRSSでなくバイナリファイルで、リナックスが何をするか エクステンド、コアファイル生成しないようにした
スパースファイルで圧縮してとかの調査してた 最近はpstacでログにはくようにしようということにしてる
他のデータベースもMyRocksつかっていきたい
FBメッセンジャーはHbaseにしてたが去年MyRocksにおきかえてた LSM、Hbaseのが書き込みが早い 進化についてこれなくなったHbase、なんかMySQLに戻った
フラッシュストレージでうまく動かないというのが最大の理由、 CPU使いすぎるのでデータをのっけられない、Javaのガベージコレクションが生じたときの刺さるやつが目立つようになった
Hbaseをフラッシュストレージに対応させるには原型をとどめない改造が必要だったのでMyRocksにかえることに。 根本的なアーキテクチャの違い、性能効率が大きく上がった
データの一貫性はアイリスというシステムで頑張ってた 2か所に書き込んでチェックなど
ーーー
8.0への期待（FBの） 我々のパッチを移行しつつ取り入れてもらえるように
パフォーマンススキーマがよくなったらしいので既存パッチを捨てられる
オプティマイザの統計情報がよくなってるとこ グループレプリケーションもソリューションとしてスタンダードになってくだろうと
現在足りない機能がある、IPV6のサポート、パクソスのマルチプライマリという1レコードコミットで3往復くらいするのがちょっと冗長。 シングルプライマリで効率よく動くほうがよくコミットが1往復がいい
ライブマスタプロモーション（手動でマスタを別マシンにうつしたい）が、できないとこがまずい （たしかにMHAだとそれできますね） このへんの課題は認識されてるのでそう遠くないうちにサポートされるはず
ーーー
8.0へのアップグレードポイントとパラメータ比較
やまざきさん
こうパラメータかわったのでここ気を付けてねと
いったん5.7最新に上げてから上げたほうがいい
マイナーバージョンでパラメータ追加されたりする
バージョン間の仕様変更に関するやつ
非推奨になった機能なども資料ダウンロードできるので追ってご確認ください
バージョンアップによって互換性が失われる変更などがある
まとめてチェックできるユーティリティがありMySQLシェルのアップグレードチェッカーというもの 修正箇所を一覧でだしてくれるもの
開発ブログでもアップグレードチェッカーつくったよというのがある
システム変数のパラメータ名が変わったやつがある バージョンリファレンスでわかるようになってる一覧がある 差異をかくにんする マニュアルから各パラメータの詳細を確認するとどのバージョンからどう変わったとかかいてある
Setvarヒントについて、オプティマイザヒントというのが少し前に導入されてる SQL文のなかにコメントとしてヒントを埋め込むというのができるように、それの種類が8.0から増えてる このセレクト投げるときにソート用のメモリ領域を一時的に大きくするというのができる それができるかどうかSetverヒントで説明されてる。セッション単位で変更できるものがすべてがヒント書けるわけでもない
5.5～7までのパラメータ比較したエクセルファイルも公開中
参考情報で富田さんのパラメータ比較ツールもあるよと オラクルオフィシャルではないですがと紹介
utf8mb4になったよ、デフォルト照合順序も変わってる ソートしたときのデータの並びの順番が変わると思うので注意してください
バイナリログはデフォルトで出力されるようになった log_slave_updatesもデフォルトで有効になってる
バイナリログも自動削除になった expire_logs_daysが非推奨でそのうち廃止されるので注意 bin_log_expire_log_secondesのデフォルト値は30日相当になってる 両方設定されてるとexpire_log_daysは無視される
リレーログインフォリポジトリとかデフォルトでテーブルになったので注意 マスタインフォリポジトリも。クラッシュセーフスレーブというやつで5.6からあるパラメータ。 合わせてrelay_log_recoveryはtrueにしないとデフォはfalseでクラッシュセーフにならないので注意
認証方式がcaching_sha2_passwrdこれクライアントが対応してないと認証エラーになるので注意
ネイティブパスワードを対応してないクライアントにはつかう
タイムスタンプ型の挙動変更 行更新されたときに自動的にTimestamp型の列に更新日付が入る動作が無効化されてる
SQLモードの変更、SQLの挙動のデフォルト値、NoAutoCreateUser自体が廃止されているので注意 ユーザが存在しない状態でGrant文で権限を与えることができなくなる、つまりGrant文でユーザ作成ができない ダンプファイル入れるときにSQLモード指定してるとエラーになる
Undoログファイル、ibdataとは別管理になるのでundo_001とかが増えてる 自動的にサイズが縮小されるのがデフォルトで有効 128回undoログのパージが呼び出されると縮小する
Xプラグインの有効か、ドキュメントデータベース用のやつ REDOログUNDOログ暗号化追加できるデフォルト値falseで暗号化されない クエリキャッシュは8.0で廃止されてる 関連パラメータは削除されるので今後つかわないように、廃止理由などは開発ブログにあるよ
入門セミナを8.0に対応させて7/23にやります初歩的なインストールとアーキテクチャの解説など
ーーー
そのたのイベント
梶山さんから
7/23のほか 申し込みサイトにそのうち出ますと
8/1水曜、ヨーロッパでのｇｔｐｒに代表されるセキュリティレギュレーション 8.0セキュリティ新機能
9/14金曜日 ベンチマークにまつわるいろいろ、そのものの性能のはなし InnoDBの開発者の人来日する
セールスコンサルタント、プリセールス人員募集中ですとのこと
ーーー
QA
Q 松信さんにMySQLのマイナーアップデート、8.0どんなことをかんがえてるか
A オラクルが3か月に一回新機能リリース、 バージョン上げるときにレギュレーションチェックして、カバレッジあげて自動的にテストいかにやるか、 そこは力入れてるところ、シャドウシステムというのがありauditプラグインで投げたやつを性能の悪化など検知できるようにしている カバレッジを上げることでバージョン上げる恐怖感をへらしてる
Q UDBというメインDBについてお話いただいて、組織おおきいしその他いろいろあると思うが、役割分担とか管理上の違いは？
A MySQLチームというのがある、アメリカとロンドンで20人くらいあって 機能別でオートメーションとかフェイルオーバーとかバックアップとかごとにわかれてる DBごとにわかれてはない サービスとかでなく自由につかえるとこのほうが問題がおきやすい UDBとメッセンジャが1番目と2番目に大きくてトップ２をかいたというところ
Q G4dでパフォーマンス上きになるところ、メモリのチャネルすくないとか問題なったりしないのか
A ハードウェアチームがいて評価するひともいるしローレベルのエキスパートがいて検証したりする メモリが高いのでメモリを減らす、それを減らすには圧縮、CPU負荷が上がるが顕在化はしてない →FPGAで検証する？ →それはビデオとか、デコンプレッションのとこはそんなに50%とかつかってるわけでないのでコストが見合わないかもというはなし gCCでビルドしてたがcLANとかのコンパイラをつかうことでcpu負荷へったりした トリム、lOCKSDBのコンパクション、負荷がたかいときとかぶらないようにしようという 運用としてはファイルをゆっくり消す、60MBずつ消すという設定を追加してそういうふうにしてる
ーーー
誤字あったらマサカリ投げていただいて構いません。 7/23は夜にMyNAあるようです。 MyNA(日本MySQLユーザ会)会 2018年7月 : ATND
では、見ていただきありがとうございました！
