Linuxでパッケージを探すときに使うTips
コマンド名やファイル名がわかっていてパッケージ名が分からない時に、以下の方法でパッケージを探すことができます。
yumが使える環境であれば特に準備の必要はありません。
yum provides "*/ファイル名"
yum provides "*bin/コマンド名"
apt-fileがインストールされている必要があります。
sudo aptitude install apt-file sudo apti-file update
apt-file search "ファイル名"
apt-file search "bin/コマンド名"
以上、簡単ですがパッケージを探す際の参考になれば幸いです。
チョコボールakaモリモリ～です。
7月から携帯コンテンツの開発に加わることになりました。
今までは管理画面系が多かったので携帯に関する知識はほとんど無かったのですが、携帯3キャリアに対応していくためのコーディングやセッションの引き回しについてなど、少しずつ覚えてきました。
今回はデータベースについて思うこと…を。
今まではDB操作はずっとphpMyAdminに頼ってたんですが、コンソールを使うようにと指示が出て、最近はひたすらSSHでカタカタとやってます。
慣れてくるとサクサク処理出来て快適ですね。
早いというか、それが通常の処理の早さってことなんでしょうけど。。
個人的に作ってるサイトはSSHが使えないレンタルサーバーなのでDB操作はphpMyAdminを通してやるしかないのが残念です。
自分は業務でデータベース設計をすることはありませんが、実際に使う時のことを考えて、できるだけ複雑なJOINやサブクエリをさせないようにうまいこと設計しないと、のちのちレコードが増えてきた時にパフォーマンスにモロに影響が出る、と実感しました。
あまりにも関連テーブルを分けすぎるとSQL組む時、かなり複雑になります…。
データが1000レコードでSELECT文、オフセット10でデータひっぱってくるのに10秒以上かかる。
こんなシステムに遭遇。。
発行されたSQL文を見てみると、JOIN、サブクエリが複雑に絡み合って恐ろしいことになってました。
一つの複雑なSQL文で全てやろうとするよりもSQLを何回かに分けてプログラム側でごにょごにょやると取り敢えずパフォーマンスは改善しそうな予感です。
今後データベース設計する機会があったら活かせるとよいなーと思います。
こんにちは～！べきこですよ。(´ー｀)
ようやくサーバ側のお仕事に慣れてきました。
インストール時にいろいろ細かい設定するためにシェルスクリプトを使うので、
せっかくだから中身をもっと充実させようと！(そして自分が少しでも楽になろうと・・)
ということでファイル作ったり、移動したり、値変更したり～なものを作ってたのですが、、
mysqlが動きません。。なんで？(´・ω・｀)
検索してて見つけたのが
シェルのオプションにデバッグがあるらしいです
sh -x test.sh
実行コマンドにこのオプションを加えるだけで、実行されたものがすべて表示されます。
cp /home/test/test.php /var/www/test/test.php chmod -R 755 /var/www/test/ chown -R test:test /var/www/test/
こんな感じで、実行したコマンドが表示されます。
このログではあらかじめ指定してあった変数もきちんと表示されているので便利です。
で、結局なんでMySQLが動かなかったのかというと・・・
パスがちゃんと通ってなかったのと、MySQLでは使わないコマンドが途中に入っちゃってたのというわけで・・・
(( ;ﾟдﾟ)ｱﾜﾜ
もっとお勉強してきます・・
新規サービスオープンのため対応中。姜子牙です。
本体のネタ以上にこの冒頭のネタを練りこんでいたりすることがあります。
2/22のエントリでバックアップについて記載しましたが、今回はバックアップ第二弾を書きたいと思います。
さて本題、バックアップは何重に取るべきか？
バックアップの対象となるデータをマスタデータと呼んだ場合、それを一つコピーしてバックアップすると1重とします。
私は基本は2重に取るようにバックアップは設計しています。1重ではやや不安で、3重だと余剰だろうと考えています。
2重の場合、マスタデータ含めて3つ同じデータが存在することとなります。
ここでのポイントは「このバックアップでマスタデータが何個分存在することになるか」です。
よくあるのが、AというディレクトリのデータをBというディレクトリが常に同期していて同じデータが入っているのに
AもBもバックアップに含めてしまう、ということがあります。
これだとマスタデータはAのディレクトリのデータなのに、Bのディレクトリ、Aのバックアップ、Bのバックアップという形で
4つも存在してしまうことになるわけです。
多ければ多いほどデータの消失確率は減りますが、逆にその分ディスク容量を圧迫することになります。
なので、私の場合、上記A・Bのディレクトリがあった場合、Aはバックアップ対象としますが
Bはバックアップ対象から外すように設定をするわけです。
こうするとAディレクトリ、Bディレクトリ、Aのバックアップでマスタデータ3つ分というわけです。
まあ、他の同期していないデータとかと一纏めにする都合でAバックアップのコピーが生まれるので
データ4つになっちゃうんですけどね・・・。
もう少し具体的に言えば
更新系を司るマスタデータベースがあって
それのホットスタンバイであるスレイブデータベースがあって
マスタ・スレイブそれぞれでバックアップ取って
さらにそれぞれのバックアップを2重化したりすると
データ6つ分になっちゃったりするんですよ・・・。
いや、うん直さないといけないですけどね・・・。
やや余談になりますが、
サーバがRAID1の場合、その時点でマスタデータが2重だからバックアップ1個取れば3重と言えなくもないですが、
私個人の考えとしてRAID1でコピーされるデータはバックアップとみなしていません。
あくまで、HDD物理障害対策の機構であって明示的なバックアップではないと考えているからです。
|-’) HDDが無事でもRAIDのカードやチップが往生してしまうこともあるし・・・。
まあ後半はやや個人意見だらけなので、こんなんあるんだ程度としておいて頂いて
バックアップを設計する時は一度マスタデータが何個分になっているか意識してみると良いかもしれません。
[Mr.マカー](#ﾟДﾟ) < 「で、バックアップサーバどうすんの？」
[姜子牙]（;’-') < 「あ、えーと今のサーバのディスク枯渇するまでもうちょい時間あるので検討します・・・。」
[べきこ] (´ー｀) < 「時間経って忘れてると大変なことになりそうだね」
[姜子牙] ∑(；’-') < 「ドキッ」
はい、冗談にならないです。
暑かったり寒かったり雨が降ったり降らなかったり。
皆様いかがお過ごしでしょうか。こんにちわ。かーつんです。
さてさて、今回はなにを書こうか悩んでいたのですが、
良いネタが見つからなかったので、直近のお仕事の様子でも少々。
現在、会員様向けにメール配信を行う用のスクリプトを作ってるんですが、
色々と難航しております。
３つのサーバから１つのDB参照して、同時稼働。
なんか昔バッチ組んでるときに似たようなことしたなぁと思いながら、
正直覚えて無くて、超抜けまくり。
のびーにょ先生に怒られツッコまれながら四苦八苦しております。
で、気をつけるべき点で、残しておきたいと思ったことを以下に記しておきます。
１．コネクション数・SQL発行回数を極限まで減らして一括でデータ取得すると、
同時稼働している３つのサーバに同じデータが取得される可能性がある。
⇒回避策⇒
データテーブルとは別にカウント用のテーブルをテンポラリとして作成して、
取得した件数をそっちに残しておけば、
サーバジョブ起動タイミングを少しずらすだけで異なるデータを一括取得できる。
但し、ジョブを途中で中断したときにデータに不整合が起こるので、
回避策が更に必要。(´･д･｀)
２．MySQLはUPDATEの対象テーブルと、
WHERE句で使用するSELECT（サブクエリ）の対象テーブルが同じだと、
ERROR 1093 (HY000): You can't specify target table ・・・
とかって怒る。
⇒回避策⇒
素直にSQL分けるか、DB変える。
MySQLは少し面倒な処理をさせようとすると、すぐ怒る。。。
Oracleなどは怒られないのにネ・・・。
３．メールが送れなかった場合の処理が必要なら、
メールヘッダのReturn-Pathにエラーメールを送って欲しいアドレスを記載する。
⇒具体的には⇒
mb_send_mail('送信先メールアドレス','タイトル','本文',
メールヘッダ(送信元アドレスとか文字コードとか),
'ヘッダオプション');
⇒⇒⇒ Return-Pathはヘッダオプションに、
‘-f エラーメールを受信したいアドレス’
を書くとよし。
mb_send_mail("hogehoge@hoge.jp","タイトル","本文",
"FROM:hogetyo@hoge.jp \n
Content-Type: text/plain; charset=ISO-2022-JP",
"-f hoge-error@hoge.jp");
こんな感じ。
４．送信間隔を考えないと、携帯キャリアからスパム扱いされる。
⇒回避策⇒
ん～模索中。リアルタイムで調整できると一番良いんだけど・・・。(´･д･｀)
と、まぁ、こんなとこでしょうか。
他にも色々あったような気がするけど、
自身で理解し切れてないことが多いので、
またの機会と言うことで。
でわ、おばかーつんがおおくりしました。