これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
A Bunch of Great Strategies for Using Memcached and MySQL Better Together - High Scalability -
The primero recommendation for speeding up a website is almost always to add cache and more cache. And after that add a little more cache just in case. Memcached is almost always given as the recommended cache to use. What we don't often hear is how to effectively use a cache in our own products. MySQL hosted two excellent webinars (referenced below) on the subject of how to deploy and use memcach
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
MySQL スレーブで SQL スレッドが停止した場合の対処方法 - maruko2 Note.
MySQL スレーブで SQL スレッドが停止した場合の対処方法 提供：maruko2 Note. 移動： 案内, 検索 MySQL スレーブで SQL スレッドが停止（Slave_SQL_Running: No）した場合、次のような対処方法がある。 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event 省略 Relay_Log_Pos: 13550246 Relay_Master_Log_File: mysql-bin.000010 Slave_IO_Running: Yes Slave_SQL_Running: No 省略 Last_Errno: 1062 Last
MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
MySQL DBマスタのDC間移設 | Ore no homepage
システムをデータセンターAからデータセンターBに論理移設を行うときのメモ。 肝になるのはDB、特にマスタDBだと思うので、主題の通りおもにDBマスタの切り替えに焦点を当てて手順を書く。 移設先であるデータセンターBではサーバ構築やアプリケーション/コンフィグのデプロイは完了していて、新マスタおよび全スレーブは現マスタにレプリを張っている状態からスタートする。新マスタにはバイナリログ出力など、DBマスタとして振る舞うための設定が入っているものとする。 手順の要約 現DBマスタへの更新クエリをすべてブロックする 全てのスレーブと新マスタでshow slave statusしてログとポジションが一致していることを確認する 新マスタと全てのスレーブでstop slaveする 新マスタと全てのスレーブでreset slaveする 新マスタでreset masterする 全てのスレーブでchange
SHOW FULL PROCESSLIST を使った MySQL のプロファイリング : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の3日目は、 引き続き MySQL 周りのチューニングノウハウとして、すぐに役立つ プロファイリング方法を紹介します。 DBサーバーの負荷が高い時、 slow_log を見て問題になっている重いクエリを 発見するのが一般的かもしれませんが、 slow_log に一切ログが残らないのに 負荷が高い状況や、むしろ負荷が高すぎてごく一般的でどう考えても遅いはずが ないクエリ ("SET NAMES utf8" や "BEGIN") すら slow_log に大量に乗ってしまう場合が あります。 slow_log 以外で問題になっているクエリを見つける方法として、 "SHOW FULL PROCESSLIST" コマンドがあります。これを数回〜数十回叩いてみて、 よく出ているクエリは、遅かったり量が
INDEX FULL SCANを狙う - MySQL Casual Advent Calendar 2011 - SH2の日記
2011年8月のkazeburoさんのエントリに対する解説記事です。結論から言うとkazeburoさんの案に賛成なのですが、本日はどうしてそうなったのかというところを確認していきたいと思います。本記事はMySQL Casual Advent Calendar 2011の17日目のエントリです。16日目はakira1908jpさんでした。 当時の内容を覚えていない方は、先にkazeburoさんのエントリをご一読ください。また、テストケースがGitHubに公開されていますのでカジュアルに再現試験をすることも可能です。 Covering Index と self-join と MySQL - blog.nomadscafe.jp kazeburo's gist: 1150842 - Gist 問題のSQLをチューニングするには、MySQLがインデックスに対してどのようにアクセスするかという点につ
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
稼働中のMySQLに無停止でスレーブを追加する - 雑記帳(2011-10-17)
■ [MySQL] 稼働中のMySQLに無停止でスレーブを追加する MySQLは簡単にレプリケーションすることができて便利。最初からレプリケーションを前提に構築するのは簡単にできる。しかし、実は運用が始まってしまって、なかなか停止できないMySQLにも、ほぼ無停止でスレーブサーバを追加できる。現在の設定状況にもよるが、再起動は必要になるかも。 マスターでバイナリログを出力するようにする my.cnfで、binlog_do_dbの設定をする。レプリケーション対象となるデータベースを指定する。 [mysqld] binlog_do_db=your_db マスタのserver_idを設定する my.cnf で server_idの設定をする。レプリケーションする際に、個々のサーバを識別するのに使われる。任意のユニークな整数を指定すれば良い。 [mysqld] server_id=10 ここまでの
mysqldumpの--order-by-primaryオプションについて - SH2の日記
TIPSです。このようなテーブルがありまして、 CREATE TABLE `link` ( `id1` int(11) NOT NULL DEFAULT '0', `id2` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id1`,`id2`), KEY `ix1` (`id2`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;データは以下のような感じで、このときは2,900万レコードありました。 +---------+---------+ | id1 | id2 | +---------+---------+ | 5 | 69 | | 5 | 1022 | | 5 | 1487 | … | 1081 | 2021414 | | 1081 | 2087813 | | 1082 | 11 | | 1082 | 225
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
既存レプリケーション環境に新スレーブ追加 - Studio3104::BLOG.new
MySQL Casual Advent Calendar 2011の27日目として更新します。 皆さんがまったくcasualじゃないので、バシッとコンセプト通りの記事をあげます。 ちなみに今日は熱出して会社を休んでおります。 アタマがぼーっとしている中書いてますので、変な事書いてたらスミマセン・・・ マスタ-スレーブ-スレーブ構成のMySQLで、サービスを停止せずにスレーブを追加する方法を紹介します。 参照が多くなってきたなーってときに、ピークタイムを避けて作業すればメンテナンスを入れなくてもスレーブを増やせます。 環境、構成 この構成に、スレーブCを追加する 【MySQLマスタ】ー【MySQLスレーブA】 ｜ 【MySQLスレーブB】 サービスからMySQLスレーブAを切り離す スレーブAのコネクションをモニタ netstatコマンドで、スレーブAのmysqlコネクションをモニタリングし
(KANGO)
昔は白のワンピーススタイルが中心だった看護師の白衣ですが、時代の流れとともにワンピース以外にもさまざまなデザインの白衣が登場し、カラーバリエーションも豊富になりました。そんな中で人気が高くなっているのがパンツスタイルの白衣です。 ここではパンツスタイルのメリットや、白衣のおすすめの購入方法などについて紹介しています。 合わせて読む：半袖の白衣のメリットとデメリットを知っておこう 白衣のデザインの変遷 看護師のユニフォームの定番とも言えるのが白衣です。白衣を着ることによって、気分も引き締まりますし、仕事への集中力を高めることができます。また、私服を汚さずに仕事ができる点もメリットの1つと言えるでしょう。 昔は看護師と言えば女性ばかりだったということもあり、白衣と言えばワンピーススタイルがほとんどでした。しかし、現代ではワンピーススタイルだけではなく、男性看護師の増加もあり、パンツスタイルの白
MySQLのUNIQUEなINDEXには長さ767byteまでしか使えない件と対策 - tanamonの稀に良く書く日記
はじめに たとえばこんなDDLを投げる。 CREATE TABLE test ( id int(10) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY, hoge varchar(256) NOT NULL, UNIQUE KEY (hoge) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; するとエラーになる。 Specified key was too long; max key length is 767 bytes (SQLState:S1000)エラーに書かれているとおり、keyは最大で767byteまでしか使えないらしい。 ちなみにkeyはPRIMARY KEYとUNIQUE KEYがダメ、ただのKEYならOK。 で、どうするか。 1.素直に諦める 上記例ではテーブルがCHARSET=utf8のため1文字3b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://mysql-casual.org/2012/04/mysql-casual-talks-vol3-1.html
Good night, Posterous
GitHub - taka84u9/fluent-plugin-mysqlslowquery: Fluent input plugin for MySQL slow query log file.
株式会社TAP