誰も教えてくれなかったMySQLの障害解析方法 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
解析まで10分！最強のMySQLチューニングツール「Jet Profiler」 - Lancers開発ブログ
こんにちは、keiです。 今回は、MySQLのチューニングに大活躍な「Jet Profiler」というツールをご紹介します。 Jet Profilerとは Jet Profilerは、MySQL向けのクエリアナライザです。 クエリチューニングは、DBパフォーマンスチューニングの中でも重要な作業の1つですが、 Jet Profilerを使えば、その作業をGUIで直感的に行うことができます。 フリーウェアの形態で提供されており、機能限定版であれば無料で利用することができます。 購入する場合は、$499となります。 詳細情報、ダウンロードは公式ページからどうぞ。 http://www.jetprofiler.com/ja/ Jet Profilerの魅力 その1 導入のしやすさ 通常のWindowマシンに、普通のアプリケーションをインストールする感覚でインストールが可能です。 イン
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
MySQLでSLAVEサーバを作る方法 - sanonosa システム管理コラム集
今回は、いわゆるMySQLでレプリケーションを行う方法を記してみます。非常に今更感がありますが、自分にとってかゆいところに手が届く文献がなかったので、自分でも一度まとめてみようと思いました。 【MySQLにおけるレプリケーションとは】 MySQLにおけるレプリケーションとは、マスターサーバでの更新情報がほぼリアルタイムにスレーブサーバに同期化される仕組みのことを指します。 マスターサーバ上で更新が起こると、バイナリログ(更新ログとも呼ばれる)に更新情報が記録されていきます。スレーブサーバは随時マスターサーバ上の更新情報を追いかけることでマスターサーバ上のデータをスレーブサーバ上で再現していきます。 レプリケーションにはシングルマスタ構成とマルチマスタ構成があり、通常はシングルマスタ構成を使います。シングルマスタ構成は1台のマスターサーバの下に複数台のスレーブサーバがぶらさがっているイメージ
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
漢(オトコ)のコンピュータ道: モダンなMySQLの開発環境の構築方法
遅ればせながら モダンな Perl の開発環境の構築方法 モダンなPHPの開発環境の構築方法 モダンなPythonの開発環境の構築方法 モダンな Java の開発環境の構築方法 に続いてみる。MySQLは言語じゃないけど。 コンパイラ等MySQLをソースからビルドするのでなければコンパイラ等は必要ないけど、どうせアプリ開発に必要なので「MySQLなんかいつでもハックしてやるぞ！」という意気込みを示すために入れておこう。OSXならXcode、LinuxならGCC。最新のソースコードじゃないとヤダ！という粋な人にはBazaarのインストールもお勧めしたい。Bazaarは言わずと知れた分散バージョン管理システムであり、MySQL開発チームも採用している。最新のソースコードは次のコマンドでゲット可能だ。 shell> bzr branch lp:mysql-server/5.1 mysql-5.1
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
KLab
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
［MySQLウォッチ］第44回 MySQL 5.1レプリケーションの注意点
MySQL5.1には，大きく改良されたレプリケーション機能が搭載された。これまでのステートメント（SQL文）ベースのレプリケーションに加えて，マスタの更新結果をスレーブが反映する行ベースのレプリケーションが搭載されたのだ。レプリケーションの機能追加によって，より正確なレプリケーション処理が可能になった。 しかし，よいことばかりではない。行ベースのレプリケーションは，注意すべき点が存在する。これまでのステートメントベースのレプリケーションと同様の設計や運用では，パフォーマンスを得られない恐れがある。今回は，MySQL5.1レプリケーションの注意点を解説する。 MySQL 5.1のレプリケーション MySQl 5.1のレプリケーションには，同期方法として3つのモードが実装されている。ステートメントベースは，マスタで実行されたSQLステートメントをスレーブでも実行する方式だ。MySQL 5.0ま
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
MOONGIFT: » たった1ファイルのMySQLフロントエンド「phpMinAdmin」:オープンソースを毎日紹介
MySQLを使った開発において、その管理インタフェースによく使われるのがphpMyAdminだ。とても便利で使いやすいソフトウェアではあるが、長い開発の歴史の中で肥大化し、様々なニーズに対応し、そのファイル数も数多くなってきている。 テーブル構造の表示 便利になることは悪いことではないが、あまり肥大化したアプリケーションは設置の手間や、問題が発生した時の解決手段が分からなかったりと問題も出てきてしまう。そこで一気にスリムなこれを使ってみよう。 今回紹介するオープンソース・ソフトウェアはphpMinAdmin、1ファイルのMySQLフロントエンドだ。 phpMinAdminはPHP製のソフトウェアで、たった1ファイルしか配布されていない。これを設置するだけでMySQLの管理が行えるようになる。ユーザの権限設定や、データベースの選択からはじまり、一通りの操作ができる。 データの一覧表示 テーブ
MOONGIFT: » MySQLの高度な管理ツール「Maatkit」:オープンソースを毎日紹介
最近のWebサービス開発ではオープンソースのデータベースを利用することが多くなってきた。それだけ信頼性や安定性も向上してきたということだろう。以前はPostgreSQLの方が人気があったが、最近ではMySQLを選ばれる方が多いようだ。 mk-parallel-dumpのヘルプ そうした中で、必要になってくるのがMySQLの管理ツールだ。特に規模の大きな開発を進める上で、デフォルトのツールだけでは物足りないと感じていた人は、こちらのさらに洗練されたツールを使ってみよう。 今回紹介するオープンソース・ソフトウェアはMaatkit、MySQL向けのコマンドラインツール群だ。 MaatkitはPerlで作られたソフトウェアで、MySQLの高度な操作を可能にするツールが幾つも提供されている。それらはmk-ではじまる名前のコマンド名になっている。執筆時点では19の機能がある。 コマンド一覧 主なコマン
GIGAZINE、ついに新サーバへ移転完了
というわけで、ここが新サーバ群による新生GIGAZINE.NETです。この記事が見えているということは、新しいサーバへのDNS浸透が済んだということです。見た目上は特に何かの変化があるわけではないのですが、サーバが物理的にトラブルを起こさない限りは重くなったりはしない……はず。 というわけで、前回の記事に引き続き、裏話第2弾です。詳細は以下から。 ・MySQLのDNSルックアップを無効化 新サーバ構成でテスト中に最大の問題となったのがコレ。ルータが落ちまくるので一体何が起きているのかがわからず、延々と1週間も悩み続け、GIGAZINE編集部を恐怖のどん底にたたき込んだものです。結論から言うと、外部のDNSサーバを利用していたため、ローカルでのテスト環境においてもMySQLに接続が発生するごとに、DNSの参照が発生していたのが原因。 MySQL :: MySQL 4.1 リファレンスマニュア
ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpやMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLバックアップの基本
初心者向けMySQLの始め方
