1GBチャレンジ

CDNになってキャッシュが多くなってきたので行けるのではと。 Spring同居してなければ500M程度のあまりがあるが、起動すると100M程度になるので、swap必須(KAGOYAはデフォルトでswapない)

PHPダウングレード

yum remove php-json php-pgsql php-mbstring php-pdo php-xml php-cli php-mysqlnd php-common php-gd php
yum install --enablerepo=remi,remi-php72 php php-mbstring php-pgsql php-gd php-xml php-mysql

再起動に時間がかかる問題

2019/06ごろからお名前.com VPSのみimport直後に発生するようになった。ただし8月下旬には解消した。

190729 15:00:06  InnoDB: Starting shutdown...
190729 15:01:07  InnoDB: Waiting for master thread to be suspended
190729 15:02:07  InnoDB: Waiting for master thread to be suspended
190729 15:03:07  InnoDB: Waiting for master thread to be suspended
190729 15:04:07  InnoDB: Waiting for master thread to be suspended
190729 15:05:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

SQS移行後の手順

  1. tools.rutake.comのdns変更
  2. consumerなるべく消化させる
  3. consumer止める
  4. バックアップ
  5. toolsのDNS切り替わりをもって、consumer手動再開
  6. mvn gradleが時間かかるのでテンポラリーならスキップ!

DNS切り替え時間

15分単位でバッチが動くようで最短16分で反映確認できた。

healess chrome残タスク

  1. chrome driver
  2. root以外でjavatool

CME

select * from market_records where id >697982;

障害履歴

2018/09/26-2018/10/03postgres止めたせいでバックアップ動かず
2018/10/06kagoya移行後初日に10/06 00時のバックアップ失敗。再現せずわからん!18:01と23:02にlost connection
2018/10/0917:01から落ちて復旧せずコンソールから強制再起動19:50復旧
2018/10/1423:19からサーバー落ちる。ただしOOMKillerのログはなくhalt: 32-bit relocation outside of kernelがコンソールで確認できたのみ
2018/10/1513:02からサーバー落ちる。コンソールから強制再起動。22:20ぐらいにも落ちてmariadb起動何回かせず。さすがにやばすぎで移行
2018/10/2210:05再起動。httpd invoked oom-killerが何回か発生していた。httpdのカウント入れてなかったというオチ。13:35にも同じ…。apacheのmaxclientの設定をいれたら落ち着いた
2018/11/13svnのダンプロード後にrsyncでやったらおかしくなってしまった。一つ前のリビジョンダンプで戻した。以後rsync禁止?後日実施したらrsyncは無実
2018/11/21 24:45dns切り替えが早すぎで、DB移行途中にかわってしまった!php-xmlがなくてSQS送信失敗。移行前なので無傷だが
2018/11/21 8:45recover途中でcron動かすのが早すぎてmysqlインポート中に再起動かかるというなんとも初歩的なミスで移行は夜へ
2018/12/05 23:30DNS切替はtoolsだけでよいのに、recover前に全切り替えでサイトダウン10分。さらにCMEはIP直打ちで面倒な移行発生。かつソースも中途半端にコミット漏れで!
2018/12/07 23:30recoverイメージのvirtual hostがおかしくてhttpが全滅。原因はインベントリホスト違いでrecoverしたため、ちともう一回来週リベンジ!
2018/12/18 00:00バッチが動くとcake/app/tmpのディレクトリがrootになってしまう。
2018/12/25 09:50javaバッチのパス切り替え漏れ。事前で発覚したので未遂
2019/01/10 23:30X windowベースだとなぜかJDKが入らず。さらにDNS切り替えが23:45でギリ!しかし障害は翌朝に!PHP7入らずCakePHPバッチ全部こけて10時間ロスト
2019/02/06 20:15DNSに影響されるバッチなのか移行後にバッチデータが旧サーバーにimportされること二回。手間取って24:05までKAGOYAサーバーにDNS向いてた
2019/04/23 07:00jarticのコピーを早くやりすぎて自分のtoolがコピーされない事態に!!最後にやれ!
2019/06/25 23:00jarticのコピーが中断されていた。tmuxでバックグラウンドにしていたのが見落とし原因
2019/10/24 21:45-22:15PHP7.3でsimple_dom_htmlが動かずPHPバッチ30分ロスト!
2019/10/29 21:30-21:50blog.rutake.comのDNSを変え忘れ!!手動はまずい!
2019/11/28 22:10-22:20ansibleの予約語変更でimportが引っかかりsvnだけ失敗!またproxyが//になりspringエラーとなるのがgit更新もれ、さらにchromedriver手動配置もれを五日後に気がつく
2019/12/19 20:30-21:00ansibleの予約語変更git更新もれ。conoha2台バグ踏んで焦る焦る
2019/12/19-2020/01/03cloudflareのcacheが無効になっていた。自動スクリプトのせいか?自動スクリプトが犯人と判明!
2020/01/07サーバー移行中にfail2banが自分のIPで発動。二度目であるが原因不明!
2020/01/21移行後のAnsible構築中になぜかエラー。朝作成した時は大丈夫だったのだが、原因不明なのでバックアップしておいたものにmysqlだけrecoverかけた。さらにcloudflareのAPIが反応しないバグ(2日後成功)
2020/01/23pip install psycopg2がこけたのでpostgresqlスルーだがrecoverでもこけて手動ばかり。fireaseのjsonを何とか自動化しないと
2020/05/21jartic GW分失う
2020/07/29お名前の構築にconohaでやって、最後にrecoverをonamaeにしたためVhostがうまくいかず!

