意外と知らないかもしれないMySQL_エンジニア勉強会20130213

5,064 views

Published on

2月13日に開催されたエスキュービズム社内勉強会資料です。

意外と知らないかもしれないMySQL_エンジニア勉強会20130213

  1. 1. 意外と知らないかもしれない... MySQL
  2. 2. メジャーバージョンの系譜 レプリケーション  古いバージョンのMasterから新しいバージョンのSlaveへはできない  メジャーバージョンの差は1つまで 4.0 サポート終了 4.1 サポート終了 5.0 サポート終了 5.1 RHEL/Cent OSでyumで入る 5.5 RHEL/Cent OSでremiレポジトリを使うとyumで入る 5.6 2013年2月5日リリース
  3. 3. Maria DBへの流れ Oracleの「10の約束」の期限は2014年12月。 OracleへのMySQLプロジェクトを閉鎖的にしているとの批判 Fedora19ではMaria DBが標準に。 そこから派生するであろうRHEL/Cent OS7でも? 4.0 サポート終了 4.1 サポート終了 5.0 サポート終了 5.1 RHEL/Cent OSでyumで入る 5.5 RHEL/Cent OSでremiレポジトリを使う とyumで入る 5.6 2013年2月5日リリース MySQL AB Sun Microsystems Oracle
  4. 4. MySQLのインストール yum install mysql-server chkconfig mysqld on service mysqld start /usr/bin/mysql_secure_installation 使ってますよね? test データベース削除 rootパスワード設定 匿名ユーザ削除 remote hostからのrootログイン禁止
  5. 5. my.cnf デフォルトのmy.cnf ・長年メンテされてない  MySQL5.5では動かないパラメータがある  想定するハードウェアスペックが低すぎる ・オプションが少ない ・想定外のケースで使ってしまうケースがある  my-innodb-heavy-4G.cnfは「複雑で思いクエリを処理するが想定する接続数は少ない」という意味 /usr/share/mysql/ 以下にあるサンプル my-small.cnf my-medium.cnf my-large.cnf 開発環境以外でそのまま使ってはいけない 実運用には適していない
  6. 6. ログ ・エラーログ ・一般クエリログ ・スローログ ・バイナリログ エラーログ以外はデフォルトでは出力されないことに注意 バイナリログが出力されていない場合、 後述のロールフォワードリカバリができない バイナリログ未出力は業務使用では絶対にNG 以下4つのパラメータは必ず確認が必要 log-bin=mysql-bin expire_logs_days=7 max_binlog-size=1G sync-binlog={0¦1}
  7. 7. スローログの解析 Percona Toolkit(旧Maatkit) MySQLの便利ツール Appエンジニアで使っている人をあまり見ないが、 O ReillyのMySQL本や鍵本などMySQL関連本には必ず載っている。 #yumもしくはcpan/cpanmで以下のモジュールをインストール yum install perl-Time-HiRes yum install perl-IO-Socket-SSL wget http://www.percona.com/redir/downloads/percona-toolkit/LATEST/percona- toolkit-2.1.8-1.noarch.rpm rpm -ivh percona-toolkit-2.1.8-1.noarch.rpm pt-query-digest /path/to/slowlog.log pt-query-digest --explain h=hostname,u=username,p=password --type tcpdump /tmp/ mysql.tcpdump > /tmp/pqd.out スローログを簡単にサマれる(cronで結果をメールで飛ばしておいてDailyで結果確認等) tcpdumpの結果を直接食べられる バックアップやオンラインスキーマ変更等の操作系コマンドは個人的には使ってない
  8. 8. バックアップとリカバリ オンラインバックアップ(無停止) コールドバックアップ(要停止) mysqldump MySQL Enterprise Backup LVM等のスナップショット /var/lib/mysql/以下を丸ごとバックアップ →使いどころとしては同じ環境を別サーバに立ち上げたい場合等にこちらの方が速い場合がある オンラインバックアップによるフルバックアップからのロールバックリカバリ              + バイナリログを使ったロールフォワードリカバリ 基本
  9. 9. リカバリ mysqldumpによるフルバックアップ 障害発生 dumpファイルからのロールバックリカバリ 欠損 バイナリログを使ったロールフォワードリカバリ フルバックアップだけではバックアップ取得時点∼障害発生時点までのデータが欠損 バイナリログだけでは起点となるデータがないためロールフォワードできない したがって、どちらかが欠けてもNG
  10. 10. メモリチューニング ・クエリチューニング ・インデックスチューニング ・メモリチューニング(上2つの方が優先度高い) MySQLの動作プロセスを理解しておく MySQLの動作はシングルプロセスマルチスレッド(マスター側) 接続毎にスレッドを1つ立てる mysqldサーバプロセス 接続スレッド 接続スレッド 接続スレッド グローバルバッファ スレッドバッファ スレッドバッファ スレッドバッファ MySQLが使用する最大メモリ= グローバルバッファ+max_connections スレッドバッファの合計値
  11. 11. メモリチューニングの方向性 ※DB専用サーバ&innodbの場合 innodb_buffer_poolsizeに全体の5∼7割を割り当ててやる [@development ~]# mysqladmin -uroot -p extended-status | egrep '(Max|Threads_)' Enter password: | Max_used_connections | 24 |  ←これまでに記録された最大同時接続数 | Threads_cached | 0 | | Threads_connected | 1 |  ←現在開いている接続数 | Threads_created | 1905 |  ←接続を処理するために生成された接続数 | Threads_running | 1 |  ←スリープ状態になっていない接続数 調整 サーバ搭載メモリを超えた場合→swap発生 サーバ搭載メモリより少ない場合→サーバリソースを有効活用できない 32bit OSの場合、MySQLが使用できるメモリは2∼3GB前後になるという制限がある ↓ めんどいのでmymemcheck.plでチェック アプリ側でコネクションプーリング有効にするとmax_connections減る  →三城で行ったパフォーマンステストではコネクションプーリングは参照系、更新系共に有効との結果が出ている
  12. 12. クエリキャッシュ SQL文が以前に実行したものと同じ場合は 事前にキャッシュしておいた検索結果をそのまま返す  →SQL文のハッシュ値で比較するので一字一句違ってもダメ mysql > SHOW GLOBAL STATUS LIKE 'Qcache%' クエリキャッシュヒット率 = Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached) クエリキャッシュヒット率が低い場合、 クエリキャッシュオフにした方がいい場合もある キャッシュに依存している構成の場合、いきなりmysqld再起動したりすると刺さる場合がある。 Slave複数台を負荷分散している場合、新参者のSlaveは比率下げてぶら下げるとか。
  13. 13. MySQL5.5、5.6の新機能 5.5 5.6 ・準同期レプリケーション ・FLUSH LOGSでFLUSHするログを個別指定可能 ・各種パラメータの指定方法の変更  レプリケーションの際のMasterサーバのhost名等がmy.cnfに書けなくなった  →change master toコマンド使う ・InnoDBでフルテキストインデックス使えるようになった ・InnoDBのいくつかのALTER TABLEでロックが掛からないようになった ・memcachedインターフェースの追加 ・クエリオプティマイザを改善  サブクエリも最適化されるように。  UPDATE/DELETE/INSERTにもEXPLAINが使える ・GTID(Global Transaction ID) - スレーブの自動的な昇格が可能に ・遅延レプリケーション ・マルチスレッドスレーブ(SlaveのSQLスレッドがマルチスレッドに) ・/usr/my.cnf←ないわー
  14. 14. 準同期レプリケーション MySQL5.5から使える 標準の非同期レプリケーション クライアント Master Slave 更新SQL ACK 更新SQL ACK データ更新 ログ送信 IOスレッド SQLスレッド リレーログ読み取り データ更新 ログ送信 障害発生 Masterは更新を続けるが、 障害発生以降、Slaveは更新されない
  15. 15. 準同期レプリケーション2 準同期レプリケーション クライアント Master Slave 更新SQL ACK ACK データ更新 ログ送信 IOスレッド SQLスレッド リレーログ読み取り データ更新 Slaveサーバからackが返ってきた時点で初めてcommitが成功 IOスレッドは同期処理、SQLスレッドは非同期処理=準同期 メリット HA実現 デメリット Masterの更新がSlaveのIOスレッドの処理に引きずられる。 (SlaveのIOスレッド、SQLスレッドはシングルスレッド/ただし5.6からはSQLスレッドがマルチスレッド) ACK

×