CDNになってキャッシュが多くなってきたので行けるのではと。 Spring同居してなければ500M程度のあまりがあるが、起動すると100M程度になるので、swap必須(KAGOYAはデフォルトでswapない)
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
15分単位でバッチが動くようで最短16分で反映確認できた。
select * from market_records where id >697982;
2018/09/26-2018/10/03 | postgres止めたせいでバックアップ動かず |
2018/10/06 | kagoya移行後初日に10/06 00時のバックアップ失敗。再現せずわからん!18:01と23:02にlost connection |
2018/10/09 | 17:01から落ちて復旧せずコンソールから強制再起動19:50復旧 |
2018/10/14 | 23:19からサーバー落ちる。ただしOOMKillerのログはなくhalt: 32-bit relocation outside of kernelがコンソールで確認できたのみ |
2018/10/15 | 13:02からサーバー落ちる。コンソールから強制再起動。22:20ぐらいにも落ちてmariadb起動何回かせず。さすがにやばすぎで移行 |
2018/10/22 | 10:05再起動。httpd invoked oom-killerが何回か発生していた。httpdのカウント入れてなかったというオチ。13:35にも同じ…。apacheのmaxclientの設定をいれたら落ち着いた |
2018/11/13 | svnのダンプロード後にrsyncでやったらおかしくなってしまった。一つ前のリビジョンダンプで戻した。以後rsync禁止?後日実施したらrsyncは無実 |
2018/11/21 24:45 | dns切り替えが早すぎで、DB移行途中にかわってしまった!php-xmlがなくてSQS送信失敗。移行前なので無傷だが |
2018/11/21 8:45 | recover途中でcron動かすのが早すぎてmysqlインポート中に再起動かかるというなんとも初歩的なミスで移行は夜へ |
2018/12/05 23:30 | DNS切替はtoolsだけでよいのに、recover前に全切り替えでサイトダウン10分。さらにCMEはIP直打ちで面倒な移行発生。かつソースも中途半端にコミット漏れで! |
2018/12/07 23:30 | recoverイメージのvirtual hostがおかしくてhttpが全滅。原因はインベントリホスト違いでrecoverしたため、ちともう一回来週リベンジ! |
2018/12/18 00:00 | バッチが動くとcake/app/tmpのディレクトリがrootになってしまう。 |
2018/12/25 09:50 | javaバッチのパス切り替え漏れ。事前で発覚したので未遂 |
2019/01/10 23:30 | X windowベースだとなぜかJDKが入らず。さらにDNS切り替えが23:45でギリ!しかし障害は翌朝に!PHP7入らずCakePHPバッチ全部こけて10時間ロスト |
2019/02/06 20:15 | DNSに影響されるバッチなのか移行後にバッチデータが旧サーバーにimportされること二回。手間取って24:05までKAGOYAサーバーにDNS向いてた |
2019/04/23 07:00 | jarticのコピーを早くやりすぎて自分のtoolがコピーされない事態に!!最後にやれ! |
2019/06/25 23:00 | jarticのコピーが中断されていた。tmuxでバックグラウンドにしていたのが見落とし原因 |
2019/10/24 21:45-22:15 | PHP7.3でsimple_dom_htmlが動かずPHPバッチ30分ロスト! |
2019/10/29 21:30-21:50 | blog.rutake.comのDNSを変え忘れ!!手動はまずい! |
2019/11/28 22:10-22:20 | ansibleの予約語変更でimportが引っかかりsvnだけ失敗!またproxyが//になりspringエラーとなるのがgit更新もれ、さらにchromedriver手動配置もれを五日後に気がつく |
2019/12/19 20:30-21:00 | ansibleの予約語変更git更新もれ。conoha2台バグ踏んで焦る焦る |
2019/12/19-2020/01/03 | cloudflareのcacheが無効になっていた。自動スクリプトのせいか?自動スクリプトが犯人と判明! |
2020/01/07 | サーバー移行中にfail2banが自分のIPで発動。二度目であるが原因不明! |
2020/01/21 | 移行後のAnsible構築中になぜかエラー。朝作成した時は大丈夫だったのだが、原因不明なのでバックアップしておいたものにmysqlだけrecoverかけた。さらにcloudflareのAPIが反応しないバグ(2日後成功) |
2020/01/23 | pip install psycopg2がこけたのでpostgresqlスルーだがrecoverでもこけて手動ばかり。fireaseのjsonを何とか自動化しないと |
2020/05/21 | jartic GW分失う |
2020/07/29 | お名前の構築にconohaでやって、最後にrecoverをonamaeにしたためVhostがうまくいかず! |
3/11 19:53からスナップショットロールバックが終わらない。21:50頃問い合わせ 3/12 キャプチャーをつけて対応依頼 電話10回以上時間帯を変えてかけるもつながらず 結局データ不整合で3/18 22:00に復帰
S3検証でまさかのオープンproxyとなること5か。あまりにCONNECTが多いから調べてみたらという状況でログをみること!
2020/01/21に遭遇。エラーではないのにdnsが切り替わらない。2日後に試したら自然復旧してたので向こうのバグだろう。
2020/01/21に遭遇。同じバージョンで12月構築したときは大丈夫だったのだが・・・。conoha1/26再構築バージョンでは解消!だがonamae VPSでは解消せず。
https://www.glamenv-septzen.net/view/1346
dstat --top-oom
vm.overcommit_memory=1 #over commitの無制限許可。2だと不許可 vm.panic_on_oom=1 kernel.panic=30
https://blog.supersonico.info/?p=321
上記設定とhtop(多分無実)を入れたあとに不安定になった可能性があるので導入は控える。over commitの無制限許可が真犯人。
項目 | 計画日 | 実施日 | 備考 |
お名前.com VPS to ConoHa 1G | 2020/01/07 | 01/07 22:55-23:08 | 通勤往路でrecoverまで準備と検証で30分。secure作り直しで有楽町ギリ。tarバックアップ中にcounterの値が変わる事態発生だが影響なし? |
ConoHa 1G to お名前.com VPS | 2020/01/07 | 01/08 24:25-24:38 | SpringBoot 128Mで同居開始。途中バッテリー切れで部屋移動などもあり2時間かけた。1Gでboot同居は危険かも |
お名前.com VPS to ConoHa 1G | 2020/01/23 | 01/23 23:00-23:08 | ansible実行後に変なエラーが出るようになったが影響なし |
ConoHa 1G to お名前.com VPS | 2020/01/23 | 01/23 23:40-23:54 | いろいろスムーズにいかなかったがちょいと手詰まり感あり |
お名前.com VPS to ConoHa 1G | 2020/01/28 | 01/28 21:10-21:30 | |
ConoHa 1G to お名前.com VPS | 2020/01/28 | 01/28 23:40-23:55 | うまくいったらconvertする予定である。結局失敗したので初期化&upgrade&convert&リトライ |
お名前.com VPS to ConoHa 1G | 2020/02/10 | 02/10 19:30-19:45 | せっかく作業環境豊富なので |
ConoHa 1G to お名前.com VPS | 2020/02/10 | 02/10 21:40-21:55 | 前回とってなかったスナップショットとりつつ、コンバートしたらスナップショットが消えた!postgresが相変わらず落ちるので外すか真面目に検討せよ。4時間かかった! |
お名前.com VPS to Kagoya 1G | 2020/02/13 | 02/13 8:15-8:23 | 1GでSpringまで含めて運用できるか?CentOS8バージョンでKagoya初挑戦だがMySQLインストールスキップな設定ミス |
Kagoya 1G to お名前.com VPS | 2020/02/14 | 02/14 9:20-30 | 2日ほど運用実績を作った。移行に夢中で有楽町おり忘れ! |
お名前.com VPS to ConoHa 1G | 2020/03/11 | 03/11 16:50-17:41 | 漏れ串で不吉なので即日再作成。snapshotのsecureまでのロールバックにが終わらない!!(-3/17まで) |
ConoHa 1G to Kagoya VPS | 2020/03/15 | 03/15 5:00-5:45 | tmuxのせいかsegmentation fault二回。upgradeしてtmux経由やめた。jqなくてエラー。KAGOYAはswap必須だな |
Kagoya 1G to お名前.com VPS | 2020/03/18 | 03/18 21:00-22:00 | gradle buildがプロセス残る問題ありつつもなんとか成功。elastic searchがまたメモリ青天井 |
お名前.com VPS to Kagoya 1G | 2020/04/07 | 04/07 7:00-15 | 日付が変わって作成し、セットアップだけして寝て翌朝に移行 |
Kagoya 1G to お名前.com VPS | 2020/04/07 | 04/07 20:45-21:00 | 完全初期化のち22Gからのコンバートが2.5H |
お名前.com VPS to Kagoya 1G | 2020/04/23 | 04/23 7:00-15 | 朝移行実施 |
Kagoya 1G to お名前.com VPS | 2020/04/23 | 04/23 18:55-19:05 | 再インストールのConvertなし |
お名前.com VPS to Kagoya 1G | 2020/05/21 | 05/21 24:00-40 | 構築から移行完了まで40分 |
Kagoya 1G to お名前.com VPS | 2020/05/21 | 05/21 17:00-17:50 | 再インストールのConvertして90分、再構築は1時間見ておく |
お名前.com VPS to ConoHa 1G | 2020/05/29 | 05/29 19:15-19:45 | 午前セットアップして、19時からpython3バージョンとlet's encrypt導入。 |
ConoHa 1G to お名前.com VPS | 2020/05/29 | 05/29 21:40-21:55 | python3でエラー続発で手動回避。db recoverで時間がかかる現象再発。conoha利用は全部で6時間 |
お名前.com VPS to Kagoya 2G | 2020/06/01 | 06/01 07:00-15 | 構築から移行完了まで40分で翌日実施 |
Kagoya 2G to お名前.com VPS | 2020/06/01 | 06/01 17:00-17:50 | |
お名前.com VPS to ConoHa 1G | 2020/06/13 | 06/15 19:06-19:16 | 土曜日にセットアップだがepelのレポジトリトラブルで2時間。月曜日にimageから復帰させて復帰。recover時にpython3非対応バグ発覚! |
ConoHa 1G to お名前.com VPS | 2020/06/15 | 06/15 20:24-20:35 | 3月のトラブル以来初のsnapshotからの復帰。なんだかんだで3時間利用 |
お名前.com VPS to ConoHa 1G | 2020/06/23 | 06/2317:52-17:58 | 定期的にゴミ掃除 |
ConoHa 1G to お名前.com VPS | 2020/06/23 | 06/23 18:52-19:02 | secureのスナップショットから復元で1時間はきつい。 |
お名前.com VPS to ConoHa 1G | 2020/07/07 | 07/08 20:25-35 | Bitbucketからgithubへ移行。事前にイメージは作成済み。 |
ConoHa 1G to お名前.com VPS | 2020/07/07 | 07/08 20:45-21:28 | secureのスナップショットから復元で1時間はJava系を後回しにすればできたかもだが、安全を考えて2時間利用 |
お名前.com VPS to ConoHa 1G | 2020/07/15 | 07/15 18:21-28 | 事前に1時間で作成し、移行 |
ConoHa 1G to お名前.com VPS | 2020/07/15 | 07/15 19:50-20:00 | 再インストール後、パッチ当て、コンバートしてスナップショットとって2時間。 |
お名前.com VPS to ConoHa 1G | 2020/07/29 | 07/29 20:19-24 | datadog再現テスト。事前に1時間で作成し、移行 |
ConoHa 1G to お名前.com VPS | 2020/07/29 | 07/29 20:30-20:40 | secureのsnapshotから復元。toolsがうまくいかない |
項目 | 計画日 | 実施日 | 備考 |
お名前.com VPS to KAGOYA V2 KVM | 2019/01/09 | 01/09 10:01-10 | GeoIP.dat形式が古すぎて404になってた&本業アタフタで2日間稼働 |
KAGOYA V2 KVM to お名前.com VPS | 2019/01/10 | 01/10 23:45-00 | XWindowを入れてみた。 |
お名前.com VPS to KAGOYA V2 KVM | 2019/02/05 | 02/06 20:00-45 | まさかのDNS参照でいったん中止、DBのみ再インポート |
KAGOYA V2 KVM to お名前.com VPS | 2019/02/06 | 02/06 23:30-00 | 上と同じミスでDNS変更伝播前にシャットダウン |
お名前.com VPS to KAGOYA V2 KVM | 2019/03/20 | 03/20 24:45-55 | 24時に構築&移行して、元のVPSは朝の間にコンバート、昼に構築して夜に1日で戻す黄金パターン。久々なので手順忘れて、せっかくSQS化したのに45分まで待っていたという。 |
KAGOYA V2 KVM to お名前.com VPS | 2019/03/20 | 03/20 20:30-40 | 上記の通り昼までに構築済みにしておき、夜20時に移行 |
お名前.com VPS to KAGOYA V2 KVM | 2019/04/23 | 04/23 6:30-45 | 早起きしたので朝以降、スナップショット戻しセットアップまで完了! |
KAGOYA V2 KVM to お名前.com VPS | 2019/04/23 | 04/23 19:30-40 | 昼に確認しておき、夜戻す。 |
お名前.com VPS to KAGOYA V2 KVM | 2019/05/21 | 05/21 00:40-55 | 夜のうちにdnfバージョンをお試し。cent7.2ではダメでyum upgradeしてから再実施。あとmod_deflate先行導入→CloudFront半額へ |
KAGOYA V2 KVM to お名前.com VPS | 2019/05/21 | 05/21 09:20-35 | centos7.5でもdnfダメ。手動upgrade後にsnapshot取得後convertで60分!順調だったので通勤往路で完璧! |
お名前.com VPS to KAGOYA V2 KVM | 2019/06/01 | 06/01 12:22-31 | 朝からセットアップして昼のランチ待ちに移行だが、土日なのでjarticは動く! |
KAGOYA V2 KVM to お名前.com VPS | 2019/06/01 | 06/01 15:05-15 | 久々の土日だったのでjartic移行がめんどいな。 |
お名前.com VPS to KAGOYA V2 KVM | 2019/06/24 | 06/24 13:05-13:20 | 朝からセットアップして昼のランチ待ちに移行。しかしDNS切り替え保存でセッション切れ!30分待っても変わらないので放置! |
KAGOYA V2 KVM to お名前.com VPS | 2019/06/24 | 06/24 22:30-45 | 最後の再起動時にInnoDB: Waiting for master thread to be suspendedがでて慌てて死んでるslave止めたら進んだ |
お名前.com VPS to KAGOYA V2 KVM | 2019/06/28 | 06/28 8:40-8:50 | 朝からセットアップして移行。 |
KAGOYA V2 KVM to お名前.com VPS | 2019/06/28 | 06/28 22:30-45 | 24日のrecoverを使う。 |
お名前.com VPS to KAGOYA V2 KVM | 2019/07/29 | 07/29 11:30-40 | 有給日!kagoyaへは早い。時間に余裕あるので最初から作り直して、snapshotも取り直し |
KAGOYA V2 KVM to お名前.com VPS | 2019/07/29 | 07/29 14:54-15:06 | |
お名前.com VPS to ConoHa 2G | 2019/08/13 | 08/14 21:20-30 | 果たして1時間で成功するか?8:24開始→セットアップ30分はかかるのでイメージ作成後recoverしたら急ぎ過ぎてバックアップが古かったオチで中断。DNS切り替え忘れで20分ロス |
ConoHa 2G to お名前.com VPS | 2019/08/14 | 08/14 22:40-23:06 | secureスナップショットから作り直してバックアップとる時間はなしで2時間以内ギリ! |
お名前.com VPS to ConoHa 2G | 2019/08/19 | 08/19 21:30-40 | お名前.com再構築準備が22時からアップデート10分の22Gから2Gのコンバートに50分の構築&移行に1時間 |
ConoHa 2G to お名前.com VPS | 2019/08/19 | 08/19 23:31-23:39 | 結局3時間利用したが、焦りすぎてconsumer止め忘れ(実害なしだが)、recover前のスナップショットとり忘れ! |
お名前.com VPS to ConoHa 1G | 2019/10/24 | 10/24 21:20-45 | CentOS8対応バージョンで再構築朝30分、夜移行で2か月稼働したので慎重にお名前を確認 |
ConoHa 1G to お名前.com VPS | 2019/10/24 | 10/24 24:00-24:10 | コンバート二回で3時間かかった。1Gで4時間耐えた。 |
お名前.com VPS to ConoHa 1G | 2019/11/28 | 11/28 20:50-21:05 | サンライズ乗車前に安心お宿で低速回線ブチ切れテザリング! |
ConoHa 1G to お名前.com VPS | 2019/11/28 | 11/28 22:00-22:20 | secureから再セットアップ。サンライズ発車直後! |
お名前.com VPS to ConoHa 1G | 2019/12/19 | 12/19 20:30-21:30 | 前日に1時間ほどでsecure/recoverイメージ作成して、DNS切り替えも用意して準備万全で移行だが、svn importでgit更新漏れ原因でこける |
ConoHa 1G to お名前.com VPS | 2019/12/19 | 12/19 22:05-22:55 | secureから30分かかって再セットアップでトータル3時間 |
お名前.com VPS to ConoHa 1G | 2019/12/25 | 12/25 06:48-6:52 | 移行はスムーズでPHP7.4本格運用開始。裏でsnapshotコンバートと再セットアップ |
ConoHa 1G to お名前.com VPS | 2019/12/25 | 12/25 09:05-09:15 | ギリ3時間であったが、PHP7.3のままだったので後日Update |
ついにさくらのVPS卒業!PHP7化を11月に実施
項目 | 計画日 | 実施日 | 備考 |
Sakura 2G to KAGOYA V2 KVM | 2018/03/06 | 03/06 | 思い立ったら即実施!Ansible最新化しつつ。backupに2分。recoverに4分で非常にスムーズ! |
KAGOYA V2 KVM to お名前.com VPS | 2018/03/12 | 03/12 23:00-15 | トライアル。金曜日までにラストSakura! |
お名前.com VPS to Sakura | 2018/03/14 | 03/15 24:00-08 | 今月3度目!しかし過信しすぎて3/10-11のjarticを失う |
Sakura to お名前.com VPS | 2018/03/28 | 03/28 23:00-10 | 今月4度目!大丈夫だろうと45分にDNS切り替えたら20分程度で伝播してDB移行前に切替発生でエラー。あとDB再起動5分かかってたので要調査 |
お名前.com VPS to Sakura | 2018/03/30 | 03/30 9:45-9:55 | 今月5度目!elasticsearch再勉強用に移動 |
Sakura to お名前.com VPS(7.4) | 2018/04/25 | 04/25 8:20-8:29 | 7:45に一回失敗。mariadbが落ちる・・・不安定でやばい!8:30からの動作確認でDNS切り替え間に合わず。クレジットバッチ再実行だが、これlocalhostにしよう |
お名前.com(7.4) VPS to kagoya 2G | 2018/08/09 | 08/09 8:06-8:14 | 台風で暇なので前日実験して、翌朝実施。recover手前まで30分と思ったたら、なんとcronタスク事前忘れ(間に合った)とバグでwikiが移行されず!手動対応 |
kagoya 2G to お名前.com(7.5) | 2018/08/10 | 08/10 23:46-23:57 | カスタムイメージのベースが7.1から7.5まで上がったので!スナップショットきれいにできなかったのが心残り。また定期的にやる!mariadb再起動成功してもansibleはフリーズで9秒時間オーバーで課金される。 |
お名前.com(7.5) to kagoya 2G | 2018/08/24 | 08/24 21:46-21:54 | 移動中だったが、無事完了。しかしDNS切り替えが15分では間に合わずLIFE手動バッチ実施 |
kagoya 2G to お名前.com(7.5) | 2018/08/25 | 08/25 17:42-17:50 | toolsのDNSを早めに変更して、昨日の教訓を生かすべく翌日実施!Mariadbログで再起動は完了していたが、でansibleがフリーズ。しゃーないので実行中止。再起動なくてもいいか?あとsdkmanにした影響でjava系のバッチがこけるこける!1日後発覚なので反省せよ!Lifeに至っては20日後に発覚という・・ |
お名前.com(7.5) to kagoya 2G | 2018/09/24 | 09/24 00:45-25:00 | たまに流してないとダメなので!しかし0時から始めたらmvn compileが時間かかり中断。45分ギリでナンとか間に合わす |
kagoya 2G to お名前.com(7.5) | 2018/09/25 | 09/25 23:00-23:15 | recoverでconnection lost発生!事前にrecover済ませて置き、slave昇格とrsyncでスピード移行。なぜかchrome閉じないとhttpsにアクセスできなかったがキャッシュのせい? |
お名前.com(7.5) to kagoya 1G | 2018/10/05 | 10/05 15:45-15:55 | 半日様子見てスワップなしでは厳しいと判断したが、スワップあれば平気。と思った2日後にlost connection3−4回でやっぱり厳しいか? |
kagoya 1G to お名前.com(7.5) | 2018/10/09 | 10/09 22:00-22:15 | むちゃくちゃ不安定になったがhtopインストールが犯人?ではなくoom-killer対策で入れたパラメータが悪かった模様。 |
お名前.com(7.5) to kagoya 2G | 2018/10/15 | 10/15 22:47-23:00 | ギリ間に合うがjavatoolセットアップスキップと稼動確認わすれで翌朝慌てて実施 |
kagoya 2G to お名前.com(7.5) | 2018/10/16 | 10/16 22:20-22:28 | 待ちきれず実施。残り2分で終了 |
お名前.com(7.5) to 自宅 to お名前.com(標準OS 7.5) | 2018/11/13 | 22:40作業開始→24:15切り戻し準備→翌日8:00切り戻し完了 | svnがrsyncのせいか移行後は崩壊。ネットワークエラーも発生頻度上がったので翌朝戻す。CentOS7.5が標準OSで作成できるようになっていたのとPHP7化忘れた!翌日PHP7にUP |
お名前.com(7.5) to kagoya 2G | 2018/11/21 | 11/21 00:45-52 | 作業開始まで長かった!翌朝php-xmlインストール漏れ発覚。 |
kagoya 2G toお名前.com(7.5) | 2018/11/21 | 11/21 20:45-58 | ボケーとしていてcron戻し忘れ手動実行。 |
お名前.com(7.5) to kagoya 2G | 2018/12/05 | 12/05 23:30-45 | 全SQS化後初の移行。 |
kagoya 2G toお名前.com(7.5) | 2018/12/07 | 12/07 23:30-45 | 万全を期してのつもりがsnapshotがおかしかったというオチでhttpに不具合 |
お名前.com(7.5) to kagoya 2G | 2018/12/18 | 12/18 23:30-45 | git移行後初、snapshot取り直し |
kagoya 2G toお名前.com(7.5) | 2018/12/18 | 12/18 10:48-58 | |
お名前.com(7.5) to kagoya 2G | 2018/12/25 | 12/25 9:30-45 | スナップショット作り直しのため移行。削除してコンバートして21Gから2.4Gヘ。今後もころころ変わるのでインストール直後のsecure化のみ |
kagoya 2G toお名前.com(7.5) | 2018/12/25 | 12/25 21:00-13 |
項目 | 計画日 | 実施日 | 備考 |
Sakura 移行 | 2017/01/15 | 01/15 | 思い立ったら1時間で実施! |
Aaure A2移行→A1へ | 2017/02/06 | 02/06 | 事前にセットアップまで終えておき、一気に切り替え移行元がSakuraだと余裕。課金切れ伸ばすべくA1へ変更だが10分かかる。A1にしてメモリ不足でMySQL死亡二回! |
Sakura 移行 | 2017/03/09 | 03/10 | SecureGuard入れてみたくて移行。しかしhttpでvitualhostが利かない障害!httpd restartで治ったが、一時間ほど404。今後はhttp&https両方で確認せよ! |
Azure A2へ移行 | 2017/06/11 | 6/11 | Sakuraが90日以上稼働しているので移行検証も兼ねて。朝用意して、昼間に検証、夜移行。しかしJenkins検証設定のまま進めて作り直しの上、うまくいったと思ったらMySQLがreadonlyで危うく大障害未遂。またpostgresの二段階移行時にスキップされてたのとjartic過去2年ロスト発覚! |
さくらのクラウド8Gへ移行 | 2017/06/17 | 6/17 | クーポンが今月末切れなので贅沢に!さすがに早い! |
さくらのクラウドtoさくらのVPS | 2017/06/29 | 6/29 | ダンプから取り込みまで10分かからない!29日夜に実施 |
さくらのVPS to Azure A1 | 2017/09/17 | 9/17 | 新Ansibleで移行初挑戦。postgresql自動起動が有効にならない!!バグ?さらに移行本番でメモリ不足でmysqlのダンプに失敗! |
Azure A1 to さくらのVPS | 2017/10/12 | 10/12 | SiteGuard lite 復活で12日夜に実施。javaバッチがパス変更を反映しておらず翌朝起動前に気づく。 |
さくらのVPS to Azure A2 | 2017/10/29 | 10/30 | CentOS7.4初稼働。まだ一ヶ月使えるので二週間だけ。ミドルウェアを極力へらして軽量セットアップにした。 |
Azure A2 to さくらのVPS | 2017/11/12 | 11/12 | 気がつけば後2日!いよいよAzureともお別れ!しかしSVNだけ利用できず!WAFが原因と判明するまでに1日 |
項目 | 計画日 | 実施日 | 備考 |
Azure移行プロジェクトII | 01/18 | 01/27 | fail2banをキチンと運用したいのでKAGOYAからazureへまたしても再構築。クレジットの残りを待って27日wiki,postgres移行が。バックアップ取得わすれで手作業多く、wikiが動かず失敗。SELinuxのせいであると判明。設定ファイルを焦って変更したため、再起動したらつながらず! |
Azure移行プロジェクトIII | 01/28 | 01/28 | A1のインスタンスで大丈夫だったが、A2にスケールアップしたところCustomLogの設定でエラー再発。バージョンも一緒なのに!謎なので作り直してwikiとpostgres移行。 |
Azure移行プロジェクト | 01/29 | 01/29 | A2インスタンスにて。cakephpのDBのみとcronも次々移行。blogの試験開始からついにblogまで移植完了!初の全部移植。以前のCentOS6のときには見られなかったPHPつまりが発生。その後料金懸念が発生し約10日で料金切れ懸念。即時出ていくプランに変更 |
Kagoya移行プロジェクト | 02/05 | 02/05 | AzureはIOが遅い。ansibleの早さがKagoyaだと段違いなので戻る。rsyslogをインストールしないとsecureやmessageが出ない。本来は週明け予定だが、6日で2500円近く食いつぶしたazureが週末をこせないと判断で夜30分でblog,cron含め全移行。6日夜停止でA2は一日約400円! |
Kagoya SSDプラン移行プロジェクト | 02/10 | 02/10 | 前日にSSDプラン登場なので、スナップショット(約10分)を取って衝動的に朝の通勤時間で移行。しかし手順が行き当たりばったりで時間足りず駅のホームで完了。空白時間は9:25から10:00の間。スナップショット作成と起動をすぐに行えば45から00までの間にぎりぎり間に合う |
Azure移行プロジェクト | 03/08 | 03/10 | Vhostを変更忘れでwikiでリダイレクトループ発生かつCloudFrontにキャッシュさせるミス。wiki,tools,postgres,svnを一気に移行して、MySQLとBlogは後日。3/14からSubcriptionは4/7に尽きる予定だが、実測したところ30日まででもっと早いだろう!二週間と考えておく。3月中に戻す予定。StaticPressインストール後にサブディレクトリが見えなくなる障害発生。3/16早朝から3/18まで停止してた!! |
Kagoya移行&新AWS完全移行 | 03/10 | 03/31 | 3/26日に実施。やはりVHOST切り替えミスでリダイレクトループ発生! |
Sakura CentOS7にて復帰 | 04/03 | 04/10 | CentOS7でリビルド。minimalにしておけばほぼkagoyaと一緒で構築OK。MySQLだけ後日移行のつもりがローカルを見る設定にしており、自動化必須。自動化仕上げて予定より早く4/4中に完全移行完了 |
Kagoya 移行 | 04/28 | 4/30 | セットアップを済ませて、recoverタスクで一気に切り替える計画。Ansibleがインストール失敗!15分ではギリだがトラブルなければ45分前にsetup終えておき、旧サーバーバックアップのリカバリーで余裕持っていける。すべて立ち上げると1.4Gで落ち着く。すべて落とすと100M程度 |
Azure A2 移行 | 05/06 | 05/07 | EPELのansibleがsvn checkout後にこけるバグあり。前日セットアップ後にwwwを午後一移行。それ以外は40分から作業着手だが、mysql-php/dstatのインストール漏れ、ESの許可IP漏れ、またしてもリダイレクトループキャッシュなどミスが目立つ。IOは相変わらず遅いがメモリは随一なので、ElasticSearch同居しても問題なし!月替わりの計算だと1000円以上残して1ヶ月持つがこれはあてにならん! |
Sakura 移行 | 05/31 | 05/31 | 残り800円であったので急遽前倒し実施。SELinux無効化忘れでSVNチェックアウトできなかったり、バックアップ削ったらディレクトリも削ったり、postgresが復元されなかったり障害レベルのミス頻発。電車降りそびれるし散々である。そして5/7の移行時にアメリカ証券のみcronされていなかった。ansibleは記載済みなのになぜ?おそらくコメントが一緒だったため。さらにはasiaがajiaとなっておりロスト! |
Azure 移行 | 06/30 | 06/30 | 完全MySQL移行完了。課金切れが怖いのでA1でスタート。前日準備の当日22時45分から着手だが、スクリプト修正やらアクセス元許可再起動忘れなどで21時からやり直し。それでもcakephpの解凍失敗(直実行だと問題なし)とsvnチェックアウトの失敗(日本語ディレクトリ関連)で時間間に合わず差分移行 |
Sakura to Azure 移行 | 10/27 | 10/27 | 思い立って即日実施。トラブルなしだが、Azureへのインポートが10分以上かかるのでひやひや。ミスなしかと思いきやcron解除し忘れでまたしてもロスト&実行時間UTC問題解消されず |
Azure to Sakura 移行 | 11/20 | 11/25 | CentOS7が標準OSとして追加されたのを発見したので旅先でansible確認して、後日夜のファミレスで実施。10分で終わったがLIFE PW更新忘れとCloudFrontがおかしいことになっていたので次回以降はキャッシュクリア必須 |
Sakura to Azure A2 移行 | 12/08 | 12/10 | デフォルトのVirtualHostのリダイレクトの設定がまずかったようだ。二回もキャッシュクリア。移行は13分で終わったが途中で切れやがった! |
Azure A1 to A1 移行 | 12/19 | 12/20 | MariaDBが落ちたのとFirewalldが止まっていた期間があったため、今回は段階移行の練習。エクスポートインポート20分でDB段階移行5分。またjavaパスとクラウドフロントリダイレクトループミスあり |
www.rutake.com | 完全に家でも良い |
wiki.rutake.com | 完全に家でも良い |
tools.rutake.com | DBのみVPSに向ける |
blog.rutake.com | 負荷次第だが、ちと長時間は厳しいかな? |
再起動に5分。recoveryの後Index再作成でも走るのかと思ったが、シャットダウン時に落ちないプロセスがいて終了を待っていた模様。バグと出ていたので再発するようであればリブートはなくす方向で!3/28のみ発生。3/30は発生せず
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.
項目 | 計画日 | 実施日 | 備考 |
wiki | 11/16 | 11/16 | |
S3バックアップ | 11/16 | 11/17 | バックアップスクリプト修正 |
toolsアプリのみ | 11/17 | 11/17 | cake2.6で動かしてみる。.htacessではまった |
バッチをローカルDBにて動かす | 11/17 | 11/17 | すんなり動いた。 |
cake2.6プロビジョニング | 11/18 | 11/19 | ちょいと後回しで、無事成功。 |
cronプロビジョニング | 11/18 | 11/18 | ansible化するが、cronファイルを復元するのでもよいかも |
postgresリモート接続にて、tftool移植 | 11/18 | 11/18 | postgresql.conf,hg_hda.conf,iptables,postgresユーザー以外での接続に変更など結構大変だったがphpモジュールは普通に動いた |
postgres移植 | 11/20 | 11/20 | ローカルから接続させる |
postgresバックアップansible化 | 11/20 | 11/20 | ローカルから接続させる |
CentOS7 iptables化 | 11/25 | ほんとはfirewalldにしたいが、共存させたいので! | |
Azureに舞台を移し,postgresアプリAnsible化 | 12/05 | 12/05 | OK |
postgre設定をAnsible化 | 12/07 | 12/07 | ローカル接続はOK! |
IP更新できない理由を突き止める | 12/07 | publicipは取得できている | |
S3バックアップジョブ分離 | 12/16 | 12/18 | credential周りでcron経由だとトラブルあり! |
svn移行 | 12/26 | 12/25 | ほぼ自動で行けた。svnだけ証明書があるので手動となる。 |
tools移行 | 12/25 | 12/25 | MySQLと管理ツールは残して、postgresは完全移行 |
Kagoyaのcron | 12/26 | 12/28 | なぜか動かなかったがいろいろインストールしてたら動くようになった。cronie-noanacronかな? |
cakephp DB完全移行 | 01/09 | 01/09 | DB単位の移行が思いのほか簡単だったので一気に作り込みしてbatchはリモートを見るようにしてみた。 |
cakephp バッチ部分移行 | 01/10 | 01/10 | SNOW,ROOM,TRAIN,ROADを早朝移行。STOCKは午後までに移行。起動スクリプトコミット漏れ発覚で注意 |
さくらのVPS512から1Gへ移行。
apacheコンテンツ移行。DBインポート完了。設定まだ。wiki.rutake.com移行完了
DB設定完了。cakephp,blog.rutake.com移行完了
SVN移行完了。SSLはIP指定をしているのでそこを変えないといけなかった。
Cronジョブ移行。バックアップでDBパスワードが変わっていたためそれなりにシェルを変更
一か月かけて準備。普段からrsyncでデータの同期はとっていた。
IP変えて再起動したら反応せず。コンソールから復旧させたが、原因不明だった。 ファイヤーウォールでSquidのポートを通していなかった。こちら設定漏れが多いので注意。Sambaのユーザー移行漏れ!
まずは、それほどアクセスのないページや自分専用コンテンツなどを自作サーバーに移行する。基本的にhttpd.confとssl.confを持ってきて、SVNのアクセス制限元を変更するぐらいで動いた。ssl.conf持ってこないとSSLに強制接続になるので今後の課題。
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
mysql> CREATE TABLE httpd_count ( -> recorded DATETIME not null, -> httpd_count int unsigned not null -> ); mysql> LOAD DATA LOCAL INFILE '/var/log/httpd_count.log' INTO TABLE httpd_count FIELDS TERMINATED BY ',';
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
createdb homedb_uft -E UTF-8 -T template0 ダンプSQLをUTF-8に変換 SET client_encoding = 'UTF-8';
データベース移行は順調。 シンボリックリンクを介してのリライトはNGのようなのでディレクトリ名変更 DBアクセス。ユーザーを追加していなくてアクセス失敗。 simple_dom_htmlライブラリを入れてなくて失敗
内部向けは自宅サーバーにおいておくか? wikiはアクセス数が減少しているのでどうする? 旧MTのコンテンツを廃止したい。
11/17-12/07 | KAGOYA VSPでCentOS7検証。wiki |
12/07- | Azureにてより自動構築重視の設定。wiki,postgresqlのtools |
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分で終わる |
GRANT ALL ON テーブル名 TO ユーザー名; GRANT ALL ON シーケンス名 TO ユーザー名;
aws s3 lsで設定の確認をすること
/etc/cron.daily/s3_backup.shがさくらだけ上記のエラーがでる。 5分ごとに実行だとでないのに!