2020年のトラブル

スナップショットが終わらない問題

3/11 19:53からスナップショットロールバックが終わらない。21:50頃問い合わせ 3/12 キャプチャーをつけて対応依頼 電話10回以上時間帯を変えてかけるもつながらず 結局データ不整合で3/18 22:00に復帰

漏れ串

S3検証でまさかのオープンproxyとなること5か。あまりにCONNECTが多いから調べてみたらという状況でログをみること!

CloudFlare API不発

2020/01/21に遭遇。エラーではないのにdnsが切り替わらない。2日後に試したら自然復旧してたので向こうのバグだろう。

pip install psycopg2

2020/01/21に遭遇。同じバージョンで12月構築したときは大丈夫だったのだが・・・。conoha1/26再構築バージョンでは解消!だがonamae VPSでは解消せず。

それ以前のトラブル

DNS切り替わらない問題

https://www.glamenv-septzen.net/view/1346

OOMKiller対策

Oom Killerになりそうなプロセスを見る

dstat --top-oom

Oom Killer発動したら再起動させる

vm.overcommit_memory=1 #over commitの無制限許可。2だと不許可
vm.panic_on_oom=1
kernel.panic=30

https://blog.supersonico.info/?p=321

上記設定とhtop(多分無実)を入れたあとに不安定になった可能性があるので導入は控える。over commitの無制限許可が真犯人。

年度毎の記録

2020

項目計画日実施日備考
お名前.com VPS to ConoHa 1G2020/01/0701/07 22:55-23:08通勤往路でrecoverまで準備と検証で30分。secure作り直しで有楽町ギリ。tarバックアップ中にcounterの値が変わる事態発生だが影響なし?
ConoHa 1G to お名前.com VPS2020/01/0701/08 24:25-24:38SpringBoot 128Mで同居開始。途中バッテリー切れで部屋移動などもあり2時間かけた。1Gでboot同居は危険かも
お名前.com VPS to ConoHa 1G2020/01/2301/23 23:00-23:08ansible実行後に変なエラーが出るようになったが影響なし
ConoHa 1G to お名前.com VPS2020/01/2301/23 23:40-23:54いろいろスムーズにいかなかったがちょいと手詰まり感あり
お名前.com VPS to ConoHa 1G2020/01/2801/28 21:10-21:30
ConoHa 1G to お名前.com VPS2020/01/2801/28 23:40-23:55うまくいったらconvertする予定である。結局失敗したので初期化&upgrade&convert&リトライ
お名前.com VPS to ConoHa 1G2020/02/1002/10 19:30-19:45せっかく作業環境豊富なので
ConoHa 1G to お名前.com VPS2020/02/1002/10 21:40-21:55前回とってなかったスナップショットとりつつ、コンバートしたらスナップショットが消えた!postgresが相変わらず落ちるので外すか真面目に検討せよ。4時間かかった!
お名前.com VPS to Kagoya 1G2020/02/1302/13 8:15-8:231GでSpringまで含めて運用できるか?CentOS8バージョンでKagoya初挑戦だがMySQLインストールスキップな設定ミス
Kagoya 1G to お名前.com VPS2020/02/1402/14 9:20-302日ほど運用実績を作った。移行に夢中で有楽町おり忘れ!
お名前.com VPS to ConoHa 1G2020/03/1103/11 16:50-17:41漏れ串で不吉なので即日再作成。snapshotのsecureまでのロールバックにが終わらない!!(-3/17まで)
ConoHa 1G to Kagoya VPS2020/03/1503/15 5:00-5:45tmuxのせいかsegmentation fault二回。upgradeしてtmux経由やめた。jqなくてエラー。KAGOYAはswap必須だな
Kagoya 1G to お名前.com VPS2020/03/1803/18 21:00-22:00gradle buildがプロセス残る問題ありつつもなんとか成功。elastic searchがまたメモリ青天井
お名前.com VPS to Kagoya 1G2020/04/0704/07 7:00-15日付が変わって作成し、セットアップだけして寝て翌朝に移行
Kagoya 1G to お名前.com VPS2020/04/0704/07 20:45-21:00完全初期化のち22Gからのコンバートが2.5H
お名前.com VPS to Kagoya 1G2020/04/2304/23 7:00-15朝移行実施
Kagoya 1G to お名前.com VPS2020/04/2304/23 18:55-19:05再インストールのConvertなし
お名前.com VPS to Kagoya 1G2020/05/2105/21 24:00-40構築から移行完了まで40分
Kagoya 1G to お名前.com VPS2020/05/2105/21 17:00-17:50再インストールのConvertして90分、再構築は1時間見ておく
お名前.com VPS to ConoHa 1G2020/05/2905/29 19:15-19:45午前セットアップして、19時からpython3バージョンとlet's encrypt導入。
ConoHa 1G to お名前.com VPS2020/05/2905/29 21:40-21:55python3でエラー続発で手動回避。db recoverで時間がかかる現象再発。conoha利用は全部で6時間
お名前.com VPS to Kagoya 2G2020/06/0106/01 07:00-15構築から移行完了まで40分で翌日実施
Kagoya 2G to お名前.com VPS2020/06/0106/01 17:00-17:50
お名前.com VPS to ConoHa 1G2020/06/1306/15 19:06-19:16土曜日にセットアップだがepelのレポジトリトラブルで2時間。月曜日にimageから復帰させて復帰。recover時にpython3非対応バグ発覚!
ConoHa 1G to お名前.com VPS2020/06/1506/15 20:24-20:353月のトラブル以来初のsnapshotからの復帰。なんだかんだで3時間利用
お名前.com VPS to ConoHa 1G2020/06/2306/2317:52-17:58定期的にゴミ掃除
ConoHa 1G to お名前.com VPS2020/06/2306/23 18:52-19:02secureのスナップショットから復元で1時間はきつい。
お名前.com VPS to ConoHa 1G2020/07/0707/08 20:25-35Bitbucketからgithubへ移行。事前にイメージは作成済み。
ConoHa 1G to お名前.com VPS2020/07/0707/08 20:45-21:28secureのスナップショットから復元で1時間はJava系を後回しにすればできたかもだが、安全を考えて2時間利用
お名前.com VPS to ConoHa 1G2020/07/1507/15 18:21-28事前に1時間で作成し、移行
ConoHa 1G to お名前.com VPS2020/07/1507/15 19:50-20:00再インストール後、パッチ当て、コンバートしてスナップショットとって2時間。
お名前.com VPS to ConoHa 1G2020/07/2907/29 20:19-24datadog再現テスト。事前に1時間で作成し、移行
ConoHa 1G to お名前.com VPS2020/07/2907/29 20:30-20:40secureのsnapshotから復元。toolsがうまくいかない

