#mysqlcasual vol.9にいってきた

こんにちは。smallpalaceです。

久々に勉強会にいってきたので備忘録を。

のっけからミッドタウンとヒルズを間違いましたが始まる前になんとかたどり着けました。よかった。

MySQL Casual Talks vol.9 - connpass

MySQL Casual Talks vol.9 - Togetterまとめ

 以下メモしてますが誤字あったらすみません。

------------

＠RKajiyamaさん

SoftwareDesignのはなし。

PostgreSQLとの比較でタイトルが地雷臭。いきなり誤植

・高速、軽量、バカ（@yoku0825

それ以外はすごいのでお勧めだそうです。

書いた人は@soudaiさん

表紙があざらしなのが納得いかないそうですｗ

昨年10月5.7がGAに。

5.7.11　TDE（透過的暗号化）

GAとはなんだったのか

データの暗号化だけでRedoログの暗号化はちょっとまってくださいと。

20160112：@morgo　という方がコミュニティ担当からプロダクトマネージメント担当に。InnoDBをメインで担当するらしい。主な役目は5.8だそう。

MｙSQL Server Blog（mysql.serverteam.comというブログに5.8のプランをかいてる記事が。

Replication関係のブログMySQL High Availability.com

パスワード変更期限が無期限になった

utf8mb4、ntf8mb4_unicode_520_ci、ご意見募集中だそうです。slackでもユーザ会でもtwitterでタグ付きでつぶやくのでもなんでもよいそうで。

MyNA,JPUG中国地方DB勉強会in東京、登録ぱつんぱつんだそうです。

会場はここ（ミッドタウンのyahoo）

https://dbstudychugoku.doorkeeper.jp/events/37635

-------------

Yahooの井上さん

MySQL監査システムを作ったはなし

@i_swing_by

好きな言語C++

競技プログラミングとAI作成が趣味だそうです。

・監査とは

　・クエリ、ip、ユーザなどを出力

・アクセス情報の解析

　・アクセスルートやコマンドの登録

・なぜ監査が必要なのか

　・不正アクセスの検知

　・アクセスルートを調べて再発防止

・DB管理者を守る

　・監査システムを別のチームが管理することで疑われることを回避

・問題ないアクセスの決め方

　・ホワイトリストを事前に登録

・監査システムの機能

　・ログイン・クエリ監視　

　・ポリシー設定（ホワイトリスト方式、インスタンス・スキーマ・アクセス元IP・有効期限・ユーザ

　・ポリシーとログつきあわせ

　　バッチを二種、ホワイトリスト作成とログイン連続失敗回数のカウントつきあわせにはmemcache、ログはfluentdを利用

　　・インシデント内容から原因を回答、管理者が問題ないと判断してからクローズされる

　　・ポリシーの登録漏れ、サーバ１つ登録しわすれ、すべてのクエリが登録されるのでテストモードにしてメールが飛ばないようにしている、リリース前にテストモードで運用するなど

・システム構成のせつめい

　・監視対象DBではMcAfeeのAuditPluginを使用して監査ログの出力をしている

　　　・ログはJson、5.1以上、

・監査コマンドの種類が多い、show status like Com_%の％の部分

　コマンドの分類、頻繁に使われるものと一時的にわけて頻繁なものは個別に登録し、一時的なものはグルーピングして登録するしくみ。

　アプリから頻繁に使われるものはグルーピングすると監査が甘くなる

　メンテナンス時などにつかうALTERなどは期限付きで監視対象外など

　showコマンドなどはデフォルトで監視対象外

パラメータ

　ログの取得方法、MySQLの特定の関数をフックするaudit_offsetの取得する

stripされてないMySQLのバイナリログを用意、

・AuditPluginをつかったときのパフォーマンス比較

　監査ログoffと直接出力とfluentd経由の場合それぞれ、offにするとパフォーマンスが1/5になるが、監査が必要なログは高いパフォーマンスが要らないケースが多かったと

・リリース後の改善点

　　インシデントの単位をクエリからセッションにした

　　申請を忘れた場合にすべてのクエリを一つ一つインシデント扱いになるのでまとめた

・現状の課題

　McAfeeのAuditPluginが原因で落ちてしまう

　　監視のプラグインをPerconaのに差し替えたい

　アクセスが激しいと監査が追い付かない

　　スケール検討中

　ポリシー更新時にfluentdを再起動させないといけない

　　ポリシー情報をDBに見に行くようにすると性能劣化が、増えてきたら検討したい

-------------------

yoku0825さんからいちご大福をいただいておいしかったです。

ごちそうさまでした（＾ｑ＾）

最近あんまりMySQLの勉強会にいけてなくてすみません；

-------------------

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

カジュアルに本番データを開発環境に入れる #mysqlcasual

アメーバおんどというサービスを管理されてる方

 調査用のデータベースを使って開発環境にデータをつっこむことを検討

Repとまると対応が面倒なのでdumpして入れた

小規模なのでdumpに3分くらい、5.6.19だそう。

dumpしてインポートするだけなら簡単

開発環境独自でつくったテストデータが消えてしまう。

独自のレコードはIDをプラス10億とかにしてAUTOインクリメントをずらすとか

全部ダンプしてバックアップしてからインポートしてバックアップしたレコードをレストア、

--whereというdumpのステキなオプションがあってそれを利用して10億以上のインサートデータをつくる

INFORMATION?SCHEMAからAutoInclementの値を取得

よかったのは、不具合がデプロイ前に発見しやすくなった、

機能追加や修正のイメージがしやすくなった

重いクエリに気づきやすくなった

みなさんもカジュアルに本番データを開発環境にいれるといいと思う

-----------------------

＠meijik（MySQLサポートのきむらさん）

