RSS

データベースのバックアップとか。

04 3月

リリースが終わった(?)わけですが色々あって公開しているのものの、手直しが合ったりなかったり。
まーβバージョンみたいな感じ?と思うことにします。

さて、今日は先日実際にやってみたのでメモ的に。超簡単。マジ簡単。

  • バッチをつくってデータベースのバックアップをとりたい!
  • です。現在VPSサーバ上で稼動しているので、別ストレージへのバックアップはとってるけれど、やっぱりまずステップとしてはデータベースのバックアップ(日々)のをとりたい。レンタルサーバでとってるストレージバックアップっていうのは、OSが爆発したとき(!)用みたいなもんで、たとえば「ああああデータ消失した!」みたいなあってはいけないトラブルには即さないと思うので、まずは稼動サーバ上に日時ごとにバックアップを取るようにしてみる。で、色々探してみたけど、cakeってシェルスクリプト書くの驚くほど簡単だな…。ソースコードはエクスギアさんのこのページがビンゴです。能がなくてごめんなさい、99%そのままです。設置も同じく、\app\vendors\shells におくだけ。プログラムが起動するためのパス/cake/console/cake への実行権限・ダンプデータのおき場所の書き込み権限は設定しておきましょう。ここも忘れやすいね。

    <?php
     class MysqldumpShell extends Shell
    {
    	// データベース設定ファイルの定義名
    	var $database_config = 'default';
    	function dump(){
    		Configure::write('debug', 0);
    		App::import('Core', 'ConnectionManager');
    		$db =& ConnectionManager::getDataSource($this->database_config);
    		// 曜日単位でダンプデータを作成する。7世代まで。
    		$path = TMP. sprintf('logs/mysqldump/dump_%s.gz', date("w"));
    		$cmd = sprintf("mysqldump -u %s --password='%s' %s --opt | gzip> %s"
    				,$db->config['login']
    				,$db->config['password']
    				,$db->config['database']
    				,$path);
    		system($cmd);
    	}
    }
    

    ためしに、コマンドライン上から
    /var/www/html/myapp/cake/console/cake mysqldump dump -app /var/www/html/myapp/app
    を実行してみましょう。ふおお!指定したフォルダにダンプデータができている…!エクスギアさんのページは日付けごとですが、これを設置して知らんふりしてますと知らないうちにじゃんじゃんデータがたまって大変なことになりますから、私は一日一回、曜日で取得するようにしました。曜日を取得する関数で名前をつけているので、最大7世代のバックアップが存在していることに。まあゆくゆくはもっと壮大なバックアップ計画を立てていますが地道にまずローカルに世代バックアップをとることにします。これをcronに設定しよう!
    上記コマンドを所定の時間に動くようにcrontabに設定して動作確認してちゃんちゃん!

    で、だ。上記はバックアップですが、これバッチも同じだよね…。とふと思って探してみると、あるある、やってる方々が。つまりデータベースそのもののデータを書き換えるバッチも、上記と全く同じようにすることで可能なんですな。

    var $uses = array('Model');//モデル名を設定
    function hogehoge(){
    //バッチ処理
    }
    

    と書くことであらまあ不思議。でこれをまたcronに設定すればバッチ処理のできあがり。まさにクッキングのようだ!

    ところで最近は「こういうことしたいときってみんなどうしてんだろ」という疑問がいろいろ。

    なんていうか、ごり押しでソースかけないことはないけれど、本来のフレームワークとしてスマートな方法だったり、負荷のかからない方法だったりを気にするようになってきました。あと最近の失敗談というか。モデルα内にAとaというフィールドがありました。Aとaが特定の条件の場合、別のβモデルを参照し、bとBの値を計算して、モデルα内で[‘aAndb’]みたいなフィールドを作って返却する、というメソッドを作成し、それをafterfindに設定。つまり返却されてきたαモデルには[‘aAndb’]というフィールドがセットされてかえってくる、というメソッド。ところがこのモデル、アソシエーションがあるため、階層的にいつも同じとは限らない。ということで再起呼び出しをするメソッドになっています。さて、そろそろなんとなく結果がわかったかな?

    そう、あちらこちらで呼ばれていて、かつ再起呼び出しになっているいたため、もんのすごい負荷がかかってページ表示5秒もかかるようになってしまったwww(デバッグレベル0でですよ!)おまけに怖くなったのでデバッグレベル3にしたら「うおおおお」画面真っ白になっちゃったwwwwwwwww笑ってる場合じゃないよ!ギャース!というわけでそんなに見ちゃいや><ということで手直しをすることに。再帰的呼び出しは仕方ないものの、ページ表示時に一度呼ばれたものはクラス変数にセットし、その値を参照することで同じメソッドを何度も呼ばないようにしました。まあ根本的?といわれたちょっと違うのでもうちょっとメンテナンスしないといけません。あと、コントローラーで色々なモデルを参照している場合、たとえば10個のモデルを参照する場合、しょっぱなコントローラーに通ったときにdescribeが大量に呼ばれる。これはすでに回避方法がブログにいろいろ書いてくださっている方がいるのでそちらで対応したいところ。なんていうか、順当にさまよってる感じですねw誰しもが行き着いてるきがするけど・・どうですかね?私だけ?路頭に迷ってる風なのは・・・。

  • フレームワークちょーべんり!
  • さくさくつくれて楽しい!
  • ちょっとまて。例外もあるのでどうすればいい?
  • 痒いところがかけないじゃん><んもう
  • ルールにのらない例外を受け入れよう
  • 速度的に気になるところはクエリを見直そう。
  • 開発ってチームでやってても、孤独感ってあると思うのです。一人でつくって、一人でデバッグ。そういう時に、たとえば勉強会とかで「あるあるーあるある」とか「同じようなことしちゃったことあるよ」とかいう話きくとちょっと、いやだいぶ救われます。低く流れる水のように、下がっていくのはたやすいのです。モチベーションをずっと維持するのは非常に大変なことだと思うのです。単に「開発がすきだから」では先に進めないほど凹むときもあるんじゃないかと。そういうときに、やっぱり同じ開発者と、色々な機会で話ができる環境に身をおくことが自分にとっても必ず+になるんじゃないかな、と思います。まあ、「あるある」といってもらえずに「…え」といわれるリスクもあるわけですけども。。。

    広告
     
    コメントする

    投稿者: : 3月 4, 2010 投稿先 Uncategorized

     

    コメントを残す

    以下に詳細を記入するか、アイコンをクリックしてログインしてください。

    WordPress.com ロゴ

    WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

    Twitter 画像

    Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

    Facebook の写真

    Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

    Google+ フォト

    Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

    %s と連携中

     
    %d人のブロガーが「いいね」をつけました。