ERROR: canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed. これは字の如く、レプリケーション側でWALの反映時にコンフリクトして強制的にクエリを殺されています。 理由は下記のスライドがわかりやすいです。 PostgreSQLによるデータ分析ことはじめ from Ohyama Masanori www.slideshare.net 詳細は公式ドキュメント読むと良いです。 26.5. ホットスタンバイ 追記（2017/12/28） 俺達のヒーロー @sawada_masahiko くんが完璧に補足してくれたのでちゃんと知りたい人はこっちを見ましょう。 qiita.com なぜコンフリク

4月からオミカレに戻ってきて半年たった。 ちょうど今月が期末だしこの半年を振り返る。 soudai.hatenablog.com party-calendar.net 4月 CTOになった（1年と3ヶ月ぶり 2度目) オミカレを離れている間の事をキャッチアップするのに心血を注ぐ感じだった。 1年ぶりに読んだプロダクトコードは機能もコードも1年で随分育つというか驚きのレベルだった。 「男子三日会わざれば刮目して見よ」というがプロダクトコードも同じである。 変更点と新たに生まれた課題点の整理をするためにかなり時間を使った。 それと並行して運用フローの見直しであったり、体制変更に伴うツールの選定、移行などをやった一ヶ月だった。 その結果、課題はかなり整理できてこの半年～1年で何をやるかを整理できた。 前職でJOIN直後はやりたい放題するチャンスと学んだので4月の後半からはドラスティックな運用フロ

表題についてそーだいなる見解を書き残します。 今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。 懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは？という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています！！！ www.koemu.com 忘れてないんですよ！しっかり覚えています。 結論 仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。 ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。 php-genba.shin1x1.com システムの柔軟性 勿論、コードの綺麗さや

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の24日目です。 qiita.com soudai.hatenablog.com それでは24日目は mackerel-plugin-json です。 mackerel-plugin-jsonはその名のとおり、JSONを可視化するプラグインです。 github.com 2020/12/02 追記 めちゃめちゃ便利なmackerel-plugin-jsonも進化していて、下記に出てくる多くの問題点が解決しています。 インストール カウンター値の計算 header付与によるセキュリティ これらを解決した機能の説明についてはこちらをご参照ください。 cohalz.co インストールと設定手順 mackerel-plugin-jsonのインストールですがmackerel-plugin-jsonは公式パッケージに同梱されてい

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の9日目です。 qiita.com soudai.hatenablog.com それでは9日目は check-tcp です。 check-tcpはTCP Socketを監視してくれるプラグインです。 github.com インストールと設定手順 至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！ mackerel.io 使い方 至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！ mackerel.io オプション一覧 README.mdにあるけど表記しました。 # check-tcp -h Usage: check-tcp [OPTIONS] Application Options: --service= Service name. e.g. ftp, smtp, pop, imap

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の11日目です。 qiita.com soudai.hatenablog.com それでは11日目は mackerel-plugin-multicore です。 mackerel-plugin-multicoreはマルチコアのCPUを監視するためのプラグインです。 Mackerelではmackerel-agentが送るシステムメトリックスでもCPUの使用率を見れます。 しかし、個々のCPUの利用状況を見ることができません。そこでmulticoreプラグインの出番なのです！ github.com インストールと設定手順 multicoreのプラグインは /proc/stat の中身を可視化してくれるプラグインです。 本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の8日目です。 qiita.com soudai.hatenablog.com それでは8日目は check-procs です。 check-procsはプロセスを監視してくれるプラグインです。 github.com インストールと設定手順 至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！ mackerel.io 使い方 至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！ mackerel.io オプション一覧 公式ドキュメントに無いので追加しました。 # check-procs -h Usage: check-procs [OPTIONS] Application Options: -w, --warning-over=N Trigger a warning if over a n

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の7日目です。 qiita.com soudai.hatenablog.com それでは7日目は check-log です。 check-logはその名の通り、ログの中身をチェックしてくれるプラグインです。 github.com インストールと設定手順 至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！ https://mackerel.io/ja/docs/entry/howto/mackerel-check-plugins 使い方 至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！ mackerel.io オプション一覧 公式ドキュメントに無いので追加しました。 # check-log -h Usage: check-log [OPTIONS] Application Option

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の2日目です。 qiita.com soudai.hatenablog.com それでは2日目は mackerel-plugin-apache2 です。 ここではApacheの細かい説明は割愛します。 mackerel-plugin-apache2はWebServerとして広く使われているApache2専用のpluginです。 こちらは README.md にも書いてある通り、 server-status を可視化してくれるプラグインで簡単に導入することができます。 github.com インストールと設定手順 本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。 インストール先は /usr/bin/mackerel-plugin-apache2

Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre

