こんにちは。暇ですか?僕もです

暇人インフラエンジニアマン

車売ったら自動車保険の中断証明書をとりましょう

車売りました

車を最近(半年くらい前)売ったんですが、保険が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くらいだっけ?)にひっかかっているわけではない

解決

jira.mongodb.org

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だったのでそのまま実行した

PC-> AWS間のネットワーク的疎通はええ感じにどうぞ

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-engine

昔のdockerの呼び方
使ってる人はアップグレードしてくんろ!って書いてあった
blog.docker.com


# 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-master-ha - MHA for MySQL: Master High Availability Manager and tools for MySQL - Google Project Hosting

MySQLでHAといったらMHAでしょ!的な雰囲気を感じます

 

mysqlfailoverとは

MySQL Utilitiesに入ってるツール。

MySQL :: MySQL Utilities 1.6 Manual :: 5.12 mysqlfailover — Automatic replication health monitoring and failover

 

まず構成

  • 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ですね。

ReleaseNotes - mysql-master-ha - MHA for MySQL: Master High Availability Manager and tools for MySQL - Google Project Hosting

 

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は自動で検出してくれる