b.l0g.jp     About     Archive     Feed

MySQL Casual Talks vol.5 メモ

 

MySQL Casual Talks vol. 5に行ってきたので、自分なりのメモと資料へのリンク。

途中、アラートが鳴り始めて確認してたりしてメモが適当なところがあるが仕方なしw

かなりのスピードでじゃんじゃんプレゼンが進んで行ったが、どれも面白い・役立つ内容ばかりで、楽しいひと時でした。発表者の皆様、会場の提供や調整などしてくださった@myfinderさんはじめとする皆様、ありがとうございました。自分の隣でビール缶を次々と「カシュッ」と空けていた@oranieさんのような余裕を持ちつつ、次回は自分も何かネタを提供できるといいなあ。

@yuryuさん GTIDを使い始めてやめた話

MySQL5.6でGTIDを試してそっと閉じた from Haruka Iwao
  • GTID - 全てのトランザクションを一意に識別、一貫性保証
  • マスタを切り替えると、マスタのUUIDが変わるのでGTIDが2個になる
  • 利点
    • change master to … master_auto_position=1で簡単にレプリをはれる
    • mysql workbenchのmysqlfailoverとか使える
  • 欠点
    • クラスタ全部GTID有効にする必要
    • MyISAM使用不可
    • HAしたいならMHAでいいんじゃね?
  • バグ
    • GTID有効でFLUSH LOGSするとレプリ停止(5.6.11のみ)
    • stop/start slaveするとトランザクションがスキップされる可能性あり
    • ネットワーク切断でトランザクションスキップの可能性
  • 結局、本格的に使うには時期尚早なので辞めました、ということ

@con_mameさん MySQL 5.6移行記

僕らのMySQL5.6移行記(仮) from Yutaka Hoshino
  • クックパッでは5.5のサーバを5.6にバージョンアップしたり最初から使ったり
  • レプリしてクエリ流してコンフィグいじり始めた
    • うまく行ったのは最初だけで問題勃発
  • EBSでスナップショット取ったボリュームを5.6マシンにぶら下げてmysql_upgrade実行
  • Kage
    • リクエストをコピーしてsandbox環境に流す仕組み(ユーザへはproductionからの結果が返る)
    • レスポンスのdiffも取れる
    • バックエンドを5.6にして違いを確認
  • バージョン違い、設定違いのサーバを並べて比較
  • 開発用DBを先に新しくしてリリース前に新環境を試す
  • バグ確認用(最新) → 検証用(1つ前) → 本番用(安定版)
  • 各バージョンが入ったAMIを用意しておいてすぐ起動できるようにしてある
  • GTID有効だとsql_slave_skip_counter使えない
  • AWSだと色んな検証がCasualにできる
  • bugsは見ましょう!
  • 5.6で遅くなるところもあるので、得意な部分から本番投入していっている

@yoshi_kenさん 5.0 Tritonnから5.6 mroongaへの移行

Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記 from Kentaro Yoshida
  • 技評の記事の裏話
  • 旧構成 マスタはDRBDでミラー、スレーブにレプリ
  • 5.6スレーブを追加してそこに孫をぶら下げて旧環境を切り離し
  • 本番環境のアクセスログから抜き出したURLを使ってテスト
    • 5.6で遅くなったクエリをチューニング
    • SQLMODE厳格化への対応
  • テスト中に見つけたmroongaのバグはすぐに修正してもらえた
  • HWトラブル
    • マスタ死亡、起動しない、焦げ臭い!さらにもう一台も焦げた。。
  • GTIDよりsemi sync repl + MHAがいいのでわ
  • innodb_file_per_tableでなかったのでダンプしてバージョンアップした
  • memcached APIはバグで使えなかった

@yoku0825さん アプリ担当が出してきたDDLがドイヒーな話

とあるイルカのバーボンハウス from yoku0825
  • すごい心が痛い&共感出来る内容だったけどテンポ早すぎてメモできなかったw
  • MariaDB 10からもGTIDが使えるようになった(ただしMySQLとは結構違う)
  • ログ用テーブル
    • 突っ込みどころたくさんww
  • インデックス名はidx_カラム名_カラム名_…とすると長いけどexplainのときに分かりやすい
  • フレームワークが作る通りではなくDBの特性を考える
  • SQL文を見るだけでどのインデックスを使うかなどの意図が分かる名前付け

