Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #課題 /tmpと/var/tmpどっちも大体一緒だからいいんじゃないかと思って/tmpにファイルをつくろうとしたら、プログラムが使用するものは/var/tmpにと叱られた。確かに、基幹系システムのディストリビューションだと何故か/var/tmp派の人が多かった気がする。じゃあ、linux系特有の宗派の問題なのか?と思い調べてみた。 #何が他のディレクトリと違うか 通常のディレクトリは、基本的にはファイルは削除しない限り消えない。 /tmpに関しては再起動するとファイルが綺麗さっぱり無くなる。 /var/tmpは再起動しても消えないがい
まえがき これは、とあるウェブプログラマーがやらかした事件の手記である。 返事がない ある日、Railsでmigrationを書いて、デプロイしたときに、ブラウザ氏からこう言われた。 502 Bad Gateway nginx/1.4.3 _人人人人人人_ > 突然の死 <  ̄Y^Y^Y^Y^Y ̄ まったくシャレにならないので、なんとかしよう。 原因を究明しよう まず、原因を探ろう。 よくよく思い出してみると、マイグレーションが重すぎて途中停止してるっぽかった。その頃からアクセスが死んだようにも思える。 ということは、何かの拍子にDBをロックしてしまった可能性が高い。 ロック、聴くぶんには大好きだけどハメられるとすごく辛い。しかも死んでるし。 で、mysqlのprocesslistを確認する。原因となる作業プロセスがいるはずだ。 processlistの探り方 基本はUNIXのpsとかとだ
サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだMySQL ALTER TABLEすると以下のような挙動でカラム変更されるようです 他のセッションからのREADを許可し、WRITEをブロック 新しいtable定義の一時テーブルを作成 一時tableに元tableのデータをすべてコピー 一時tableを元table名にリネームして元tableを削除 ブロックされていたWRITE系クエリを反映 全コピしてるので、ALTER TABLEを実行する時にどでかいtableのサイズの場合は長い時間WRITEがブロックされるので注意が必要です。 ALTER TABLEを実行した環境 上記を踏まえた上で、以下のようなテーブルにALTER TABLEを実行してカラム追加する事にした レコード数はちょっとしかない READ
Waiting for table metadata lockって何? 8.10.4. Metadata Locking Within Transactions 日本語ページにこの説明は無いので、頑張って翻訳してみます。 To ensure transaction serializability, the server must not permit one session to perform a data definition language (DDL) statement on a table that is used in an uncompleted transaction in another session. トランザクションの直列化を確保するため、他セッションによる処理が完了するまでの間、DDLの実行は許可しません。 As of MySQL 5.5.3, the serv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く