2019

項目計画日実施日備考
お名前.com VPS to KAGOYA V2 KVM2019/01/0901/09 10:01-10GeoIP.dat形式が古すぎて404になってた&本業アタフタで2日間稼働
KAGOYA V2 KVM to お名前.com VPS2019/01/1001/10 23:45-00XWindowを入れてみた。
お名前.com VPS to KAGOYA V2 KVM2019/02/0502/06 20:00-45まさかのDNS参照でいったん中止、DBのみ再インポート
KAGOYA V2 KVM to お名前.com VPS2019/02/0602/06 23:30-00上と同じミスでDNS変更伝播前にシャットダウン
お名前.com VPS to KAGOYA V2 KVM2019/03/2003/20 24:45-5524時に構築&移行して、元のVPSは朝の間にコンバート、昼に構築して夜に1日で戻す黄金パターン。久々なので手順忘れて、せっかくSQS化したのに45分まで待っていたという。
KAGOYA V2 KVM to お名前.com VPS2019/03/2003/20 20:30-40上記の通り昼までに構築済みにしておき、夜20時に移行
お名前.com VPS to KAGOYA V2 KVM2019/04/2304/23 6:30-45早起きしたので朝以降、スナップショット戻しセットアップまで完了!
KAGOYA V2 KVM to お名前.com VPS2019/04/2304/23 19:30-40昼に確認しておき、夜戻す。
お名前.com VPS to KAGOYA V2 KVM2019/05/2105/21 00:40-55夜のうちにdnfバージョンをお試し。cent7.2ではダメでyum upgradeしてから再実施。あとmod_deflate先行導入→CloudFront半額へ
KAGOYA V2 KVM to お名前.com VPS2019/05/2105/21 09:20-35centos7.5でもdnfダメ。手動upgrade後にsnapshot取得後convertで60分!順調だったので通勤往路で完璧!
お名前.com VPS to KAGOYA V2 KVM2019/06/0106/01 12:22-31朝からセットアップして昼のランチ待ちに移行だが、土日なのでjarticは動く!
KAGOYA V2 KVM to お名前.com VPS2019/06/0106/01 15:05-15久々の土日だったのでjartic移行がめんどいな。
お名前.com VPS to KAGOYA V2 KVM2019/06/2406/24 13:05-13:20朝からセットアップして昼のランチ待ちに移行。しかしDNS切り替え保存でセッション切れ!30分待っても変わらないので放置!
KAGOYA V2 KVM to お名前.com VPS2019/06/2406/24 22:30-45最後の再起動時にInnoDB: Waiting for master thread to be suspendedがでて慌てて死んでるslave止めたら進んだ
お名前.com VPS to KAGOYA V2 KVM2019/06/2806/28 8:40-8:50朝からセットアップして移行。
KAGOYA V2 KVM to お名前.com VPS2019/06/2806/28 22:30-4524日のrecoverを使う。
お名前.com VPS to KAGOYA V2 KVM2019/07/2907/29 11:30-40有給日!kagoyaへは早い。時間に余裕あるので最初から作り直して、snapshotも取り直し
KAGOYA V2 KVM to お名前.com VPS2019/07/2907/29 14:54-15:06
お名前.com VPS to ConoHa 2G2019/08/1308/14 21:20-30果たして1時間で成功するか?8:24開始→セットアップ30分はかかるのでイメージ作成後recoverしたら急ぎ過ぎてバックアップが古かったオチで中断。DNS切り替え忘れで20分ロス
ConoHa 2G to お名前.com VPS2019/08/1408/14 22:40-23:06secureスナップショットから作り直してバックアップとる時間はなしで2時間以内ギリ!
お名前.com VPS to ConoHa 2G2019/08/1908/19 21:30-40お名前.com再構築準備が22時からアップデート10分の22Gから2Gのコンバートに50分の構築&移行に1時間
ConoHa 2G to お名前.com VPS2019/08/1908/19 23:31-23:39結局3時間利用したが、焦りすぎてconsumer止め忘れ(実害なしだが)、recover前のスナップショットとり忘れ!
お名前.com VPS to ConoHa 1G2019/10/2410/24 21:20-45CentOS8対応バージョンで再構築朝30分、夜移行で2か月稼働したので慎重にお名前を確認
ConoHa 1G to お名前.com VPS2019/10/2410/24 24:00-24:10コンバート二回で3時間かかった。1Gで4時間耐えた。
お名前.com VPS to ConoHa 1G2019/11/2811/28 20:50-21:05サンライズ乗車前に安心お宿で低速回線ブチ切れテザリング!
ConoHa 1G to お名前.com VPS2019/11/2811/28 22:00-22:20secureから再セットアップ。サンライズ発車直後!
お名前.com VPS to ConoHa 1G2019/12/1912/19 20:30-21:30前日に1時間ほどでsecure/recoverイメージ作成して、DNS切り替えも用意して準備万全で移行だが、svn importでgit更新漏れ原因でこける
ConoHa 1G to お名前.com VPS2019/12/1912/19 22:05-22:55secureから30分かかって再セットアップでトータル3時間
お名前.com VPS to ConoHa 1G2019/12/2512/25 06:48-6:52移行はスムーズでPHP7.4本格運用開始。裏でsnapshotコンバートと再セットアップ
ConoHa 1G to お名前.com VPS2019/12/2512/25 09:05-09:15ギリ3時間であったが、PHP7.3のままだったので後日Update