@kamipoさん mysql-build

プレゼン資料

  • この辺りトラブル発生してメモがおろそか
  • いろんなMySQLをインストールして使い分ける仕組み
  • percona serverのmysqldumpにはkeyを消してダンプして作り直すオプションがある
    • ダンプが高速化
  • fbの5.6にはlogical key readのオプションがある

@do_akiさん multi master replication

殿堂入りのアレ~Multi-Source Replication を添えて~ from do_aki
  • MySQL Casual定番の内容
  • change masterを2秒ごとに切り替えてマルチマスタ
  • 5.7では標準でできるようになった
  • 過去に色々な方法でマルチマスタを試みている人がいるww

@RKajiyamaさん 5.7 Multi-source replication

MySQL Casual Talks vol.5 - MySQL Labs - @RKajiyama from rkajiyama
  • labsにはDMR以前のものがありますよ
    • hadoop applier for mysql
      • hadoopをMySQLスレーブのように使う
    • JSON UDF
    • Multi source replication
    • MySQL Utilities Fabric
      • シャーディングの情報を管理する仕組み
    • Fabric + multi source replication + multi thread slaveの組み合わせ良さげ

@songmuさん

プレゼン資料

  • GitDDL::Migrator, SQLTranslator(SQLFairy)
    • ブランチごとにテーブルやカラムが違うと大変
    • テーブル構成の違いなどが表示できる
    • ブランチを行ったり来たりしながらalterしたりできる
  • App::RunCron
    • perlのラッパー、レポータを書くと色々できる
    • cronのログってnullに捨てちゃうけど困るよね
    • cronlog
    • cronの処理をラップしてエラー処理が可能

@nekogeruge_987さん DB2からMySQL5.5への移行

  • 13年運用されてるデータベース
  • レコードをCSVにしてload infile
  • シェルスクリプトで自動化
  • 4時間以内に終わらせるという時間制約
    • loadを高速化する工夫
    • ジョブフローの最適化(jenkins build flow plugin)
    • ジョブフローをGroovyで書ける(並列実行などなども可)
    • データ移行自体をCIする(1クリックデータ移行!)
    • /var/lib/mysql以下の並列rsync

@monryさん Amazon RDS

20131025 my sql casual talks vol.5 from Tetsuya Mori
  • マスタ1台、スレーブ5台
    • 243ドル/月
  • 物理サーバが1台13万以上ならRDSの方が安い(3年償却)

@chobi_eさん ストレージエンジンを作ってみた

MyNA会2013年9月 メモ

 

MyNA(日本MySQLユーザ会)会 2013年9月

先週のMySQL Cluster Casual Talksに続いて、週末にかけて行われたMySQL Connectで発表された最新情報を聞けるということで、MyNA会に参加してきた。基調講演の内容は既に報道されていたので(Publickey (1), (2), (3))ある程度分かっていたが、一番うれしかったのはMySQL Fabricのデモが見られたこと。MySQL Utilitiesの機能でシャーディングができるようになるということでどんな感じか見てみたかったので、(ラボ版で一部動かないところがまだあるということだったが)興味深かった。発表者のみなさま、会場を提供していただいたOracleのみなさまなど関係者の方々ありがとうございました。

@RKajiyamaさん MySQL Connect基調講演の概要

  • いつOracleはMySQLを殺すのかと言われてきた → うわさを打ち消すために3年半の間大量のリリースをしてきた
  • チーム全体も増員、特に品質管理チーム
  • DMR(Development Milestone Release)というやり方
    • リリース候補版になったコンポーネントを含んだリリース
    • 18から24ヶ月ごとにメジャーリリースしたい
  • Webや組み込み系に強いDBとしてOracleにとっても価値がある
    • 現在もLinux系の最も重要なスキル=MySQL
    • 今もユーザは多数
  • 5.7.2 DMRの発表
    • Release noteが超長かった=たくさんの更新が含まれている
    • InnoDBパフォーマンス向上
    • explain for connectionで別セッションのexplain
    • Optimzerの結果をWorkbenchでさらに詳しく
    • performance schema改善
      • メモリの使用状況
      • storedの詳細
    • tmpテーブルがInnoに
    • 同じDB内でのマルチスレッドレプリケーション
  • 5.7の以後のバージョンでの予定
    • マルチソースレプリケーション
  • MySQL Utilities 1.3
    • レプリケーションのフェイルオーバをデーモンで
  • MySQL Utilities 1.4から
    • Fabric
      • アプリから意識せずにシャーディングできる
      • Connectorが接続を受けて振り分ける
      • レンジかハッシュ、リシャーディング

