komiyay

komi

サーバインフラ系主婦です。 さいきんわりとqiitaに書いてます。
  • mysqlfailoverをデーモンになってから試してみた

    ※ 古い記事ですのでご注意ください。

    こんにちは。小宮です。

    まだ使いたい人がいるかわかりませんが検証してみましたので載せておきます。
    長い記事になりますのでお時間のあるときにどうぞ。

    mysqlfailoverを–forceつけず–daemon=startで起動させる

    以前検証したときは
     –forceつけないと動かなかったのと
     デーモンで起動させるオプションは存在しなかった
    というわけでそこを再度たしかめてみます。

    ・構成:

    192.168.1.133   komiya-test-mysql01 my1
    192.168.1.155   komiya-test-mysql02 my2
    192.168.1.150   komiya-test-mysql03 my3
    192.168.1.241   komiya-test-mysql04 my4 manager
    192.168.1.222   vip
    

    ・インストール:
    パッケージは公式とかこのへんからダウンロードできます。
    とりあえずchefでmysql5.6とutility等を入れておきました。
    ssh-copy-idとknife solo prepareして
    nodeファイルのrunlistにdbロール指定して
    knife solo cookしただけで以下と必要な設定ファイルが置かれて
    server_idとかreport_hostとか自動的に入るようにしました。
    参考にしたレシピはこちら

    以下が関連パッケージです。
    mysql-utilitiesはpythonで書かれたツールなのでmysql-connector-pythonが必要です。

    $ rpm -qa|grep -i mysql
    MySQL-shared-compat-5.6.15-1.linux_glibc2.5.x86_64
    MySQL-test-5.6.15-1.linux_glibc2.5.x86_64
    perl-DBD-MySQL-4.013-3.el6.x86_64
    mysql-utilities-1.4.1-1.el6.noarch
    mysqltuner-1.1.1-1.el6.noarch
    MySQL-client-5.6.15-1.linux_glibc2.5.x86_64
    MySQL-server-5.6.15-1.linux_glibc2.5.x86_64
    MySQL-devel-5.6.15-1.linux_glibc2.5.x86_64
    mysql-connector-python-1.1.4-1.el6.noarch
    mysqlreport-3.5-4.el6.noarch
    

    ・replicaitonを組む
    server_idはipアドレスの第4オクテットにしたので重複しないはず。
    report_hostも自分のIPに自動的になってるはず。

    ...
  • chef-soloのレシピのカスタマイズの記録

    こんにちは。小宮です。
    おかげ様でカスタマイズする機会があったため、その一部を引用してご紹介いたします。

    基本的なことなどは、
    以下のリンクや「入門chef-solo」その落ち穂拾いもご覧になるとよいと思います。
    Chef Soloと Knife Soloでの ニコニコサーバー構築 (2) 〜導入編〜:dwango エンジニア ブロマガ
    chef-solo - Chefを読んで実行するための全知識 - Qiita
    DevOpsを実現するChef活用テクニック // Speaker Deck
    あとGW前後にchef実践入門的な書籍をエンジンヤード(chefが出る前から8年くらい使ってる会社)の御方が出されるそうで大変期待してるところです。

    chefのnode、role、enviroment、attribute、data_bagsの解説になります。
    この記事は基本の説明とカスタマイズの為の簡単な情報提供になるかと思います。
    以下に記載しているレシピを実際ためした環境はCentOS6.4のみで、申し訳ありませんが異なる環境での動作保障はできないです。
    異なるOS間の動作保障するような汎用的(複雑)なレシピはopscodeコミュニティの☆がいっぱいついてるクックブックを使えばいいらしいです。
    (余計なものを極力入れないとか既存の環境または手順をレシピ化するという需要には不向きかとは思います。)

    chefリポジトリ直下のディレクトリの解説を以下に記します。
      cookbooks :サードパーティのクックブック置き場
     data_bags :data_bagsのデータ置き場
     environments :環境設定ファイル置き場
     nodes :ノード(ホスト・各サーバ)設定ファイル置き場
     roles :役割設定ファイル置き場
     site-cookbooks :自作クックブック置き場(クックブックはレシピ、配布ファイル等を含む)

    各用語を以下に軽く解説します。
    ・ohai
    chefに同梱されているレシピを適用するホストの情報を取得するコマンドです。
    ohaiで取得した値に基づいてattributeを定義することが可能です。
    たとえばOS搭載メモリやCPUコア数に応じて設定値を変えたい場合やホスト名や
    IPアドレスなど固有の情報を設定ファイルに載せたい場合などに利用すると便利です。

    ・node
    nodesディレクトリ直下にhostname.jsonまたはipaddress.jsonというファイルを置き、
    そこにそのサーバ固有の設定値(attribure)や割り当てる役割(role)を定義します。

    ・role
    dbやwebなど、同じ役割のサーバをroleでまとめ、同じ役割のサーバ群に適用するレシピ
    やパラメータをまとめて定義します。

    ...
  • AMIのバックアップをawscliで自動でとる

    こんにちは。OPSのほうの小宮です。

    どうも社内で需要があるようだったのと、
    javaよりpythonのツールが早いということで検索したけどawscliのは見つからなかったのでつくりました。
    タグでとるとらない自動判定などはしておりません。bkup_numに世代数を指定すると複数世代とれるように直しました。
    引数1にインスタンスID、引数2にホスト名を指定して実行する仕様です。
    --no-rebootを付けてあるので稼働中のインスタンスが再起動されることはありません。
    データ領域のEBSがあってもamiコマンドが勝手に複数とってくれるようだったので、
    osデバイスかdataデバイスか判定してわかりやすいタグつけるようにしてみました。

    ※※要注意※※
    --no-rebootつけてAMIを取得する対象がMyISAMストレージエンジンのmysqlのDBサーバだった場合に、データが壊れて止まるという現象が発生しました。
    InnoDBじゃない場合にどうしてもAMI取得したい時はメンテ推奨で止めてやるのがよいかと思われます。
    ※AWSでは無停止でのAMI取得に関するデータの整合性は保証しておりません。
     参考URL:http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html
    ということはストレージ系のサーバは気をつけたほうがよい(メンテ推奨)ようです。

    ・awscliが入ってなければインストールする
    入れ方参考:(入ってない場合はpip install awscliとする。pipはeasy_installで入れる)
    AWS Command Line Tool Python版 | Developers.IO
    pythonでeasy_install - ハネ@日記
    AWS Command Line Interface(awscli)を使ってみた - 元RX-7乗りの適当な日々

    スクリプトから呼ぶAWSのアクセスキーとリージョンの設定ファイルを作っておきます。
    [shell]# cat /root/.ec2/aws.config ———— [default] aws_access_key_id=<アクセスキーID> aws_secret_access_key=<シークレットアクセスキーID> region=ap-northeast-1 ————[/shell]
    ・コマンドの調査(いちおう載せておきます)
    [shell]# aws ec2 copy-image help ———— copy-image DESCRIPTION Initiates the copy of an AMI from the specified source region to the region in which the request was made. リージョン間コピーなのでいま要らない。 ———— create-image Creates an Amazon EBS-backed AMI from an Amazon EBS-backed instance that is either running or stopped. create-image [–dry-run | –no-dry-run] –instance-id –name [–description ] [–no-reboot | –reboot] [–block-device-mappings ] Command:

    ...
  • redisのソースインストール(chef-solo)

    こんにちは。opsのほうの小宮です。
    redisのソースインストールをご依頼いただきCHEF-SOLOったのでその記録をのこしておきます。

    ★要件
    バージョンについては2.8.4でお願いします。(2014/1時点で最新のソース)

    ★以下作業
    ・rpmで入るバージョンの確認(※同環境のサーバでyumで確認)
    redis.x86_64 0:2.4.10-1.el6

    ※要件に合わないためソースインストールする必要がある

    ・chef-soloの下準備

    [shell]$ ssh-copy-id -i ~/.ssh/id_dsa.pub server2 $ ssh-copy-id -i ~/.ssh/id_dsa.pub server1

    $ knife solo prepare server1 $ knife solo prepare server2[/shell]

    ・role作成
    [shell]$ vi roles/rankingAPI.json { “name”:“rankingAPI”, “chef_type”: “role”, “json_class”:“Chef::Role”, “default_attributes”:{ “base_setting”: { “swappiness”: “0”, “tcp_tw_reuse”: “0”, “tcp_tw_recycle”: “0”, “tcp_fin_timeout”: “10”, “tcp_max_syn_backlog”: “8192”, “somaxconn”: “8192”, “ntpserver1”: “ntp.nict.jp” } }, “override_attributes”:{}, “description”:“rankingAPI’s role”, “run_list”: [ “recipe[roles::rankingAPI]” ] }

    ...
  • cpuコア数に応じたrps_cpusに入れる値の計算方法

    こんにちは。OPSのほうの小宮です。
    cpuコア数に応じたrps_cpusに入れる値の計算方法です。

    ネットワークの割り込み処理を複数コアに分散したいという要望がありまして。(特にキャッシュサーバ)

    できる人に頼って、ここ↓まで頑張ってもらいました。

    [shell]# core=1 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ 1 # core=2 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ 3 # core=4 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ f # core=5 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ 1f[/shell]

    ...
  • MySQLでALTER TABLEでINDEXを作成するときの注意事項

    こんにちは。Ops側の小宮です。
    ある日朝来たら突然開発の方から相談いただいたので、後のために記録しておこうと思います。

    相談内容:
    jenkinsで本番デプロイを行ったが、処理を途中停止した。
    (CakeのDBマイグレーションスクリプトでデプロイした)
    KEYカラムにINDEXをはろうとしたがDBの応答がなくなり接続できなくなった。
    結果としてテーブルが破損したためRDSの時刻指定してロールバックする機能を用いた。
    (ALTERが終わってたかどうかとかはロールバックしたので不明)
    同じレコード数の試験環境で同じ操作をしたら特に異常なくすんなり終わった。
    もう一回同じことを本番でやりたいけどどうしましょう。
    MySQLのバージョンは5.5.27。

    私の個人的認識:
    普通、ALTERする時はロックがかかるから、
    事前に同じ構成と件数の試験環境でかかる時間を見積もってから
    その時間サービス止めてメンテ入れるべきです。
    (※5.5まで。5.6から一部のALTERはオンラインで大丈夫になったようです。)
    sorry表示に切り替えて更新のない環境でやってみましょう。
    (既存のELBの下のwebを全部はずして、別のサブドメインのwebにvhost切ってsorryコンテンツおいてELBに入れるとか)
    途中で強制終了とかするとMyISAMだとテーブル壊れやすそう。
    show full processlist;で現在のクエリとかかってる時間は見ることができる
    けどkillするのは最終手段かと。

    alter table mysqlとか、それプラス5.6とかでググると色々わかります。

    sh2さんのブログを見ると、以下のように書かれています。
    MySQLでALTER TABLE文の進捗状況を確認する - SH2の日記
    -————— MySQLでは
    変更後の定義にもとづく作業用テーブルを作成し、
    変更前のテーブルから作業用テーブルへデータをコピーして、
    最後に二つのテーブルを入れ替えるという仕組みになっています。
    テーブルへのインデックス追加についても、現在のところ大半の
    ケースで内部的にALTER TABLE文が実行されています。

    どこまですすんでるのか確認する方法:
    SHOW GLOBAL STATUS LIKE ‘Handler_write’;
    作業開始前にHandler_writeの値と対象テーブルのレコード件数を控えておけば、
    どこまで処理が進んだのかを確認することができるのです。

    InnoDBならinnotopをつかうと、row operationsのビューにズバリIns/Secがあるので、
    同様にしてALTER TABLEの完了予想が立てられますね。
    差を自分で計算しなくてもいいし、標準的なツールなので便利
    -—————

    ...
  • natインスタンスの冗長化

    こんにちは。プラットフォームの小宮です。

    他を冗長化してもnatインスタンスを冗長化してないと、
    プライベートセグメントでHAしてるサーバ達がAWSのAPIサーバと通信できなくなって詰むなあと思いまして、
    先人の皆さまの記事を参考にして以下のとおりにしました。

    **・なんとなくどうするか検討
    **

    AmazonLinuxで作っちゃったので、たぶんHeartbeatとか入れづらいし、そもそもheartbaet使う必要ない気がする。
    待機系から監視してaws的にルーティングテーブル挿げ替えるだけでよさそう。

    待機系natインスタンスについて、
     作成しておかないと作成と起動とルーティングテーブル作るところもやらないといけないので切替時間が長くなる。
     インスタンス代がかかるけど起動もしたままがいいと思われ。

    **・とりあえず既存のAmazonLinuxのNATインスタンスの設定をいじるところから
    **
    sudoできるようにしてみる

    # usermod -G wheel user-op
    # id user-op
    uid=500(user-op) gid=501(user-op) groups=501(user-op),10(wheel)
    # visudo
    %wheel  ALL=(ALL)       ALL
    

    コメントはずす。
    他のインスタンスから渡ってsudoできるか確認する

    あとnatインスタンスにpythonのツール入れておく

    メール送信も設定
    AmazonLinuxではsendmailが動いてる模様だった。

    vi /etc/mail/submit.cf
    D{MTAHost}[172.18.10.22]
    Djnat01.hoge.com    ※nat02はそう変える
    service sendmail stop
    chkconfig sendmail off
    yum install mailx
    echo hoge |mail -s testkomi komiyay@xxxxx
    

    ロケールを合わせる

    ...
  • AWS(VPC)上でheartbeat3でlvsを構成する話

    ※1年以上前の旧い記事なのでご注意ください。※

    こんにちは。プラットフォームの小宮です。

    今回は、ELBは高いのでスモールスタートだからLVSを構築しましょうという趣旨ですすめた記録です。 最初に書くのもなんですが、LVSでWEBもDBも負荷分散しちゃおうぜということだったんですが、結果的にはWEB側はやっぱELBにという話になりました。 (公私混同フラットNWであることを顧客に説明するのが大変だという話とSSLとかスケールとか運用の利便性等で。)

    普段よりは気をつける点: ・環境がAWS(インスタンスを気軽に作り直してChange Source/Dest CheckをDisableにし忘れる等に要注意) ・クライアントがグローバル越しだとDSRできない(エッジルータでENIとIPが合わないパケットが破棄される) ・フラットなNW構成でないとDSRできない(これは普段通りだけど気をつけるポイント) ・複数NWでNATインスタンスが必要になる等の特殊事情(だからNWは1つだけにしました) ・DBはDSR、WEBはNATで分散する ・VIPは使えるけどAWS的な管理上APIサーバと通信して切り替える必要がある ・AWS的な管理上splitbrainは実質起こらないがどっちについてるか確認必要 ・AWS的な制約でマルチキャストは使えないのでHA通信はunicastを用いる ・証明書は負荷分散ライセンスとかでWEBサーバ側で管理する

    目次: ・基本構成 ・分散対象側の基本的な設定 ・ipvsadmで負荷分散の単体テスト ・heartbeatの導入設定 ・ldirectordの導入設定 ・EIP・PrivateIP移動シェル作成 ・リソース設定 ・インスタンスコピーの際の作業 ・切替テスト ・ハマったところ

    ・基本構成

    LVS01(主系) LVS02(待機系) web2台、配信サーバ2台、db2台に対しそれぞれ80と443、3306readを分散

    lvs01:172.18.1.23 lvs02:172.18.1.25 db-r-vip:172.18.1.200 web-vip:172.18.1.199 db-client:web(local) web-client:any(global) real-db:172.18.1.220,221 real-web:172.18.1.33,34 webの分散方式:NAT dbの分散方式:DSR

    設計書ではフロントセグメントとバックセグメントに分かれていたのですが、AWS的な仕様上LVSと組み合わせる為にはフラットにせざるをえませんでした。 ⇒クライアントがグローバル越しのWEBサーバはエッジルータでENIとIPが一致しないパケットが破棄される為分散方式はDSRは無理でNATしか利用できない ※こちらのスライドの17枚目が論拠です。 ⇒分散方式がNATだとリアルサーバは負荷分散サーバをデフォルトGWとして指定する必要がある ⇒NATインスタンスはNICを一つしか持つことができない仕様だがデフォルトGWは同一セグメントでないと指定できない ⇒少なくともWEBはセグメント1つにしないとLVS+VPCでは負荷分散できないがDBとWEBの分散は同じLVSで一緒にやりたいしもうNWセグメントは1つでいいや ⇒バックセグメントが無くてもVPCだしSecurityGroupの設定さえまともなら大丈夫 というような事情によりまして設計書の仕様変更をしないとどうにもなりませんでした。 なんでHAproxyじゃないのかというと、運用上不慣れだからとLVSのがパフォーマンスがいいらしいから。DBだけでもDSRできるのは嬉しいです。

    ...
  • facebookのIPがmod_geoipで拒否される対応

    こんにちは。プラットフォームの小宮です。

    apacheのmod_geoipモジュールで海外を拒否してみたところ、
    Facebookの画像が表示されないということで対応しました。

    ・whoisが必要だが入ってなかったので他の入ってるサーバでパッケージ名を調べて導入

    [shell]$ which whois /usr/bin/whois # rpm -qf /usr/bin/whois jwhois-3.2.2-1

    # yum install jwhois Installed: jwhois.x86_64 0:4.0-19.el6 # which whois /usr/bin/whois[/shell]

    ・fb公式で許可リスト取得方法を確認
    以下のコマンドで定期的に更新リストを取得せよと公式に書いてある。
    App Security - Facebook開発者

    [shell]# whois -h whois.radb.net – ‘-i origin AS32934’ | grep ^route:|awk ‘{print $2}’ 204.15.20.0/22 69.63.176.0/20 ~略~ 69.63.184.0/21 66.220.144.0/20 69.63.176.0/20[/shell] ※65ブロックくらいだった。手作業はあり得ないので何とか自動化を試みる。

    ・設定追加方法の検討
    この辺に追記できるか考えてみる。
    [shell]# cat /etc/cron.monthly/geoip #!/bin/bash wget -q http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz gunzip GeoIP.dat.gz mv -f GeoIP.dat /usr/share/GeoIP/GeoIP.dat[/shell]
    datはバイナリなので自分で追記は困難。軽くググってもそんなことしてる人いない。
    [shell]# file /usr/share/GeoIP/GeoIP.dat /usr/share/GeoIP/GeoIP.dat: data[/shell]

    ...
  • MySQLのMyISAMが混在する環境のバックアップについて注意事項

    ※古い記事ですのでご注意ください※
    こんにちは。小宮です。

    社内のMyISAMテーブルが混在しているサービスにて、
    mysqldumpによるバックアップに失敗しコールドバックアップを取ったが不整合出たという事件について相談うけまして、
    その顛末を記録しがてら注意事項をまとめておきたいと思います。
     (昔軽く伝えた記憶があり皆知ってると思ってたんですが、わかりやすさや伝える力と、
     私と他の人のmysqlに対する愛のレベルが少し異なるという認識が足らなかったようです。
     トラブルは起きるもんだし失敗は挑戦の証で成功の元ですが同じことは繰り返さないようにしないと。)

    何が大切かって、マスタとスレーブのデータの整合性です。
     つまり、
     ⇒バックアップ対象が絶対に更新されてないこと
     ⇒バックアップ取得時点のポジションとバイナリログファイル名が明確であること
     が超重要です。
     MyISAM混在環境では気をつけないと不整合でます。
     不整合でると購入したはずのコンテンツが買われてないように見えるなど割と大変なことになりますね。
     InnoDBだけなら–single-transactionつけとけば不整合は気にしなくて大丈夫です。

    ・mysqldumpに失敗した原因

    mysqldump: Error 1317: Query execution was interrupted when dumping table
    

    このエラーは、
    mysqldumpでデータを読んでる間にクエリーが中断されると出るやつです。Ctrl + Cとかkillでスレッドが殺されたとか。。
    (とTwitterで教えていただきました。ありがとうございます。

    それから、整合性のためにマスタからmysqldumpでデータをとることになったのですが、
    その際にslaveでreplicationを止めて更新がない状態でとっている方法をそのまま用いたのも不整合が起きる原因になりました。
    (MyISAMが混在する環境なのにFLUSH TABLES WITH READ LOCK;をしてなかった)

    MyISAMが混在する環境の場合、トランザクションは使えないので、
    replicaion停止または共有ロックで更新停止が必要になります。

    ex)
    FLUSH TABLES WITH READ LOCK;
    sleepやsyncでロックが終わる(確実に更新停止される)のを待つ
    ポジションとファイル名をとりログに記録する
    mysqldumpする
    UNLOCK TABLES;
    

    特にクエリを中断したりしてない(中断と整合性がごっちゃ)という指摘があったりしてそれは私もよくわからないところですが、
    更新されないようにしてれば中断も起きるはずがないので、対処方法は更新を確実に止める一択かと思います。

    ...
  • AWSメンテナンスでstoppingのまま停止しない障害の対応

    こんにちは。小宮です。

    タイトルどおり障害がありまして、今後の為に記録しておこうかと思います。

    AWSメンテ通知の来たインスタンスをStopしたところ、最終的には6時間強ほどstoppingのままでした。
    今回のインスタンスは、自分で構築したわけでなく、構築メモは残っているもののメンテナンスされていない、
    という状況把握が難しいパターンでした。
    一応上がってるプロセスとポートくらいは控えてから止めましたが、snapshotは撮ってなくAMIも作っていませんでした。

    日本語フォーラムに投稿したところ特に反応がありませんでした。
    聞いた話によると英語フォーラムを使えば15分くらいで対応してもらえることもあるようです。

    その間、stoppingのインスタンスのsnapshotを撮ってAMI作成してそこから新インスタンスを起動してみましたが、
    NICの設定の問題かなにかで接続できませんでした。
    microインスタンスを起動しapacheだけ入れて簡単なsorryページを設置しました。

    stoppingのまま6時間ほど待ったのですが一向に進捗せず、
    しかもサポートにも未加入だったので、サポートに申し込んで以下のように問い合わせをしました。
    (申し込んだら10分くらいで反映されました)。
    -——————————– 1回目:
    EC2 Management ConsoleからサーバをStopしましたが、Stoppingから進みません。
    http://aws.amazon.com/jp/instance-help/
    に従い、何度かForce Stopを試みましたが同様のため、強制停止をお願いしたいです。

    Zone: ap-northeast-1a
    Instance: i-4a42a348

    インスタンスID: i-4a42a348
    -——————————– 2回目:

    先ほどstopしました。何か対応されましたでしょうか。
    同じインスタンスをstartしたいのですが、2回ほどstartしてもstopされてしまいます。
    可能なら起動をお願いできますでしょうか。
    -——————————– 私が時短なので帰宅後、stopedになってから選べたCreateImageでAMIを作って新インスタンスを起動したら接続できたようです。

    翌朝みたらサポートから返事が来ていました。
    -——————————– サポートの方から:
    お問い合わせ誠にありがとうございます。

    i-4a42a348についてお調べしたところ、仮想サーバホストに問題が発生していたためインスタンスの停止にお時間を要しておりました。
    EC2では、長時間StoppingやShuttingdownの状態が続いているインスタンスを自動でクリーンアップする仕組みがございます。
    今回はこちらの仕組みによってインスタンスのStopが行われておりました。
    このたびはご迷惑をおかけし、申し訳ございませんでした。

    インスタンスが起動できない件については、インスタンスとEBSボリュームの関連付けに問題が発生しており、その影響でインスタンスが起動しない状態となっているようです。
    お手数をおかけしますが、インスタンスにアタッチされているボリュームをデタッチ/アタッチして再度インスタンスの起動をお試しいただけるでしょうか。
    通常のデタッチが効かない場合、Force Detachをお試しください。

    ボリュームのデタッチ/アタッチを行ってもインスタンスが起動しない場合、恐れ入りますが、再度ご連絡いただけるでしょうか。

    ご不明な点がありましたらお知らせください。
    よろしくお願いいたします。
    -——————————–

    ...
  • VPC上でPrivateIPアドレスを付け替える

    こんにちは。小宮です。
    ちょっと前にAWSのVPC上でVIP(VirtualIPアドレス)を移動させる需要があって検証したのですが、
    個人的にメモってただけだったのと、質問される機会が数回ありましたので簡単にですが投稿しておきます。

    なんらかのクラスタ構成をVPC上で扱う際、VPC上でPrivateIPアドレスを付け替える必要が生じた場合、
    awsなので切替スクリプトをAPI使うように修正しないと内部はともかく外部から打ったPINGへの応答が帰ってこない。
    つまりVIPが移動したことになりません。

    つまり、以下のような感じになります
    落とすときは、IF落としてかつCLIも実行する
    [shell]ifconfig eth0:1 down ec2-unassign-private-addresses –network-interface eni-4b649*** –secondary-private-ip-address 10.0.0.96[/shell] ※ec2-unassign-private-addressesの短縮バージョンはec2upip
    起動するときも、IF起動かつCLI実行する
    [shell]ifconfig eth0:1 up ec2-assign-private-ip-addresses –network-interface eni-70609*** –secondary-private-ip-address 10.0.0.96[/shell] ※ec2-assign-private-ip-addressesの短縮バージョンはec2apip

    切替元のENI:eni-4b649***
    切替先のENI:eni-70609***

    参考:
    VPC 内の EC2 インスタンス に複数EIPを付与する
    ec2-assign-private-ip-addresses - Amazon Elastic Compute Cloud
    ec2-unassign-private-ip-addresses - Amazon Elastic Compute Cloud

    もし、EIPが紐づいてるENIをデタッチ、アタッチしたい場合、以下のような感じ。(たぶん(自分で試してないです))
    [shell]ec2-detach-network-interface ${eni_attach_id} ec2-attach-network-interface ${ENI_ID} –instance ${target_instance_id} –device-index ${TARGET_DEVICE_INDEX}[/shell]
    加えて、ifupしてip route処理をするといいらしい。
    [shell]ifconfig eth${TARGET_DEVICE_INDEX} up

    ...
  • MySQLのslaveでDuplicate entryエラーが出た時の対処

    こんにちは。小宮です。
    このまえ出たエラーの記録です。

    ・エラーログ

    >show slave status\G
    
                       Last_Error: Error 'Duplicate entry '1133523-2013-08-18 05:03:01' for key 'PRIMARY'' on query. Default database: '*****'. Query: 'INSERT INTO `event_****_logs` ...
    

    時刻がプライマリキーになってるから重複してる感じのエラーなような。
    ログとかセッションとか重複しやすい感じがします。

    念のためmysqldumpのオプションをみたものの、
    --skip-optは入ってないのでoptが勝手について–add-drop-tableは有効なはず。

    MYDUMP_PAR='--single-transaction --dump-slave=2 --routines --include-master-host-port --all-databases'
    

    http://dev.mysql.com/doc/refman/5.5/en/mysqldump.html

    データ投入後にreset slaveしてログファイルとポジション合わせてstart slaveするなど手順には問題がないように見えました。

    お客さまに重複エントリは全部skipしていいか確認いただいたところ
    Insertでプライマリキーが被ってるのは大丈夫なのかは別途開発側で確認でとりあえずskipという話に。
    (対象がサービスで使用していないいので復旧優先ということだったと思います。不整合が気になるならマスタからdump撮り直すのが良いです。)

    ・エラーのクエリをskipする方法
    1つだけなら、

     SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
    

    ですがいっぱいでてくる場合は
    Last_SQL_Errno: 1062
    こちらのエラー番号を指定してスキップ。重複エントリを全部スキップするということです。

    ...
  • Chefで書いたレシピをテストする(serverspec)

    こんにちは。小宮です。

    今回で最終回です。
    前回までにご紹介したレシピのテストするところをご紹介します。Serverspecを用います。

    なぜServerspecがいいかというのは以下リンクにも書いてますが、以下の点がよいと思います。
    ・Chefのテストツールでなく外部のツールなので依存関係がない(puppetでも使える)
    ・設計思想がシンプル簡単に使えるものということで、手間があんまりなくて簡単につかえた

    参考:
    Serverspec at hbstudy #45
    入門Chef Solo落ち穂拾い
    kayac/newbie-training
    「入門Puppet」
    resource_typeのマニュアル
    advanced_tips
    ncstudy#05 ハンズオン資料
    parallel_tests

    ・セットアップ
    バージョン0.3と0.6だとテストの書き方が若干違う感じだったので、マニュアルに沿ってる新しいほうを推奨します。
    [shell]# yum install rubygems

    gem install serverspec rake

    serverspec-init

    Select a backend type:
    
      1) SSH
      2) Exec (local)
    
    Select number: 1
    
    Vagrant instance y/n: y
    Input vagrant instance name: 10.0.0.241
     + spec/10.0.0.241/
     + spec/10.0.0.241/httpd_spec.rb[/shell]
    <br>
    コマンドの実行が終わると、上記のようにいくつかのファイルが作成されます。<br>
    

    [shell]# serverspec-init ~略~ Input target host name: 10.0.0.240 + spec/10.0.0.240/ + spec/10.0.0.240/httpd_spec.rb[/shell]
    SSHを指定し、ターゲットホストを入力すると、ホスト毎のディレクトリが作成されました。

    ...