2018

ついにさくらのVPS卒業!PHP7化を11月に実施

項目計画日実施日備考
Sakura 2G to KAGOYA V2 KVM2018/03/0603/06思い立ったら即実施!Ansible最新化しつつ。backupに2分。recoverに4分で非常にスムーズ!
KAGOYA V2 KVM to お名前.com VPS2018/03/1203/12 23:00-15トライアル。金曜日までにラストSakura!
お名前.com VPS to Sakura2018/03/1403/15 24:00-08今月3度目!しかし過信しすぎて3/10-11のjarticを失う
Sakura to お名前.com VPS2018/03/2803/28 23:00-10今月4度目!大丈夫だろうと45分にDNS切り替えたら20分程度で伝播してDB移行前に切替発生でエラー。あとDB再起動5分かかってたので要調査
お名前.com VPS to Sakura2018/03/3003/30 9:45-9:55今月5度目!elasticsearch再勉強用に移動
Sakura to お名前.com VPS(7.4)2018/04/2504/25 8:20-8:297:45に一回失敗。mariadbが落ちる・・・不安定でやばい!8:30からの動作確認でDNS切り替え間に合わず。クレジットバッチ再実行だが、これlocalhostにしよう
お名前.com(7.4) VPS to kagoya 2G2018/08/0908/09 8:06-8:14台風で暇なので前日実験して、翌朝実施。recover手前まで30分と思ったたら、なんとcronタスク事前忘れ(間に合った)とバグでwikiが移行されず!手動対応
kagoya 2G to お名前.com(7.5)2018/08/1008/10 23:46-23:57カスタムイメージのベースが7.1から7.5まで上がったので!スナップショットきれいにできなかったのが心残り。また定期的にやる!mariadb再起動成功してもansibleはフリーズで9秒時間オーバーで課金される。
お名前.com(7.5) to kagoya 2G2018/08/2408/24 21:46-21:54移動中だったが、無事完了。しかしDNS切り替えが15分では間に合わずLIFE手動バッチ実施
kagoya 2G to お名前.com(7.5)2018/08/2508/25 17:42-17:50toolsのDNSを早めに変更して、昨日の教訓を生かすべく翌日実施!Mariadbログで再起動は完了していたが、でansibleがフリーズ。しゃーないので実行中止。再起動なくてもいいか?あとsdkmanにした影響でjava系のバッチがこけるこける!1日後発覚なので反省せよ!Lifeに至っては20日後に発覚という・・
お名前.com(7.5) to kagoya 2G2018/09/2409/24 00:45-25:00たまに流してないとダメなので!しかし0時から始めたらmvn compileが時間かかり中断。45分ギリでナンとか間に合わす
kagoya 2G to お名前.com(7.5)2018/09/2509/25 23:00-23:15recoverでconnection lost発生!事前にrecover済ませて置き、slave昇格とrsyncでスピード移行。なぜかchrome閉じないとhttpsにアクセスできなかったがキャッシュのせい?
お名前.com(7.5) to kagoya 1G2018/10/0510/05 15:45-15:55半日様子見てスワップなしでは厳しいと判断したが、スワップあれば平気。と思った2日後にlost connection3−4回でやっぱり厳しいか?
kagoya 1G to お名前.com(7.5)2018/10/0910/09 22:00-22:15むちゃくちゃ不安定になったがhtopインストールが犯人?ではなくoom-killer対策で入れたパラメータが悪かった模様。
お名前.com(7.5) to kagoya 2G2018/10/1510/15 22:47-23:00ギリ間に合うがjavatoolセットアップスキップと稼動確認わすれで翌朝慌てて実施
kagoya 2G to お名前.com(7.5)2018/10/1610/16 22:20-22:28待ちきれず実施。残り2分で終了
お名前.com(7.5) to 自宅 to お名前.com(標準OS 7.5)2018/11/1322:40作業開始→24:15切り戻し準備→翌日8:00切り戻し完了svnがrsyncのせいか移行後は崩壊。ネットワークエラーも発生頻度上がったので翌朝戻す。CentOS7.5が標準OSで作成できるようになっていたのとPHP7化忘れた!翌日PHP7にUP
お名前.com(7.5) to kagoya 2G2018/11/2111/21 00:45-52作業開始まで長かった!翌朝php-xmlインストール漏れ発覚。
kagoya 2G toお名前.com(7.5)2018/11/2111/21 20:45-58ボケーとしていてcron戻し忘れ手動実行。
お名前.com(7.5) to kagoya 2G2018/12/0512/05 23:30-45全SQS化後初の移行。
kagoya 2G toお名前.com(7.5)2018/12/0712/07 23:30-45万全を期してのつもりがsnapshotがおかしかったというオチでhttpに不具合
お名前.com(7.5) to kagoya 2G2018/12/1812/18 23:30-45git移行後初、snapshot取り直し
kagoya 2G toお名前.com(7.5)2018/12/1812/18 10:48-58
お名前.com(7.5) to kagoya 2G2018/12/2512/25 9:30-45スナップショット作り直しのため移行。削除してコンバートして21Gから2.4Gヘ。今後もころころ変わるのでインストール直後のsecure化のみ
kagoya 2G toお名前.com(7.5)2018/12/2512/25 21:00-13

