- 12/04 [PR]
- 11/08 NAT越しにMySQLでレプリケーションすると接続が切れる
- 11/07 Fedora19のコンソール設定
- 12/27 Glassfishインスタンスリソース監視テンプレ
- 12/07 systemctlによるサービス管理でつまづいた
- 09/28 ZABBIXとnscd
Title list of this page
DCとAWS間で、MySQLのレプリケーションを試してみたら、レプリケーションがうまくいかなかった。無通信状態が1時間続くと接続がきれてしまいます。
現象発生時にマスター側、スレーブ側で以下のような確認をしましたが、正常そうに見えました。
・この時 スレーブ側でshow slave statusを実行すると、IOスレッドの稼働状況はYesになっている。
・両方でnetstat -atnを実行すると、スレーブ側ではEstablishedになっているが、マスター側には対応するセッションがない。
最後のnetstatsの結果から途中経路にあるNW機器が原因かと辺りをつけて、両方のMySQLサーバでパケットキャプチャしてみると、30分おきにマスターから スレーブに対してpushフラグのついたパケットが投げられていましたが、途中経路にあるYamaha RTX1200がリセットフラグのついた応答を返していました。
どうやら、RTX1200のNatテーブル保持期間がデフォルトで900秒だったため、Natテーブルからレコードが消えていたため通信に失敗していました。
このため、マスターからスレーブへパケットを投げる間隔を60秒にしてやったところ、問題は解決しました。
変更するためには、 スレーブ側で以下のコマンドを実行します。
現象発生時にマスター側、スレーブ側で以下のような確認をしましたが、正常そうに見えました。
確認内容
・マスター側でshow slave hostsを実行すると、1時間経過した時点でエントリーが消える。・この時 スレーブ側でshow slave statusを実行すると、IOスレッドの稼働状況はYesになっている。
・両方でnetstat -atnを実行すると、スレーブ側ではEstablishedになっているが、マスター側には対応するセッションがない。
最後のnetstatsの結果から途中経路にあるNW機器が原因かと辺りをつけて、両方のMySQLサーバでパケットキャプチャしてみると、30分おきにマスターから スレーブに対してpushフラグのついたパケットが投げられていましたが、途中経路にあるYamaha RTX1200がリセットフラグのついた応答を返していました。
どうやら、RTX1200のNatテーブル保持期間がデフォルトで900秒だったため、Natテーブルからレコードが消えていたため通信に失敗していました。
このため、マスターからスレーブへパケットを投げる間隔を60秒にしてやったところ、問題は解決しました。
変更するためには、 スレーブ側で以下のコマンドを実行します。
mysql> change master to MASTER_HEARTBEAT_PERIOD=60;
PR
Fedora19をvirt-installでKVM上にインストールしたら、コンソールが表示されなかった。しかもgrub2に代わってコンソール設定も迷ったので対処方法のメモ。
(1)/etc/default/grubに以下の行を追加する。
(1)/etc/default/grubに以下の行を追加する。
GRUB_TERMINAL_OUTPUT=serial GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"(2)grub.cfgの再作成
# grub2-mkconfig -o /boot/grub2/grub.cfgGRUB_TERMINAL_OUTPUTがないと、シリアルに関する設定がgrub.cfgに入らないところで、少し戸惑った。
今までTomcatを複数台用意して運用していましたが、はっきりいって管理が面倒でした。
そこで代替品を探していたら、Glassfishというフリーのアプリケーションサーバに出会いました。
こいつがまた、管理用Webから一元管理ができて、クラスターの拡張も簡単という、とてもイカす奴でした。
運用するからには監視が必要ということで、ZabbixでGlassfishクラスタの各インスタンスのリソース監視をするためのPythonスクリプトを作りました。
これ → zabbix_server.tgz
【環境】
・監視サーバ Zabbix 1.8系
・監視対象 CentOS6 Python2.6系 Zabbix 1.8系(Zabbix-JP配布のRPM)
■Glassfish管理ノード側作業
(1)pythonスクリプトをGlassfish管理ノードに配置する。
配置先 /etc/zabbix/customscripts/glassfish_monitor.py
実行権限をつけ忘れないように。
(2)pythonスクリプトの編集
・das_userにDASのログインユーザ、パスワードを記述する。
デフォルトだと、admin:admin
・zabbix_serverにZabbixサーバのDNS名を記述する。
(3)userparameter_glassfish.confを/etc/zabbix/zabbix_agentd.dに配置し、zabbix_agenを再起動する。
■Zabbixサーバ側作業
(1)テンプレートをZabbixサーバにインポートする。
(2)監視したいインスタンス(Javaプロセスのこと)をZabbixサーバに登録する。
登録する際、以下のように入力する。
DNS名:Glassfish DASのサーバ名
接続方法:DNS名
マクロ:{$node} => インスタンス名 (クラスタに定義されているインスタンス名)
JDKのバージョンによって、GCの種類が変わってくるので、スクリプト中の以下の箇所を編集する必要があるかもしれません。
そこで代替品を探していたら、Glassfishというフリーのアプリケーションサーバに出会いました。
こいつがまた、管理用Webから一元管理ができて、クラスターの拡張も簡単という、とてもイカす奴でした。
運用するからには監視が必要ということで、ZabbixでGlassfishクラスタの各インスタンスのリソース監視をするためのPythonスクリプトを作りました。
これ → zabbix_server.tgz
【環境】
・監視サーバ Zabbix 1.8系
・監視対象 CentOS6 Python2.6系 Zabbix 1.8系(Zabbix-JP配布のRPM)
使用方法
■Glassfish管理ノード側作業
(1)pythonスクリプトをGlassfish管理ノードに配置する。
配置先 /etc/zabbix/customscripts/glassfish_monitor.py
実行権限をつけ忘れないように。
(2)pythonスクリプトの編集
・das_userにDASのログインユーザ、パスワードを記述する。
デフォルトだと、admin:admin
・zabbix_serverにZabbixサーバのDNS名を記述する。
(3)userparameter_glassfish.confを/etc/zabbix/zabbix_agentd.dに配置し、zabbix_agenを再起動する。
■Zabbixサーバ側作業
(1)テンプレートをZabbixサーバにインポートする。
(2)監視したいインスタンス(Javaプロセスのこと)をZabbixサーバに登録する。
登録する際、以下のように入力する。
DNS名:Glassfish DASのサーバ名
接続方法:DNS名
マクロ:{$node} => インスタンス名 (クラスタに定義されているインスタンス名)
JDKのバージョンによって、GCの種類が変わってくるので、スクリプト中の以下の箇所を編集する必要があるかもしれません。
menu={"os":"/jvm/operating-system","compiler":"/jvm/compilation-system","runtime":"/jvm/runtime","thread":"/jvm/thread-system","memory":"/jvm/memory","majorgc":"/jvm/garbage-collectors/PS%20MarkSweep","minorgc":"/jvm/garbage-collectors/PS%20Scavenge","class":"/jvm/class-loading-system"}GlassfishのRESTチャネルを使って値をとってきているので、https://hoge.glassfish.manage.server:4848/monitoring/domain/ にブラウザでアクセスすれば何に変更すればいいかわかると思います。
仕事で使ってるサーバの大半はCentOSなんですが、たまにFedoraが混じってたりします。
Fedoraの場合、サービス管理にはsystemdを経由しますが、こいつがたまに思った通りに動いてくれません。
CentOS用に作ったkyototycoonのRPMパッケージを、Fedora用にパッケージし直し、いざ起動するとすぐ停止してしまいます。
kyototycoonのログを見ると、起動した形跡はあるが、直後にシャットダウンされている模様。
起動直後に、ステータスみると確かに殺されている。
とりあえず回避方法として、systedを経由せずに起動させています。
やり方は簡単で、起動スクリプト中に以下のシェル変数を定義すればOKです。
【変数】
SYSTEMCTL_SKIP_REDIRECT=yes
値は便宜上yesにしましたが、何でもOKです。
Fedoraの場合、サービス管理にはsystemdを経由しますが、こいつがたまに思った通りに動いてくれません。
CentOS用に作ったkyototycoonのRPMパッケージを、Fedora用にパッケージし直し、いざ起動するとすぐ停止してしまいます。
kyototycoonのログを見ると、起動した形跡はあるが、直後にシャットダウンされている模様。
起動直後に、ステータスみると確かに殺されている。
# /etc/init.d/ktserver status ktserver.service - LSB: KyotoTycoon Server Loaded: loaded (/etc/rc.d/init.d/ktserver) Active: deactivating (stop) since Fri, 07 Dec 2012 12:03:05 +0900; 1s ago Process: 32573 ExecStart=/etc/rc.d/init.d/ktserver start (code=exited, status=0/SUCCESS) Main PID: 32578 (code=exited, status=0/SUCCESS); Control: 32581 (ktserver) CGroup: name=systemd:/system/ktserver.service t 32580 /usr/bin/ktserver -port 1978 -dmn -li -log /var/log/ktserver.log -pid /var/run/ktserver.pid -th 64 -sid 2 -mhost taudience01.hogehoge.com -mport 1978 -rts /data/ktser... t 32581 /bin/bash /etc/rc.d/init.d/ktserver stop m 32650 sleep 1同じパッケージを入れている別のサーバではおきなかったりして、今のところ原因不明です。
とりあえず回避方法として、systedを経由せずに起動させています。
やり方は簡単で、起動スクリプト中に以下のシェル変数を定義すればOKです。
【変数】
SYSTEMCTL_SKIP_REDIRECT=yes
値は便宜上yesにしましたが、何でもOKです。
ブログ内検索
カテゴリー
最新記事
(11/08)
(11/07)
(12/27)
(12/07)
(09/28)
最新トラックバック
プロフィール
HN:
アフロ
性別:
非公開
リコメンド