サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ドラクエ3
blog.toor.jp
お久しぶりですー、毎度毎度超不定期更新ですいません^^; 「RHETOLO」の関連サービス「れとろ握り」や「レトロバッヂジェネレータ」、「あぷり握り」をガリガリ作りつつ、基幹システムの調整やら不具合対応やら新機能の構想やらで相変わらずバタバタしておりますが、このあたりのご紹介はまた後日、ということにしておいて。 以前、「lsyncd+rsyncでミラーリング」なる記事を書きましたが、あれからlsyncdには本当に色々なところで活躍してもらっています。今回のRHETOLOサーバでも使っているんですが、最近ディレクトリ同期が取れなくなる、という現象に悩まされていました。 ログを見ても特にエラーらしきものはなく、むしろ逆に「ファイルの変更が検知できていない」という感じ。 カーネルバージョンなどを疑っていましたが、どうやら原因は別のところにあったようです。。。 ずばり、原因は「ユーザマイページシス
データベースを設計する時、どんなツールを使ってますか? 『そうさっ、viと脳だけがと~もだっちっさ~っ』のikedaですこんにちは。 ま、今までというか今でもさくさくっと作るときはviで直接SQLファイル書いちゃいますが、後々拡張なんて話が出てきたときに頭を抱えるってことが多いわけですよ。 学習しろという話もありますが^^; 僕は基本的にviラヴ~な人なので、IDEなんてハイカラなものは使わない(正確には使えない)のです。 IDEって「重い」ってイメージがありましたし。。 でも、ちょっと使い続けられそうなツールを見つけましたのでご紹介(^^)b ベンダー謹製のデータベースモデリングツール、MySQL :: MySQL Workbench 5.1です! まだまだ使い方を解説できるようなレベルではないので^^; ざっくりとご紹介。 まずは特徴を公式ページから。 ビジュアルなデータベース設計
データベース接続確立エラー
すぐ忘れてしまいそうなのでメモ。 あ、ご無沙汰してます@ikedaです。 RHETOLOベータリリースで落ち着くかと思いきや、やるべきこと・やりたいことが山積みで相変わらずな状態ですorz さて、そのRHETOLOのhttps接続用にGeoTrustのサーバ証明を使っているんですが、初めてhttps接続する時に「接続の安全性を確認できません」と火狐君に怒られる、という現象が報告されました(´・ω・`) 調べてみると、GeoTrust社のサーバ証明書はルートCAを含め3階層もしくは4階層になっていて、どうやらこの2階層目・3階層目の中間CA証明書が火狐君にインストールされていない場合に警告されるようです。 ということで、nginxに中間CA証明書をインストールしてみました。 まず、GeoTrustから中間CA証明書を取得してファイルに保存しておきます。 CA証明書はWebで公開されてますね。
以前、『lsyncdとrsyncdでミラーリング』という記事を書きましたが、あれ以来lsyncdにはかなりお世話になっています。 で、RHETOLOサーバでもバックアップと負荷分散のために導入しようとしたところ、lsyncdのバージョンが上がっていました(遅) 現時点(2011/7/31)での最新バージョンは 2.0.4 で、こちらからダウンロードできます。 inotifyを利用してファイルの変更を検知し、rsyncdを起動する、、という本来の機能には変わりありませんが、最も大きな変更点としては設定ファイルのフォーマットが今までのXMLからLuaになったという点ですね。 ということで、早速使ってみました。 インストールっ インストールやrsyncd関連についてはほぼ今までと同様でOKですので、詳細は以前の記事をご覧頂きたい(手抜き)のですが、バージョン2.xからビルドにはLuaライブラリが
仕事先でサーバリプレイスを行うことになり、まずは最も単純構成である動画ストリーミングサーバから手をつけることにしました。 現状、サーバは各々2台ずつの冗長構成になっており、従って動画ファイルもそれぞれに配布する必要があります。以前から面倒だなーとは思っていたんですが、このリプレイスのタイミングで動画ファイルの格納ディレクトリを同期させてやることに^^)b 最初に思いついたのはDRBD+heartbeat。しかし、YouTubeのような動画アップロードサイトではありませんし、そこまで頻繁に動画ファイルの更新があるわけではありません。リアルタイム性もそこまで必要というわけではないし。。 そもそもDRBDはアクティブ-スタンバイ式なので、両サーバから同時に読み出しを行うにはさらにNFSかiSCSI+CLVMを組み合わせるしかなさそうです(間違い・勘違いでしたらご指摘下さいm(_ _)m) で、グ
ニュースリーダーは今までに色々と使ってきましたが、現在は FeedDemon に落ち着いています。 なにより、Webアプリ・Windowsアプリ・iPhone/iPod Touchアプリ(NetNewsWire)が相互に同期してくれるので、非常~~~~に便利なのです。バージョン2.xまではNewsGator独自のサーバと同期していました(Webアプリも独自でした)が、バージョン3.0からはGoogleReaderと同期するようになりました! こりゃもう便利この上ないっすねぇ~~~!^^ まぁ、確かに3.0になってからちょっと重くなったとかiPhoneアプリのUIが替わったとかありますが、日本語化されていないのが難点。英語版のままでも日本語は全く問題なく使えますからいいんですが、なんていうかこの・・・・見た目?(笑 今まで「どうせ言語ファイルはバイナリ化されてんでしょ」と勝手に決め込んで、日
ほんっとにメモです^^; pgpool-II 公式ページのドキュメントによると、行うべきことは pgpoolの設定 C言語関数のインストール リカバリスクリプトの配置 の3点。 pgpoolの設定 pgpool.confの以下の値を設定します。 backend_data_directory バックエンドのデータディレクトリ($PGDATA)。 recovery_user リカバリに使用するユーザID。 recovery_password ログインパスワード。 recovery_1st_stage_command recovery_2nd_stage_command pgpoolでは2つのステージに分けてオンラインリカバリが行われます。ここにそれぞれのステージで実行すべきコマンドを指定します。 C言語関数のインストール リカバリを実施するためのC言語関数を全ノードの template1 デー
さて。前編からかな~~~り時間が経ってしまいました。 ということで今回は実際のインストールから設定内容をメモっておきたいと思います。 用意したもの DBサーバ2台(検証環境:Fedora6(古) 実機:RHEL3(こっちも古)) PostgreSQL(都合により 7.4.x) pgpool-II 2.1 pgpool-ha 1.1.0 heartbeat 2.1.3 libnet 当初はRPMでインストールしていましたが、最新バージョンにしたかったためソースからビルドすることにしました。設定ファイルやバイナリの場所は(個人的趣味により)基本的に /usr/local 以下としています。RPMインストールされる方や prefix を変更した場合は適宜読み替えてください。 インストール。 ということで、まずはガンガンインストールします。手順としては基本的に tarball解凍→ configu
ということでバグ追跡にはMantisを使い出してみたんですが、SCMとの連携に関してはSubversionとのものしか情報が得られません。 具体的にはSubversionのpost-commitフックを利用し、checkin.php というスクリプトにコミットログを含むコメントを食わせ、その中に特定のキーワードがあればチケットのステータスを変更させる、というものでした。 って、Gitにもばっちりhookってありますよね。しかも post-commit ってそのまんまのやつが。もしかするとこれをいじることで、同様のことができるんじゃないでしょうか? ものは試し、早速やってみました (^^)b ざっくりとした設定の内容は続きに。 では、Mantisのドキュメントにある内容を参考に進めてみます。 まず、SCMからチケットを弄ぶため、Mantisに専用ユーザを作れ、とのこと。何も考えずに”gitu
遂にGIGAZINEでも取り上げられることとなったヨドバシ・ドット・コム。 確かにこれだけの商品を扱うECサイト、しかもかなりのPVが予想されますからシステムもそれなりの構成になっているものと思われます。 「ヨドバシ・ドット・コム」がリニューアル直後から表示が遅すぎて激重になる大規模障害が発生、一体何が起きているのか? – GIGAZINE 詳しくはGIGAZINEのエントリを見ていただくとして、、 確かに重いですね、こりゃ。 あちこちで分析されていますが、ここはやはり技術屋の端くれ、FirefoxアドオンのFirebugで接続情報を見てみました。 ちょ、ちょっとwwww index.html (28KB) 返すのに 16.89秒ってwwww しかもCSSがやたら大きくて多いような気がします。。40Kとか12Kとか。 画像は全て専用の画像サーバ image.yodobashi.com から
仕事でPostgreSQLデータベースサーバの冗長化について調査と実験を行っていたんですが、昨日やっと設定が仕上がりました。忘れないようにメモっときますね(メモの割に長い。。)。 某ケーブルテレビ局のWebサーバ群なんですが、導入時から ファイアウォール(FW)→ロードバランサ(LB)→サーバ群 という経路は冗長化構成にしていました。しかし、データベース(DB)サーバのみ1台で、ここがシングルポイント(冗長化されていない個所)だったんですね。ケーブルテレビ局のWebサイトということで、DBには重要なデータも蓄積されます(問合せやプレゼントの応募などの個人情報とかですね)。 今回、このデータの損失を最大限防ぎ、なおかつシステム全体のダウンを最小限に抑えよ、とのお達しがお代官様上司より下りました。 要件としてはこんな感じ。 データの損失を防ぐ → レプリケーション DBサーバダウンによるWeb
tumblelogというブログ形式があります。 通常のブログはサイドバーやカテゴリ・アーカイブなど多種多様な機能を持ち、日記なりの独自のコンテンツを発信しています。書かれる内容は完全にオリジナルであるか、何か/どこかの紹介であったとしてもブロガーの独自の目線・意見が追記されますよね。 tumblelogはそういった通常のブログとは少し異なります。あえて言うなら、オンライン上で発見したアイテムや自分/他人の意見などを収集して公開するための「物置」のようなものです。 もっと手軽に、簡単に、シンプルなブログ、とも言えます。 TwitterやHaruに代表される一行ブログもシンプルなブログですが、記述される内容が テキスト 画像 動画 音声 引用 URL と、予めカテゴライズされているのが特徴です。 というとdel.icio.usやはてなブックマークのようなソーシャルブックマークか、と
このページを最初にブックマークしてみませんか?
『Ikeda->Weblog(); | Ikedaの徒然雑記。』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く