いちいさん@Gree, いけださん@SCSK MySQL Connectの感想

  • Oracle OpenWorld、JavaOneと一緒にやってる
  • SFのホテルいくつも貸し切り、道路も閉鎖して休憩スペースに
  • FacebookのMySQLの話
  • まつのぶさん MySQL 5.6@Facebook
    • 5.1にパッチ当てたのを使っている
      • 圧縮、クラッシュセーフスレーブ、フラッシングの高速化など
    • シャドウサーバ
    • 5.5を飛ばして5.6へ
      • 低リスクのところから徐々に移行
  • GoogleがMySQLをやめてMariaDBに全面移行するというのは、XLDBというカンファレンスでの話を元にした記者の煽り記事で、Googleの人曰く迷惑しているそうだ

@yyamasaki1さん JSON UDFs

ドキュメントデータベースとして MySQLを使う!? ~MySQL JSON UDF~ from yoyamasaki
  • MySQL json UDFs
  • カラムにJSONをつっこんだものをファンクションで処理できる

@RKajiyamaさん MySQL Fabric

  • ラボ版のMySQL Utilitiesに搭載された新機能
  • マスタにスレーブがぶら下がってる構成
    • これを1つのシャード(グループ)として扱う
  • アプリからConnectorを使ってアクセスする
    • ConnectorはFabricに問い合わせ先を確認してからシャードにアクセス
    • state storeに情報保存
    • スキーマの情報などだけもってデータは持たない
  • グローバルグループ
    • 全体に影響のある処理に関係するメタ情報を持つ
  • アクセス時にRWかROを指定すると、Fabricが自動でマスタあるいはスレーブにアクセスを振る
  • lab版は罠だらけなので気をつけよう。。
  • 開発者の方のブログが役に立つ

赤井さん GNU 30周年とMySQL

  • GNUプロジェクトが始まって30年
  • MySQLの成長はGNUの恩恵を受けた
  • GNUへのリスペクトを忘れないようにしよう

 

MySQL Cluster Casual Talksメモ

MySQL Cluster Casual Talks

一応仕事でMySQLをよく触っている身として、軽く検証はしてみたものの、担当している業務では参照メインのDBが多いこともあって実運用では使ったことがなかったMySQL Cluster。改めて利点も欠点も聞いておきたいと思ったのと、会社からすぐ近くのGMOさんが会場ということもあって参加してみた。

MySQL Clusterの本も書かれている@nippondanjiこと奥野さんから、MySQL Clusterは何に向いていて、どう使えばよさを引き出せるのかを聞いたうえで、そのサポートを受けながら4年間運用されている@tsakuradaさんの実運用上のハマりどころを聞くことで、どういうところにMySQL Clusterを使えばいいのかイメージが浮かんだので、非常に今後の役に立ちそう。

発表者のみなさま、会場提供していただいたGMOのみなさまありがとうございましたm(__)m さくらのクラウド2万円分クーポンももらったし、GMOクラウドのキャラクタのシールもたくさんもらったので宣伝しますw

既にまとめはgarage-kidさんが書いてくれているので、これは個人的なポイントのまとめ。

@RKajiyamaさん MySQL Cluster大地に立つ!「5.6とは違うのだよ、5.6とは!」

  • MySQL Clusterの概要
    • 分散型、共有ディスク不要のHAクラスタ
  • 使用しているユーザ
    • 元々はモバイル通信の位置情報をリアルタイムかつ高可用性を持って保存するためにできた
    • SQLインタフェースは昨今ゲーム業界などで使われ始めてから追加されてきた機能
    • 艦○れでも使われている?

@nippondanjiさん カジュアルにMySQL Clusterを使ってみよう

カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09 from Mikiya Okuno