2017

項目計画日実施日備考
Sakura 移行2017/01/1501/15思い立ったら1時間で実施!
Aaure A2移行→A1へ2017/02/0602/06事前にセットアップまで終えておき、一気に切り替え移行元がSakuraだと余裕。課金切れ伸ばすべくA1へ変更だが10分かかる。A1にしてメモリ不足でMySQL死亡二回!
Sakura 移行2017/03/0903/10SecureGuard入れてみたくて移行。しかしhttpでvitualhostが利かない障害!httpd restartで治ったが、一時間ほど404。今後はhttp&https両方で確認せよ!
Azure A2へ移行2017/06/116/11Sakuraが90日以上稼働しているので移行検証も兼ねて。朝用意して、昼間に検証、夜移行。しかしJenkins検証設定のまま進めて作り直しの上、うまくいったと思ったらMySQLがreadonlyで危うく大障害未遂。またpostgresの二段階移行時にスキップされてたのとjartic過去2年ロスト発覚!
さくらのクラウド8Gへ移行2017/06/176/17クーポンが今月末切れなので贅沢に!さすがに早い!
さくらのクラウドtoさくらのVPS2017/06/296/29ダンプから取り込みまで10分かからない!29日夜に実施
さくらのVPS to Azure A12017/09/179/17新Ansibleで移行初挑戦。postgresql自動起動が有効にならない!!バグ?さらに移行本番でメモリ不足でmysqlのダンプに失敗!
Azure A1 to さくらのVPS2017/10/1210/12SiteGuard lite 復活で12日夜に実施。javaバッチがパス変更を反映しておらず翌朝起動前に気づく。
さくらのVPS to Azure A22017/10/2910/30CentOS7.4初稼働。まだ一ヶ月使えるので二週間だけ。ミドルウェアを極力へらして軽量セットアップにした。
Azure A2 to さくらのVPS2017/11/1211/12気がつけば後2日!いよいよAzureともお別れ!しかしSVNだけ利用できず!WAFが原因と判明するまでに1日

