Jmeterはthread group間のグローバルな変数のやりとりができない模様
Jmeter
最近Jmeterを触る機会がありまして(今更)、そのメモ
昔から「負荷試験といえばJmeter」と言われるくらい有名なツールで名前は知ってましたが、全く無縁な状態でした。
リクエスト組み立ててぶん投げるだけ、余裕っしょ〜〜〜って感じで最初は舐めてたんですが、なかなか香ばしい挙動をするみたい
thread group間で変数のやりとりがしたい
あるリクエスト処理した結果(レスポンス)を拾って別のリクエストに渡したいってことをやろうとしていてサンプルを見ながら設定してたんですが一向に値が入らない
よくよく調べてみると変数はthread group内に閉じていて、thread group間で変数をやりとりはできない模様
また、親子関係のthread groupなら変数のやりとりはできるらしい
変数の代わりにプロパティというものを介してやりとりができるみたいでした。ちなみにプロパティが何かはいまだに全くわかってない
処理としてはAの結果を変数に入れてBで取り出してリクエストを組み立てる
- thread group A
- HTTP Request
- Regular Expression Extractor
- JSR223 PostProcessor (*1)
- HTTP Request
- thread group B
- HTTP Request
- JSR223 PreProcessor (*2)
- HTTP Request
JSR223 PreProcessor/PostProcessor
テストの実行前後にスクリプト処理を実行できる代物
Thread Group Aのリクエスト後の結果がExtractor経由でvar(変数)に入ってる前提で、その値をprop(property)に代入(?)
*1の処理
props.put("prop", vars.get("var"))
Thread Group Bではリクエストテスト前にpropAに値が入ってる前提で、その値をvarAに代入(?)
ちなみにここのvarはThread Group Aのvarとは別物。varと言っているが、別に好きな名前で良い。
ただしpropという名前はグローバルでユニークに考える必要がある
*2の処理
vars.put("var", props.get("prop"))
これでThread Group Bで変数が使えるようになります。
めでたし
Nuro光にした。HGWはHG8045Q
憧れのNuro
新居に引っ越したため、お家の回線をNuro(2G)にした キャッシュバックか1年間980円かで迷って980円の方にした。(こっちの方がお得?
開通まで
申し込み〜開通まで非常に長かった・・・
2月:申し込み
3月:宅内工事
4月:屋外工事
電柱にアームつけなあかん、と言われて工事せず(ワイブチ切れ
5月:電柱にアームがつく
6月:開通
HGWはHG8045Q
5月くらい?Nuroまだかな〜ワクワク(イライラ)しながら待ってると、とあるqiitaの記事(リンク切れなので貼らないでおく)を発見。
HG8045Qはipv6 FW未実装とのこと。実際に外からアクセスできるとこまで確認(ぴえん
まじか〜と思いつつ、どうせメッシュWiFi環境にするし間にかますルータがFW対応してればええやろ、までは考えてた
マンションに住んでる人はメッシュにしないだろうし、このルータ当たったら辛そうだね。南無
ということでメッシュルータ来るまで、一旦ipv6は無効にしてipv4オンリーで使用することに
メッシュWiFiルータ【Deco M9 Plus】
2packのやつを購入
ethernet backhaulを有線にするか無線かで迷ったが、有線環境を1から作るより無線で初期費用抑えようと思ってトライバンドのこれにした
デュアルバンドだとメッシュ機自体の通信で本来のスピードが出ないとかなんとか、ということで
www.amazon.co.jp
家が3階建てで、光終端が2階にあるため2階に1つ、1階に1つを配置。
3階はまだ物置みたいな感じなので後々購入する予定。
接続はアプリ経由ですんなり行った。
IPv6設定
色々IPv6の知識が圧倒的に不足してて、試行錯誤した。
tp-linkの公式記事によるとパススルーで繋いでくれや、としか書かれてなくてそれだとFW無効じゃねーか!と。
ということでちょっと調査しつつやってみた結果👇
項目 | 設定値 |
---|---|
IPv6接続タイプ | 動的IP |
IPv6アドレスを取得 | ステートレス(※ステートフルでも大丈夫だった) |
プレフィックス委任 | OFF |
DNSを自動的に取得する | ON |
割り当てタイプ | ND Proxy |
この設定自体はこれで決まり!というわけではなくて上位ルータに依存する。
FWを有効にするには動的IPが必須で、さらにミソはND Proxyにすること。ND Proxyにすると上位ルータと同じ設定でIPv6の設定を行う
あとステートフル/ステートレスに関してはよくわかってない。のでもうちょっと調べたい
技術的な話だとRA(Route Advertizement)とDHCPv6が関わってくるところっぽい。ネットワークわからない。
これで割とセキュアにIPv6設定できた。(外部からアクセスできないことを確認
あとは外からアクセスさせたいところだけ穴あけすればおkかな。
って感じで一件落着したかに見えた
が一つ問題があって、これだとAndroid系のデバイスはIPv6有効にならないってこと。
なぜかAndroidはIPv6有効にならないンゴ
MacとかiPhoneはこれでIPv6有効になってるんだけど、なぜかAndroidは有効にならない
理由はちょっと触れたDHCPv6がらみの話なんだが、AndroidはDHCPv6に未対応とのこと。
設定でうまく有効にできないかなと思って、HG8045Qもdeco M9 Plusも色々試したがまだできてない。
ここに関してはわかったらまた追記する
まとめ
とりあえずネット環境がようやく落ち着いた
やっぱりNuroは速かったので満足
無線、deco挟んでも挟まなくてもこれくらい
どっかの記事でHG8045Qだと電波悪いし速度出ねーとか行ってる人もいたけど、絶対それ おま環 としかw
それでは。
車売ったら自動車保険の中断証明書をとりましょう
車売りました
車を最近(半年くらい前)売ったんですが、保険が5月更新なもので、最近保険会社から継続確認依頼が来てまして
あぁ〜解約しなきゃなぁと思いつつ、ふと気づいたんですが
あれ?また車買う時等級どうなるの?また振り出しなんてことないよねぇ
と思って調べたところ、どうやら中断証明書なるものを取得していれば、10年以内であれば等級が引き継げるらしい。
早速解約
解約手続き+中断証明書の申請ポチー
Ω「残りの保険期間の保険料を返還するよ。振込口座は?」
えっっ、お金帰ってくるの!?じゃぁ売った時すぐに解約しておけば半額くらい戻ってたやんけ、、、 もったいな、、、
と悲しい気持ちになりながらも、雀の涙程度のお金のために振込先を入力し次へ
Ω「中断証明書発行するんで、必要書類送ってね!」
まぁそうやな。書類必要やもんな。どこにしまったやろか(ゴソゴソ
・・・
・・・
…
ない。
無いやんけ〜
書類捨てた?終わったか?
またもや悲しい気持ちになっていたんですが、よく見たところ売った時の車検証あれば、それでもOKぽい。 車検証の写真はあるンゴ!と思い、ケータイの写真フォルダを漁って無事発見。
送信して返答まち。
中断証明書もらえるといいなぁ
結果はまた後日。
まとめ
売ったらすぐ自動車保険解約
売った時の書類は捨てない。車検証の写しは残しておく。
追記
やっぱり車検証だとダメだった あきらめ~
追追記
やさしいおにーさんが電話かけてきてくれて、わざわざ売却した店に確認とってくれたみたいで、証明書取得できました
MongoDBがtoo many connectionsで暴走した
最近MongoDBのLAがぶち上がりでパフォーマンスが不安定だったので、脳死でshard増やす前に調べてみた
現象
- LAぶち上がりのタイミングは不定期
- いわゆるユーザのアクセスが増える夕方とかに連動、というわけではない
- 確かにops/data sizeは以前と比較して増えてるが、特定のqueryがトリガーになってるわけではない
- IOスループット各種が軒並み落ちてる
- CPUは特に使ってない
- primary shardが瀕死
- sharding忘れではない
- chunkの偏りもない
- 他のrsも若干不安定
- connectionが増えてる
- 通常の3倍以上
- limit(デフォ 60000くらいだっけ?)にひっかかっているわけではない
解決
issueとバージョンは違うけど、これが怪しそうだっていうことで、mongosの再起動とprimary shardのrsを切替
今の所は落ち着いている
時限爆弾っぽいので覚えておこう
redisをAWS ElastiCacheに移行した
オンプレredisに乗ってるデータをAWSに移行した時のメモ ※redis初心者です
- redisはnot cluster
- 一部のデータベースのデータのみ移行
- ttl含む
- 参考(↓) stackoverflow.com
手元のPC(mac)を経由して移行
A(オンプレ) -> PC -> B(AWS)
#!/bin/bash source_host=A source_port=6379 source_db=1 target_host=B target_port=6379 target_db=1 redis-cli -h $source_host -p $source_port -n $source_db keys \* | while read key do ttlmilli=$(( $(redis-cli -h $source_host -p $source_port -n $source_db ttl "$key")*1000 )) redis-cli --raw -h $source_host -p $source_port -n $source_db DUMP "$key"| /usr/local/opt/coreutils/libexec/gnubin/head -c-1| redis-cli -x -h $target_host -p $target_port -n $target_db RESTORE "$key" "$ttlmilli" done
この方法だとttlが無限だとエラーになるのでよしなに
僕の場合は、無限のものは無視してOKだったのでそのまま実行した
macのheadコマンドとgnu版でオプションが違ったのでgnu版をインストールするのぢゃ
- ループ回数がエグくて時間かかった
- 僕の場合、valが文字列だったので、わざわざdumpしなくても良く、一度コマンドリスト作ってから実行すればもっと早く終わったなぁと思った
- 移行終わってからmigrateコマンドがあることを知った
docker-engine、docker-ce、docker.ioの違い
最近dockerさわり始めました。
インストールガイドに沿ってdocker環境整えたあとに気づいた。
なんかいろいろパッケージあるけどなんなんですか
- docker-ce
- docker-engine
- docker.io
ケツロンは全部同じなのかな?
# docker-ce
今のdockerの呼び方(docker-eeとかエンタープライズ版もある)
# docker.io
ubuntuがメンテしているdockerのパッケージ名
らしいっす
ワイと同じ疑問を持った人がおった
What is the difference between docker-engine and docker.io packages? - Quora
MySQL5.7でMHAとmysqlfailover試した
どうも@No_oLimitsです。
この記事はCyberAgent Developers Advent Calendar 2016 - Adventarの16日目の記事です。
最近CyberAgentに転職してMySQL触るようになったので、タイトルの通り検証的なものを書きたいと思います。
それでは早速行きましょう
MHAとは
MySQLのHA化できる、すごい人が作ったすごいツールです。
MySQLでHAといったらMHAでしょ!的な雰囲気を感じます
mysqlfailoverとは
MySQL Utilitiesに入ってるツール。
まず構成
- CentOS6
- MySQL5.7でGTIDレプリケーション
- マスター1つとスレーブ2つ用意、フェイルオーバ管理してくれるサーバ1つ
サーバ | 役割 | IP |
ohara-mysql-1 | クライアント、MHA manager | xxx.xxx.xxx.52 |
ohara-mysql-2 | レプリケーション用 | xxx.xxx.xxx.53 |
ohara-mysql-3 | レプリケーション用 | xxx.xxx.xxx.54 |
ohara-mysql-4 | レプリケーション用 | xxx.xxx.xxx.55 |
GTIDレプリケーションの設定は以下を参考にしました。
http://downloads.mysql.com/presentations/20151207_02_MySQL_Replication_for_Beginners.pdf
MHA試す
手順は、、、いろんな人がMHA組んでるので割愛
バージョンは0.56使いました
とりあえずmasterをkillしてみましょう
結果
----- Failover Report -----
mha: MySQL Master failover xxx.xxx.xxx.53(xxx.xxx.xxx.53:3306) to xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306) succeeded
Master xxx.xxx.xxx.53(xxx.xxx.xxx.53:3306) is down!
Check MHA Manager logs at ohara-mysql-1:/var/log/mha/mha.log for details.
Started automated(non-interactive) failover.
Invalidated master IP address on xxx.xxx.xxx.53(xxx.xxx.xxx.53:3306)
Selected xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306) as a new master.
xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306): OK: Applying all logs succeeded.
xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306): OK: Activated master IP address.
xxx.xxx.xxx.54(xxx.xxx.xxx.54:3306): OK: Slave started, replicating from xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306)
xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306): Resetting slave info succeeded.
Master failover to xxx.xxx.xxx.55(xxx.xxx.xxx.55:3306) completed successfully.
うまくfailoverしたみたいです。
MHA公式のリリースノート見てみたら0.56からMySQL5.6 GTID対応済みのようです。
5.7も動作OKですね。
mysqlfailover試す
本命はここからです。
以下サクッと手順
// MySQL Utilitiesインストール
yum install mysql-utilities
// failover用mysqlユーザ作成
create user failover@'%' identified by 'failover';
grant all on *.* to 'failover'@'%' with grant option;
設定簡単ですね
utilitiesはクライアント用のサーバに入れます。1.6.4を使用
failoverユーザをクライアントサーバからアクセスできるようにします。
アクセス制限の所は今回適当です。
権限はgrant option付きでallが必要みたいです
mysqlfailover起動
mysqlfailover --daemon=start --master=failover:failover@'xxx.xxx.xxx.55' --discover-slaves-login=failover:failover --log=/tmp/mysqlfailover.log --force
さてkillしてみます
結果
Failover starting in 'auto' mode...
# Candidate slave xxx.xxx.xxx.53:3306 will become the new master.
# Checking slaves status (before failover).
# Preparing candidate for failover.
# Creating replication user if it does not exist.
# Stopping slaves.
# Performing STOP on all slaves.
# Switching slaves to new master.
ERROR: Slave xxx.xxx.xxx.xxx.54:3306 change master failed. Error performing commit: 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active.
あれ・・・
MASTER_AUTO_POSTION設定してると上記のchange master文はエラーのようです
おかしくない・・・?
GTIDでレプリしてるから、MASTER_AUTO_POSITION設定するでしょ。
何かがおかしい
調べても有用な情報見つからず、一旦諦めてMySQL5.6で試してみることに
INFO Master may be down. Waiting for 3 seconds.
INFO Failed to reconnect to the master after 3 attemps.
CRITICAL Master is confirmed to be down or unreachable.
INFO Failover starting in 'auto' mode...
INFO Checking eligibility of slave xxx.xxx.xxx.54:3306 for candidate.
INFO GTID_MODE=ON ... Ok
INFO Replication user exists ... Ok
INFO Candidate slave xxx.xxx.xxx.54:3306 will become the new master.
INFO Checking slaves status (before failover).
INFO Preparing candidate for failover.
INFO Reading events in relay log for slave xxx.xxx.xxx.54:3306
INFO Creating replication user if it does not exist.
INFO Stopping slaves.
INFO Performing STOP on all slaves.
WARNING Executing stop on slave xxx.xxx.xxx.54:3306 WARN - slave is not configured with this master
INFO Executing stop on slave xxx.xxx.xxx.54:3306 Ok
INFO Switching slaves to new master.
INFO Disconnecting new master as slave.
INFO Execute on xxx.xxx.xxx.54:3306: RESET SLAVE ALL
INFO Starting slaves.
INFO Performing START on all slaves.
INFO Checking slaves for errors.
INFO Failover complete.
INFO Discovering slaves for master at xxx.xxx.xxx.54:3306
動いた(^^;)
まとめ
- MySQL5.7 GTIDでMHA 0.56+は動作する
- MySQL5.7 GTIDでmysqlfailover(MySQL Utilities 1.6.4)は動作しない要調査
- MySQL5.6 GTIDでmysqlfailover(MySQL Utilities 1.6.4)は動作する
個人的にmysqlfailover悪くないと思った
- MHAのようにmha-nodeエージェントみたいなのを入れなくて良い
- sshノンパス設定いらない
- slaveの分だけ無限にfailoverしてくれる(MHAは一度failoverするとmanagerプロセスが落ちる)
- slaveは自動で検出してくれる