データノード、SQLノード、管理ノードの3種類からなる

  • 1台だけならndb(MySQL Clusterのエンジン)よりInnoDBの方が速い
  • ただしNDB APIを使うならClusterの方が圧倒的に速い
  • ノードを増やすとスケールしていく点に優位性があるが、いつでも速くなるとは限らない(後述)
  • 新しいバージョン使いましょう

シェアードナッシング型

  • データノードは2台ペアでノードグループを構成
  • データをフラグメントに分けて、それをノードグループ内で同期レプリする
  • RAID10的な感じでグループ内で1台落ちてもデータは保全される

InnoDBとは特性が違う & いつでもノードを増やせばスケールするとは限らない

  • 主キーを使った検索 → データノード数に応じてスケール
  • (少数の行を取ってくる)スキャンは苦手
    • データがノードに分散しているので複数ノードをスキャンする必要があるため
    • フェッチするレコードが多いと並列処理できるので早くなる
    • Engine Condition Pushdown : where句部分を丸ごとデータノードに渡して並列処理して高速化する仕組み
    • sysbenchをただ走らせると遅いのはこのせい
  • ユーザ定義パーティション
    • スキャンを高速化させる仕組み
    • 2つのテーブルの関連を考慮してデータノードへの分散を定義すれば、読み書きを特定のノードに抑えられるので高速に
  • レプリケーション
    • ndbに不得意な処理があるならInnoDBのスレーブを作るという手もある
    • データノードが書き込みしたことをSQLノードに通知し、それをbinlogに書き込んでスレーブに送るという仕組み
    • 通知を受け取るのがbinlog injector thread
  • インメモリDBだけど永続化処理が多いのでディスク書き込み多い=速いディスクがいい
  • blobを別テーブルに保存するのでJOIN的処理が発生して遅くなる
    • varcharで頑張ろう
  • NoSQLインタフェースを使えば爆速
    • 各種言語のインタフェースあり
    • InnoDBのmemcachedインタフェースよりMySQL Clusterの方が現時点では賢い

まとめ(MySQL Clusterの使いどころ)

  • 大量の更新をさばきたい
  • HA機能が欲しい
  • 高速JOINしたい

@tsakuradaさん MySQL Clusterと丸4年の付き合いを振り返ってのよもやま話と、Version 7.3への期待(もっとユーザが増えるといいな~)

MCCT20130926 tsakuradac from Takeshi Sakurada

使用開始時の期待と使ってみたギャップ、現在の期待

  • インメモリだから速いはず
    • 参照に関していえばFIO+InnoDBでも変わらないかも
  • スケールアウト簡単
    • 構成によってはスケールしないこともあるので要考慮
  • 高可用性
    • 期待通り、フェイルオーバーは数秒で完了
  • ライセンスがGPLでオープンソース
  • 7.3でInnoとの互換性が上がって期待

サーバの構成

  • SQLノードと管理ノードは同居してもよい、データノード2台と合わせて最低4台からが現実的
  • データが多いならデータノードを増やす(が制約はあるので注意)
  • アクセスが多いならSQLノードを増やす。制約は少ないので割と簡単
  • せっかくのMySQL ClusterなんだからHW構成上もSPOFを減らそう
  • クエリがキャンセルされた時それを検出して後続処理をやるアプリ作り込み必須
    • ノード障害時にクエリがキャンセルされるため

InnoDBとの組み合わせ

  • Innoと同じ感覚でテーブル設計してもよいか?
    • 場合による。最近のバージョンではやってみる価値あり
  • InnoDBスレーブとの組み合わせ
    • 分離レベルが違う点は要注意だがおおむね問題なし

ハマりどころ(資料が詳しいのでそちら参照)

  • GCP Stop
  • ローリングリスタート
  • ボトルネックが見えづらい
  • データのライフサイクルを考えよう
  • リストアが大変

4年間でだいぶ地雷を踏んだのでもう大丈夫w 皆さんMySQL Cluster使いましょう

@yyamasaki1さん MySQL Cluster Auto-Installerのデモ

5分で作るMySQL Cluster環境 from yoyamasaki

Auto-Installer簡単なので使いましょう

  • ブラウザベースでぽちぽちやればインストール可能
  • 初期パラメータをいくつかいじった方がいい

@yoku0825さん ウチがNDBCLUSTERを使わない理由をもう一度考える

MySQL Clusterというと紛らわしいので、NDB Clusterと言いましょう<table border=0>

</table>