はてなブックマーク

以前スレーブ側の更新がとまっていることに気付きました :x001: その時のトラブルシューティングの手順です。 １．スレーブ側で、SlaveS tatusを確認する まずはスレーブの状態を確認し、何が停止しているかをチェックしました。 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.xxx.xxx Master_User: xxx Master_Port: xxx Connect_Retry: 60 Master_Log_File: mysql-bin.000009 ←①スレーブのI/Oスレッドが現在処理中のマスタのバイナ

Usersテーブルにusernameとpasswordを入れて、 チュートリアルにある簡単な認証画面でテストしたのですが、 どうしても認証できません。 データベースはMySQLを使用して、select md5(‘password’)　で取得した値を passwordに入れていました。 デバッグしてみると、auth.phpでSecurity.saltで設定している ランダムの値が使用されていました・・・。 Security.saltの値プラス、フォームのpasswordの値をmd5に変換していたのです。 対応策は、事前に登録する値はselect md5(‘Security.saltの値password’) で登録するか、Cakeでaddするか、以下のように修正するかのようです。 Securityコンポーネントでは、saltを使用するかをtrueかfalseで設定できますが、 肝心の呼び出し元

tcpdumpの基本的な使用方法はこちら ##　名前解決をしない tcpdump -n src 192.168.100.1 and dst 192.168.100.2 ##　インターフェイスを指定する tcpdump -i eth1 ##　特定のホストを除外する tcpdump -i eth0 not host 192.168.100.5 ##　複数ホストを除外する tcpdump -i eth0 not host 192.168.100.5 and not host 192.168.100.6 ##　ネットワークを指定する tcpdump net 192.168.100.0/24 ##　ネットワークを除外する tcpdump not net 192.168.100.0/24 ##　特定ポートを指定する tcpdump -i eth0 not host 192.168.100.5 and

ntpdを起動してもすぐには同期されません。 同期の状態を確認するのに使用するコマンドが ntpq -p です。 # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *ntp-b2.nict.go. .NICT. 1 u 1 64 377 91.074 20.475 82.456 LOCAL(0) .LOCL. 10 l 57 64 377 0.000 0.000 0.001 ntpdを起動したての状態ではまだ同期が始まっていません。 同期が開始されれば、remoteの左に同期しているサーバーに*がつきます。 また、複数設定している場合には、同期可能なサーバー

セッションという日本語のイメージこそ、最も注意すべき点です。 WEBサーバーとブラウザの間には、トンネルのような物理的な接続状態は存在しません。 一回ポッキリのデータのリクエスト・レスポンスしかHTTPには存在しないのです。 Cookieとセッションの違い ID・パスワードなど別の画面に遷移しても必要なデータは多々あります。 こうした場合によく使用されるのが、Cookieやセッションです。 CookieはWEBサーバーが発行し、ブラウザが保持するキーと値です。 ブラウザは同じサイトにアクセスする際にはそのCookieをWEBサーバーに送信します。 WEBサーバーはブラウザからのリクエスト毎にその値を参照することができます。 一方セッションはWEBサーバーで保持するキーと値です。 IDやパスワードなどを毎回ブラウザから送信してはセキュリティ的にも問題です。 ログインアクションにより、WEBサ

データベースやWebサーバーは、実際に稼働してから問題が多発します。 データ量が増えてきたり、アクセスが増えてきたらまずレスポンスの問題が発生するでしょう。 経験のあるエンジニアがいれば、十分なテストを行ってから稼働するわけですが、なかなかそうもいきません。 今回のテーマはMySQLのwait_timeoutの設定です。 なぜハマってしまうかというと、グローバル変数のwait_timeoutがそのまま個々のセッションのwait_timeoutになるとは限らないからです。 結論からいいますと、 プロセス生成時にグローバル変数のinteractive_timeoutかwait_timeout が、セッション変数のwait_timeout に反映されます。 そして、どちらが反映されるかは、mysqlのAPI呼出し時に対話型クライアントの定義かどうかできまります。 MySQLサーバーと、サーバ接続

そもそもこの機能が動作しなくて非常にこまりました。 もしスレーブが認識できないのであれば前回の記事が役に立つかもしれません。 utilitiesのmysqlrplshowを使いたい レプリケーションの目的や構成も様々だと思います。 今回の構成・目標は以下の通りです。 【構成】 Windows8:192.168.0.99。mysqlfailoverを起動する └centos:マスター。192.168.0.100。Windows8上のvmwareで起動 └centos:スレーブ。192.168.0.101。Windows8上のvmwareで起動 MySQLのバージョンは5.6.13。 MySQL Utilities mysqlfailover version 1.2.0 – MySQL Workbench Distribution 5.2.47 【目的】 通常はマスターを使用する。メンテナンス

Windowsを使用するのはグラフィカルで便利な開発環境があるためです。 そしてサーバーとしてのLinuxは秀逸です。 PHPもフリーで簡易ですし、Apache・MySQL・Linuxとの相性も最高です。 しかし多くの場合var_dumpやログでデバッグするハメになり苦労します。 リモートデバッグを行うと、Windows上でLinuxの実環境や開発環境での実行ができるようになります。 この環境を整えるのに恐ろしく苦労したのでここにその記録を残します・・・ :x001: しかし一旦この環境を整えると、ステップ実行や変数の確認が容易になり、 昨今の複雑なフレームワークを理解する上でも大変役に立つこと間違いなしです！ :x002: そもそもPHPをデバッグして、ステップ実行するにはそのままでは無理です。 まずはLinuxサーバー側にxdebugをインストールします。 ZendDebuggerとい

status=’1’とかdelete=’0’といった条件はよく使用することでしょう。 そこでフラグにはどのデータ型がベストなのでしょうか。 フラグにベストなデータ型 考えられるのは tinyint(1) smallint(1) といった数値型。 もしくは char(1) char(3) といった文字型でしょう。 char(3)としたのは、マイナスだってありうるからです。 以下100万件のデータにランダムな10件のstatus=’1’のデータを作成して select id,name,status from test where status=’1′ した結果です。 tinyint(1)の場合 DROP TABLE IF EXISTS `test`.`test`; CREATE TABLE `test`.`test` ( `id` int(10) unsigned NOT NULL AUTO_

Base64は暗号化としてよりも、HTTPでスペースやら記号などやりとりできない文字を置き換えて送受信する場合によく利用されます。 Linuxで簡単に使用できるBase64のエンコードやデコードの方法です。 openssl # echo -n "abc" | openssl enc -base64 YWJj # echo "YWJj" | openssl enc -d -base64; echo abc base64 # echo "abc" | base64 YWJjCg== # echo "YWJjCg==" | base64 -d ;echo abc base64: invalid input ←何故かエラー？ nkf nkfはインストールされていなければ、yumで簡単にインストールできます。 #yum -install nkf # echo "abc" | nkf -MB ;ech