誰も教えてくれなかったMySQLの障害解析方法 - Qiita
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
mysqlのHAがらみのトラブルの思い出 - smallpalace's blog
いーつのことーだかー思い出してごーらん、あんなことーそんなことーあーったでしょー。 というわけでこんにちは。smallpalaceです。 ちょっと前にテクニカルセミナー的な機会があって思い出してくれということになり思い出したのでかける範囲で書いときます。 mysqlの運用時のトラブルまとめ。HAがらみのところほか順不同です。 ・高負荷後の「max_connect_errors」がらみでホストによっては拒否されてアクセスできなかったりなど。対策としては、flush hosts;とmax_connect_errors=999999999でエラーカウント無効になるようです。 ・主にクラウド上でI/OスパイクでF/Oしやすい。（I/O共有なのでしょうがないです）ベンダによってはDBだけ物理で提供（納期はかかる）というのもメニューにあったりして人気があるようです。予算が許せばioDriveとかステキ
ZNC Failing to Connect
While setting up ZNC, a BNC for those who had not guessed, I ran into the following error <*status> Cannot connect to IRC (Cannot assign requested address (Is your IRC server's host name valid?)). Retrying... Googling for the exact error did not help much either, since most I got were pastebins with just that error repeated a few times. Quite useless. Next stop was the ZNC IRC channel on EFnet. Tu
Redisでログの書き込みがblockを引き起こす - 酒日記 はてな支店
「RedisかわいいよRedis」(by typester)……というほど自分は Redis 期でもないのですが、最近 Redis を使ったサービスの面倒を見ていて時々レスポンスが悪化する現象に出会ったので調べました。 前提 使用しているのは Redis 2.4.16 です。 redis.conf に "save [t] [n]" を定義すると、最後に save をしてから [t]秒間に [n]個以上の key が更新された場合に background で save (=bgsave) が実行されます。 save 60 10000これだと、60秒間に 10,000 keys です。 bgsave では redisは自分自身のプロセスを fork() し、子プロセス側は自分のメモリに乗っている内容をファイルにすべて書き出します。 この仕組みによって、1プロセス 1スレッドで動作している re
ディスクがとんだので md RAID を修復した - daily dayflower
作業メモ。 以下の2台のハードディスクを md で /dev/md0 として RAID-1 をくんでる。 /dev/sdb 1TB (SAMSUNG HD103UI) /dev/sdc 1TB (WD WD10EADS) ある日 smartd からメールがとどいていた。以下の2通。 Device: /dev/sdc, 1 Currently unreadable (pending) sectors Device: /dev/sdc, 5 Offline uncorrectable sectorsいわゆる Caviar Green のほうがちょっとおかしくなったらしい。 dmesg みてみる。 ata4.00: exception Emask 0x0 SAct 0x3e7ffe0f SErr 0x0 action 0x0 ata4.00: irq_stat 0x40000008 ata4.0
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
mysqlbinlog なんてやめて show binlog events を使おう - いちいの日記
夜中に眠いのに master のディスク容量がいっぱいで、でも binlog 用のスペースがない slave たちはまだ明日起きてから対応するんでも間に合うとき。よくありますよね。 ほっといてエラーになるよりかはその場しのげる方がマシ 多少サービス止めるなり i/o 負荷が高くてもいいから何とかしたい 根本的には master 切り替えるしかない だが、そこまで元気がない そんなとき、いままで mysqlbinlog と格闘しながら pos のコピペに注意しつつやってたんですが、 show binlog events という便利コマンドがあることを今更知ったメモです。 基本的な方針 master から絶対に読み込みがないデータを消して、延命することにします。しかし innodb だったりするので単に delete しても容量は減りません。 そこで、えいやとアプリを止めて (or table
http://www6.ocn.ne.jp/~caribou/i-mode/fsck.html
■突然リードオンリーでデバイスがマウントされた(ファイルシステムエラー編） ０．リードオンリーとなった場合（通常リードライトのパーティションが） ★当該パーティションのファイル編集やパーミッション変更時に 【Read-only file system】が出力される。 １．とりあえず、リードライトでリマウント # mount -t ext3 -o rw,usrquota,remount /dev/hda1 /opt ★出力ALM：【block device /dev/hda1 is write-protected, mounting read-only】 ２．I/O errorメッセージ確認 # dmesg # less /var/log/messages ⇒ファイルシステムのエラー(I/O error)によって強制的に Read-Only モードに移行させられる のでシステムログを確認する
レプリケーション時のエラースキップ - bushimichiの日記
MySQLのレプリケーションで、稼動中のマスターDBからスレーブDBに データをコピーし、レプリケーションを開始したところ ところどころで、error 1060 プライマリーキーの重複などのエラーがでました。 最初は、 SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE SQL_THREAD;として、処理を再開していましたが、大量に出てきてこりゃ手に負えないわということで my.cnf に以下を追記し再起動 [mysqld] slave-skip-errors=1060一応、今のところ問題なくレプリケーションしてます。 そもそも、稼動中のMySQLのレプリケーションのやり方を詳しく説明しているのを見つけることができず とりあえずで、以下の手順でスレーブを作りました。 （１）マスターをコピーして、スレーブに移動 （２）マスターのバイナリーログをな
Network Troubleshooting: A Complex Process Made Simple
Network Troubleshooting: A Complex Process Made Simple Gideon T. Rasmussen - CISSP, CISM, CFSO, SCSA The most efficient manner to troubleshoot a network issue is to approach it in a systematic way. Start by gathering background information; then troubleshoot following the Open System Interconnection (OSI) networking model. GATHER BACKGROUND INFORMATION It is critical to obtain a complete picture o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLの冗長化 2013-01-24
弊社データセンターにおける通信障害について｜プレスルーム｜日鉄ソリューションズ
DNS Troubleshooting - Everything Depends on It