2016

項目計画日実施日備考
Azure移行プロジェクトII01/1801/27fail2banをキチンと運用したいのでKAGOYAからazureへまたしても再構築。クレジットの残りを待って27日wiki,postgres移行が。バックアップ取得わすれで手作業多く、wikiが動かず失敗。SELinuxのせいであると判明。設定ファイルを焦って変更したため、再起動したらつながらず!
Azure移行プロジェクトIII01/2801/28A1のインスタンスで大丈夫だったが、A2にスケールアップしたところCustomLogの設定でエラー再発。バージョンも一緒なのに!謎なので作り直してwikiとpostgres移行。
Azure移行プロジェクト01/2901/29A2インスタンスにて。cakephpのDBのみとcronも次々移行。blogの試験開始からついにblogまで移植完了!初の全部移植。以前のCentOS6のときには見られなかったPHPつまりが発生。その後料金懸念が発生し約10日で料金切れ懸念。即時出ていくプランに変更
Kagoya移行プロジェクト02/0502/05AzureはIOが遅い。ansibleの早さがKagoyaだと段違いなので戻る。rsyslogをインストールしないとsecureやmessageが出ない。本来は週明け予定だが、6日で2500円近く食いつぶしたazureが週末をこせないと判断で夜30分でblog,cron含め全移行。6日夜停止でA2は一日約400円!
Kagoya SSDプラン移行プロジェクト02/1002/10前日にSSDプラン登場なので、スナップショット(約10分)を取って衝動的に朝の通勤時間で移行。しかし手順が行き当たりばったりで時間足りず駅のホームで完了。空白時間は9:25から10:00の間。スナップショット作成と起動をすぐに行えば45から00までの間にぎりぎり間に合う
Azure移行プロジェクト03/0803/10Vhostを変更忘れでwikiでリダイレクトループ発生かつCloudFrontにキャッシュさせるミス。wiki,tools,postgres,svnを一気に移行して、MySQLとBlogは後日。3/14からSubcriptionは4/7に尽きる予定だが、実測したところ30日まででもっと早いだろう!二週間と考えておく。3月中に戻す予定。StaticPressインストール後にサブディレクトリが見えなくなる障害発生。3/16早朝から3/18まで停止してた!!
Kagoya移行&新AWS完全移行03/1003/313/26日に実施。やはりVHOST切り替えミスでリダイレクトループ発生!
Sakura CentOS7にて復帰04/0304/10CentOS7でリビルド。minimalにしておけばほぼkagoyaと一緒で構築OK。MySQLだけ後日移行のつもりがローカルを見る設定にしており、自動化必須。自動化仕上げて予定より早く4/4中に完全移行完了
Kagoya 移行04/284/30セットアップを済ませて、recoverタスクで一気に切り替える計画。Ansibleがインストール失敗!15分ではギリだがトラブルなければ45分前にsetup終えておき、旧サーバーバックアップのリカバリーで余裕持っていける。すべて立ち上げると1.4Gで落ち着く。すべて落とすと100M程度
Azure A2 移行05/0605/07EPELのansibleがsvn checkout後にこけるバグあり。前日セットアップ後にwwwを午後一移行。それ以外は40分から作業着手だが、mysql-php/dstatのインストール漏れ、ESの許可IP漏れ、またしてもリダイレクトループキャッシュなどミスが目立つ。IOは相変わらず遅いがメモリは随一なので、ElasticSearch同居しても問題なし!月替わりの計算だと1000円以上残して1ヶ月持つがこれはあてにならん!
Sakura 移行05/3105/31残り800円であったので急遽前倒し実施。SELinux無効化忘れでSVNチェックアウトできなかったり、バックアップ削ったらディレクトリも削ったり、postgresが復元されなかったり障害レベルのミス頻発。電車降りそびれるし散々である。そして5/7の移行時にアメリカ証券のみcronされていなかった。ansibleは記載済みなのになぜ?おそらくコメントが一緒だったため。さらにはasiaがajiaとなっておりロスト!
Azure 移行06/3006/30完全MySQL移行完了。課金切れが怖いのでA1でスタート。前日準備の当日22時45分から着手だが、スクリプト修正やらアクセス元許可再起動忘れなどで21時からやり直し。それでもcakephpの解凍失敗(直実行だと問題なし)とsvnチェックアウトの失敗(日本語ディレクトリ関連)で時間間に合わず差分移行
Sakura to Azure 移行10/2710/27思い立って即日実施。トラブルなしだが、Azureへのインポートが10分以上かかるのでひやひや。ミスなしかと思いきやcron解除し忘れでまたしてもロスト&実行時間UTC問題解消されず
Azure to Sakura 移行11/2011/25CentOS7が標準OSとして追加されたのを発見したので旅先でansible確認して、後日夜のファミレスで実施。10分で終わったがLIFE PW更新忘れとCloudFrontがおかしいことになっていたので次回以降はキャッシュクリア必須
Sakura to Azure A2 移行12/0812/10デフォルトのVirtualHostのリダイレクトの設定がまずかったようだ。二回もキャッシュクリア。移行は13分で終わったが途中で切れやがった!
Azure A1 to A1 移行12/1912/20MariaDBが落ちたのとFirewalldが止まっていた期間があったため、今回は段階移行の練習。エクスポートインポート20分でDB段階移行5分。またjavaパスとクラウドフロントリダイレクトループミスあり

