rsyncでディレクトリを同期の対象から外したい

rsyncでディレクトリを同期の対象から外したい。

すでにexcludeを利用しているが、同期しているディレクトリの途中にはさまっているディレクトリを、そのディレクトリ以下すべてを同期の対象外としたい。

rsync で特定のディレクトリを同期対象外にする –exclude の指定方法

どうやら

--exclude="hoge/"

ってかくといいみたい

mysqlのレプリケーションがこける “Error initializing relay log position: Could not find target log during relay log initialization”

mysqlのレプリケーションが下記のようなエラーでこけるようになった。

Last_SQL_Error: Error initializing relay log position: Could not find target log during relay log initialization

やったことといえば新たにmysqlを立て直してデータをリストアして、レプリケーションの設定を復元してやった。

ログは途中から読ませた。そしたらエラーに。何度やってもエラー。前はうまくいったのになぁ。

原因判明。どうやらmy.cnfにレプリケーションの内容が書いてあったらしく、その段階ですでにレプリケーションのスレーブを開始してた。そんでそこにデータを突っ込んで、さらにchange master toしたからログの位置がよくわからんくなって、master.infoの中身が整合性がとれなくなったらしい。master.infoとrelay-log全部けしてchange master toしたらうまくいった。

FreeBSDのホストにsshが繋がらない時のある対処法

あるホストでsshの調子が悪くなった。
sshのサーバ側、繋がれる待ち受け側はFreeBSD7.2-R i386

OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen

クライアント側、繋ぎにいく側はFreeBSD。

これだとどこからもつながらない。

sshclient.l2tp.org%ssh badssh.l2tp.org
Connection to 10.0.0.1 timed out while waiting to read

FreeBSDだと繋がらない、というのは、windowsのputtyだと時間がかかるけどつながる。なんでだろう。

FreeBSDからtelnetするとこんな感じ

sshclient.l2tp.org%telnet badssh.l2tp.org 22
Trying 121.1.227.95...
Connected to badssh.l2tp.org.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901

とちゃんと応答がある。

予想だと名前解決あたりでこけてるんじゃないかな、と。

と思ったらマジでこけてた。resolv.confの最初がつながらないホストが指定してあった。

おそらくここのタイムアウト待ちして次のname serverに聞きに行く前に、freebsdのsshクライアントがタイムアウト処理しちゃうんだと思われる。それに対してputtyだとタイムアウト値が長い模様。

mysqlがクラッシュした

mysqlがクラッシュした。

hddのエラーっぽいのが発生したよ、とかいって再起動を勝手に繰り返しまくる。

おかげさまでリレーログが大量発生してる図

aaa

これはbinlogがたくさん
エラーメッセージの内容。HDDエラーとか言ってる。
再起動を終えた直後のログ。勝手に再起動しまくる。
何かのダンプ

aaaaaaaaa

wordpressで記事が削除されたと出る件

wpで管理してる記事が削除されていると出る。
ちょっと雰囲気が違うのは、have_postでコケてること。
permanent_structureを使っているのでcanonical.phpでリダイレクトさせないようにして?p=1234でアクセスすると、single.phpのhave_postがfalseを返してきている。
permanent_structureでアクセス、もしくはcanonicalでリダイレクトすると404ページに飛ばされる。

最初は原因不明だった。memcacheによるキャッシュを利用していた(object-cache.php)んだけど、これの動作がちょっとわかりにくいし、発生し始めたのがキャッシュを利用し始めた時期とかぶる。
試しにmemcacheでキャッシュの中身を見てみると、key: “wp_:posts:1234″はちゃんとある。これがあるって事は記事が存在するはず。DBの中を見てみると記事がある。
どこでこけてるか確かめてみると、post.phpの途中、L2295あたりにある

if ( !empty($this->posts) && ($this->is_single || $this->is_pag\
e) ) {

この辺。

if ( !empty($this->posts) && ($this->is_single || $this->is_pag
e) ) {
if ( ('publish' != $status) ) {
 if ( ! is_user_logged_in() ) {

この三段階の条件を見事スルーして記事が無いように見えてしまうらしい。
他の正常な記事だと途中で条件から抜けてる。
ちなみにこの後に待っているのは

$this->posts = array();

で、これが入っちゃうからpost_countが0になるらしい。それでhave_post()がfalseになる。
よく記事の内容を見てみるとpost_statusがtrashになってる。trashってのは見たことが無かった。
post.phpにwp_trash_post()の定義が。見ると2.9.0で実装されたらしい。
この関数はwp_delete_post()から呼ばれるらしい。
外部で削除の制御、記事の追加を行っていたのだけど、削除の時はwp_delete_post()を使って、挿入は手動で行っていたのでそうなっちゃったぽい。
ひとまずはpost_statusを全部publishにして対処。insert周りをいじるのは大変かも。
以上。