って話を明日のPHPカンファレンスでする予定でした。 PHPカンファレンス、私用のため私の登壇をキャンセルします。楽しみにされてた皆様、大変申し訳ありません。当日登壇予定だった内容はブログに細かく詳細まで記載して公開します。この度は皆様、ご迷惑をおかけします。 #phpcon2017 https://t.co/qgHogswYeI— そーだい@初代ALF (@soudai1025) 2017年10月6日 ここにあるとおり、雨の影響により、子供の運動会が延期になり、PHPカンファレンスと被ってしまいました。そこで色々悩んでいたところ、スタッフの方が気を利かせて連絡を先にくださり、キャンセルさせていただくことにしました。正直年に1度のお祭ですし、会いたい人も沢山いるイベントですから断腸の思いでした。しかも僕は今年各地のPHPカンファレンスに出れなかったので会えていないPHPerの方が多く居ます

GoogleSpreadsheetに定期的に登録したいタスク一覧を書いておくとGoogle Apps Scriptで自動登録されるようにした。 GASをチョイスした理由は2つ。 定期実行されるためのサーバが不要 スプレッドシートとスクリプトが対になるので「この処理してるスクリプトどこ？」ってなりにくい GASを使ったので一覧管理はスプレッドシートしたとも言える。 スプレッドシートだとそれなりにセキュアな環境で簡単にチームに共有出来るのもメリットだし、メンテナンスがエンジニア以外でも出来るってのがメリット。 細かいところはチームのフローに合わせて調整するとそれなりに使えるんじゃないかな。 ちなみにGASは下記のような時間トリガーで実行できる 指定日時 毎日の指定の時間 毎週の指定曜日と指定日時 毎月の指定の日時 なのでそれ毎にスプレッドシートのシートを作ってGASもそれぞれ作る想定。 あんま

Mackerel / NewRelic / Elasticsearch Seminar という夢のコラボーレーションのイベントで登壇してきました。3サービスそれぞれ強みがあって、勿論競合する部分（代替できる部分）もあるのだけど組み合わせて使うことが多いと思っているサービスです。次は「住み分けにこんなユースケースあるよ」みたいな話が出来れば聞きたいのでそういう企業で喋りたい人、絶賛大募集中です。 登壇について で私の資料はこちら。 speakerdeck.com インフラエンジニアからすると知ってて当たり前のtopコマンドの見方みたいな話になってます。でもtopは今を知るためのコマンドで歴史を知るためにはモニタリングが必要です。そして歴史（履歴）が無いと障害対応の時に比較することができません。これは id:y_uuki くんが言ってる下記のツイートがまさにそのとおりだと思っています。 モニタ

私がはてなに入社した時には大方話が進んでいて、見守るだけだったMackerel本だがついに発売されました。普段MackerelのCREとして活動している自分にとって「お客様に勧めれる本かどうか？」って言う点と「読んだ人に本の内容を質問される可能性が高い」ので一通りちゃんと読んだ。 みんなに勧められる本か 結論：安心して勧められる。 私はMackerelをそれなりに知っている前提だが全部ちゃんと読むと4時間程度で読めた。つまり分量的にはそんなに多くはない。カラーが多く、文字も大きいので比較的サクサクページが進む。特に前半部分はMackerelを一度でもインストールしている人は読み飛ばせると思う。必要な箇所だけ読むならそれこそ1時間である程度つかめる内容だ。なのでMackerelを全く触った事ない人は id:koemu さんの言うとおり、公式本として力を発揮するだろう。新メンバーが入ってきたと