自宅サーバーを一時的に使う計画

www.rutake.com完全に家でも良い
wiki.rutake.com完全に家でも良い
tools.rutake.comDBのみVPSに向ける
blog.rutake.com負荷次第だが、ちと長時間は厳しいかな?

MySQL再起動問題

再起動に5分。recoveryの後Index再作成でも走るのかと思ったが、シャットダウン時に落ちないプロセスがいて終了を待っていた模様。バグと出ていたので再発するようであればリブートはなくす方向で!3/28のみ発生。3/30は発生せず

MariaDB落ちる問題

180425  7:48:01  InnoDB: Starting shutdown...
InnoDB: Warning: 1 threads created by InnoDB had not exited at shutdown!
180425  7:49:42  InnoDB: error: return value 16 when calling
InnoDB: pthread_mutex_destroy().
InnoDB: Byte contents of the pthread mutex at 0x55c575571830:
 len 40; hex 00000000000000000000000001000000030000000000000000000000000000000000000000000000; asc                                         ;
180425  7:49:42  InnoDB: Assertion failure in thread 139859370972928 in file os0sync.c line 258
InnoDB: Failing assertion: pthread_cond_destroy(cond) == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
180425  7:49:42 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Ansible化全体計画

項目計画日実施日備考
wiki11/1611/16
S3バックアップ11/1611/17バックアップスクリプト修正
toolsアプリのみ11/1711/17cake2.6で動かしてみる。.htacessではまった
バッチをローカルDBにて動かす11/1711/17すんなり動いた。
cake2.6プロビジョニング11/1811/19ちょいと後回しで、無事成功。
cronプロビジョニング11/1811/18ansible化するが、cronファイルを復元するのでもよいかも
postgresリモート接続にて、tftool移植11/1811/18postgresql.conf,hg_hda.conf,iptables,postgresユーザー以外での接続に変更など結構大変だったがphpモジュールは普通に動いた
postgres移植11/2011/20ローカルから接続させる
postgresバックアップansible化11/2011/20ローカルから接続させる
CentOS7 iptables化11/25ほんとはfirewalldにしたいが、共存させたいので!
Azureに舞台を移し,postgresアプリAnsible化12/0512/05OK
postgre設定をAnsible化12/0712/07ローカル接続はOK!
IP更新できない理由を突き止める12/07publicipは取得できている
S3バックアップジョブ分離12/1612/18credential周りでcron経由だとトラブルあり!
svn移行12/2612/25ほぼ自動で行けた。svnだけ証明書があるので手動となる。
tools移行12/2512/25MySQLと管理ツールは残して、postgresは完全移行
Kagoyaのcron12/2612/28なぜか動かなかったがいろいろインストールしてたら動くようになった。cronie-noanacronかな?
cakephp DB完全移行01/0901/09DB単位の移行が思いのほか簡単だったので一気に作り込みしてbatchはリモートを見るようにしてみた。
cakephp バッチ部分移行01/1001/10SNOW,ROOM,TRAIN,ROADを早朝移行。STOCKは午後までに移行。起動スクリプトコミット漏れ発覚で注意

2012/04

さくらのVPS512から1Gへ移行。

スケジュール

apacheコンテンツ移行。DBインポート完了。設定まだ。wiki.rutake.com移行完了

DB設定完了。cakephp,blog.rutake.com移行完了

SVN移行完了。SSLはIP指定をしているのでそこを変えないといけなかった。

Cronジョブ移行。バックアップでDBパスワードが変わっていたためそれなりにシェルを変更

トラブル

2013/07 自宅内サーバー移行

一か月かけて準備。普段からrsyncでデータの同期はとっていた。

トラブル

IP変えて再起動したら反応せず。コンソールから復旧させたが、原因不明だった。 ファイヤーウォールでSquidのポートを通していなかった。こちら設定漏れが多いので注意。Sambaのユーザー移行漏れ!

2013/12 さくらVPS再構築

下準備

まずは、それほどアクセスのないページや自分専用コンテンツなどを自作サーバーに移行する。基本的にhttpd.confとssl.confを持ってきて、SVNのアクセス制限元を変更するぐらいで動いた。ssl.conf持ってこないとSSLに強制接続になるので今後の課題。