My sql casual9lt_pub

GIS：GeographicInformationSystem地理情報システム

本体のみでMYSQLは実装されてるのがいいところだった、PostgreSQLはいれないとだめだったが、PostGISがリリースされた、ジオグラフィサポート

MySQL5.6.2でリリースされた

MySQL5.7で生まれ変わったGIS。

GISチーム専門家を雇用したそう、古いアルゴリズムと関連するソースを破棄してC++のBoostでつくりなおされたそう

GeoHash、位置情報は通常、緯度経度で表しますが、GeoHashは緯度経度の２つの座標を１つの文字列（長さ20）にまとめたものです。

文字列なのでB-treeのインデックスがはれる、

文字列の長さで精度が調整できる

PostGISとの違いなどをまとめた国府田さんの資料が↓

http://kenpg.bitbucket.org/blog/201511/29.html

MySQLはピンポイントで重要なところに注力している感

Workbench6.2からGISのビュワーがついてる

デモが

地理データはいってるテーブルをselectすると特に外部と連携しなくても地図がでてくる

PostGISは集約関数が豊富だったりなどなど

CROSS2016で、パネルディスカッションのオーナーとして参加されるそうです。

「おうちで学べるデータベースのきほん」という本を執筆されたそうです。じゃんけん争奪戦が。

おうちで学べるデータベースのきほん

 --------------------------

MySQLClusterのトラブル事例

FreeMemoryとは？

管理ノードからデータノードの空きメモリを確認できます 

DataMemory増やしてローリングリスタート

何もせずにローリングリスタートしても一時的にメモリが解放される

空きがあるのに1行インサートしようとするとDiskIsFullとかでるので80%くらいでメモリ増設を検討するとよいそうです

・突如滞留するクエリ、原因不明だったがLCP（ローカルチェックポイント）が終わったタイミングで復旧していることが判明

Redoログにあたるファイルが小さい場合にでるそう

更新が多い環境ではほぼ常時LCPが行われる、LCPの書き出しが追わる前にREDOログの領域（FragmentLogFileSize）を使い切ってしまうと、LCPが完了するまでクエリをブロックしてしまう。

アプリ的には500エラーがかえったりする。

増やしてイニシャルローリングスタートする。

・不定期にクエリが滞留、原因は1台のディスクが中途半端に壊れかけてRAIDコントローラから切り離されないせいで発生していた

その結果書き込みまちになってた、RAIDコントローラからみたHDDがFaildになって自然復旧、iostatのUtilとかから検知できそう、また単純にログを監視してもよさそう

そのた、7.2からTimeBetweenEpochsTimeoutがデフォルト0になりGCPstopがおきないようになっている

今回のケースだと7.1のころの4000とかにしておけば早く復旧してたかも

・まとめ、前回の発表から思ったより安定していると思います

パラメータは普段のMySQLの知識はほぼ役にたちません。

------------------------------------

＠yoku0825さん

紹介 of Anemometer

box/Anemometer: Box SQL Slow Query Monitor

紹介ofAnemometer

pt-query-digestの可視化ツール

Time-rangeとしてクエリーをまとめてしまう問題

anemo eaterというのを作ってみたそうです。

すると分単位にわけれてくれるそう。

丸めたやつとかサンプルクエリとか過去90日でこんだけでてるとかわかる

kibanaとか面倒なことはしたくなかった

スローログをfluentdに食わしてるがそれとは別にグラフで見たいと

保存期間を考えずに残っているかぎりの情報を最初から最後までみられると

githubからcloneして食わすだけ

食わせるだけでURLにアクセスすると画面がでてくる

だれか手伝ってくださいとのこと

一分単位で分割しているので結構かかるそう

ほかによい可視化の方法あったら教えてくださいと。

----------------------

MySQLとUnicode

@kamipoさん

MySQLとUnicode

Railsのコミットがんばってるそう。

Planning the defaults for MySQL 5.8

デフォルトコレイション変えようとおもってんだよねと戦慄。

unicode に詳しくなった2015年。ハハパパ問題と寿司ビール問題

ハハパパ、unicode_ciはダメなので日本人が使ったらだめ

寿司とビールの絵文字が一緒になる、

文字列を比較するときに、並び順をウェイトで定義している

3バイトの文字まではうまくやってるけど4バイトになった瞬間に補助文字になった瞬間に同じになってしまう

本当は仕様が定義されている、フルスペックで定義すれば大丈夫だけどMySQLは1段階めしか持ってないので同じになってしまう

utf8mb4_japanise_ciがないと、我々日本人は死亡。ルビーがスクエアルピー（絵文字）になるそうです（utf8mb4_unicode_520_ci）

〇×表が資料に。

MySQL Bugs: #79977: utf8mb4_unicode_520_ci don't make sense for Japanese FTS

---------------------------

yahooの立岩さん

MySQL利用システムの運用小話

前職は開発だそう。

その１、容量オーバー

デフォルト4Gのファイルサイズオーバー

容量監視してなかった、どこかのタイミングで見直しが必要でした

その２、定期Optimize

フラグメンテーションで時間がかかっていたがデュアルマスタで切り替えられるように改修

その３、サーバーダウン

ローンチ後５～６年で

原因はサーバ老朽化

把握はしていたがリプレイスに手が回っていなかった

夜中におこされて日中は復旧・リプレイスに追われる毎日、マスタがいつダウンするかおびえる毎日。。

監視・運用計画がだいじです。

ｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ

myfinderさんから、こういう話や人の話がききたいなどあれば#mysqlcasualつけてつぶやいてくださいとのことです。

 Join mysql-casual on Slack!

本日もおもしろかったです。

ありがとうございました！

 

では見ていただいてありがとうございました。

またそのうちに。