移行対象

  1. tools.rutake.com以下のアプリ
  2. wiki.rutake.com

要塞化

tools.rutake.comのpostgres移行

  1. postgres自動起動の設定
  2. DBインポート(DB作成必要)
  3. PHPツール移植(ツールは問題なしだが、DB接続で下記問題発覚)
psql: FATAL:  Ident authentication failed for user "postgres"
SQLSTATE[08006] [7] FATAL: Ident authentication failed for user "postgres"
# "local" is for Unix domain socket connections only
local   all         all                                trust
#host    all         all         127.0.0.1/32          ident sameuser
host     all         all         127.0.0.1/32          md5

2.4にしてみた。いつものようにhttpd.confの設定が必要。 appのみSVNからコピーして無事接続成功

DB単位でエクスポート
mysqldump -u root -p MYDATABASE > /var/tmp/MYDATABASEdmp.sql
移行元のDBを消す。
[root@epox cake2.4]# mysqladmin -u root -p drop MYDATABASE
空のDBを作成
mysql> create database MYDATABASE default charset utf8;
インポート
mysql -u root -p MYDATABASE < MYDATABASEdmp.sql
目的のディレクトリの一階層上に移動
cd /var/www/UPPER_DIR
tar cvzf blog.tar.gz blog/
DBも同じようにバックアップして圧縮しておく(18Mが十分の一に)
受け取りサーバー側では同じく一階層上で解凍
DBもインポートしておく
空のDBを作成(utf-8でOK)
mysql> create database MYDATABASE default charset utf8;
インポート
mysql -u root -p MYDATABASE < MYDATABASEdmp.sql
移行元
mysqldump -u root -p --add-drop-table cakephp rooms > rooms.sql
gzip rooms.sql
移行先
gzip -d rooms.sql.gz
mysql -u root -p cakephp < /var/tmp/rooms.sql
svnadmin dump /home/svn/repos | gzip > /var/tmp/myrepos.tar.gz

サーバー再インストールからコンソール上がりきるまで10分は見ておいたほうがよい。DNSがなかなか切替わらず見切り発車で実施。SSLの秘密鍵のバックアップを忘れてSSL月だと起動失敗したのでSSLは後日。blogとwikiは移行完了。cronの改行コードがおかしくてエラーとなっていた。LFじゃないとNG

SVN移行,hosts設定,

移行漏れ

SSL証明書,.htpasswd

移行前の下準備

  1. 公開鍵のバックアップ(OK)
  2. blog関係バックアップ
  3. cron関係チェック(OK)
  4. yumの履歴(OK)
  5. SVNバックアップ(OK)
createdb homedb_uft -E UTF-8 -T template0 
ダンプSQLをUTF-8に変換
SET client_encoding = 'UTF-8';
データベース移行は順調。
シンボリックリンクを介してのリライトはNGのようなのでディレクトリ名変更
DBアクセス。ユーザーを追加していなくてアクセス失敗。
simple_dom_htmlライブラリを入れてなくて失敗

2015/04 攻撃を受けてセキュリティ強化とアプリケーション分離と作り直し

基本方針

内部向けは自宅サーバーにおいておくか? wikiはアクセス数が減少しているのでどうする? 旧MTのコンテンツを廃止したい。

対象

作業手順

トラブル

2015/11 一部アプリケーション分離

移行スケジュール

11/17-12/07KAGOYA VSPでCentOS7検証。wiki
12/07-Azureにてより自動構築重視の設定。wiki,postgresqlのtools

Ansible状況

CentOS 6 さくらのVPSセットアップ完了。DBの移行断念
CentOS 6 nagoya VPSセットアップ完了。DBの移行断念
Azure OpenLogic CentOS 7.1セットアップ完了。移行も完了
Azure OpenLogic CentOS 7.2セットアップ完了。Sonhrqube以外OK
さくら CentOS 7.2セットアップ完了。セットアップタスクが5分程度(ほか14-15分)で終わるので、一番早い!
KAGOYA CentOS 7.0セットアップ完了。TybeBだとセットアップ5分、リカバー2分で終わる

チェックリスト

  1. 認証周りがキチンとされているか?(管理画面に入ること)
  2. 旧コンテンツ(blog/techmemo)やwikiのリダイレクトが完璧であること。
  3. アクセス制限が移行されていること

postgresのユーザーに権限付与(シーケンスリード権限がなかった)

GRANT ALL ON テーブル名 TO ユーザー名;
GRANT ALL ON シーケンス名 TO ユーザー名;

cron移行周りのはまり(現在進行中)

aws s3 lsで設定の確認をすること

/etc/cron.daily/s3_backup.shがさくらだけ上記のエラーがでる。 5分ごとに実行だとでないのに!

wordpressのサブディレクトリからサブドメインへ移行

  1. http://blog.shun-ichiro.com/howto/move-wordpress/
Counter: 3047, today: 3, yesterday: 0

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS