- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2020-09-25T19:20:26+00:00","default:wikiadmin","wikiadmin")
#author("2020-12-07T12:30:56+00:00","default:wikiadmin","wikiadmin")
#contents
*1GBチャレンジ [#ae852652]
CDNになってキャッシュが多くなってきたので行けるのではと。
Spring同居してなければ500M程度のあまりがあるが、起動すると100M程度になるので、swap必須(KAGOYAはデフォルトでswapない)
*PHPダウングレード [#e0fdf7ea]
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
*再起動に時間がかかる問題 [#p6a40b29]
2019/06ごろからお名前.com VPSのみimport直後に発生するようになった。ただし８月下旬には解消した。
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移行後の手順 [#qc065a74]
+tools.rutake.comのdns変更
+consumerなるべく消化させる
+consumer止める
+バックアップ
+toolsのDNS切り替わりをもって、consumer手動再開
+mvn gradleが時間かかるのでテンポラリーならスキップ！
**DNS切り替え時間 [#p9276497]
15分単位でバッチが動くようで最短16分で反映確認できた。
*healess chrome残タスク [#p8c359dd]
+chrome driver
+root以外でjavatool
**CME [#te4821a9]
select * from market_records where id >697982;
*障害履歴 [#cef911e0]
|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バッチ全部こけて１０時間ロスト|
|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がうまくいかず！|
|2020/08/12|Ansibleの警告対応でデフォルトのパーミッションが600になる。そのためdockerのaws profile/datadog/tools/svnのdigest認証ファイルが読み込めずに対応。ついでに証明書のバックアップが5/25時点でずっと古かったというのが運用後に判明|
|2020/08/27|コンソールログ出っぱなし４日気が付かない＆DBダンプのオプション調査でdumpファイルをzlessで検索かけたら、CPU100%でログインもできずにコンソールから再起動|
|2020/09/03|Failed to validate GPG signatureが至るところで出るという状況。remi/percona/webminで発生。Conohaは順調だったが、onamaeで発生後にConohaでも発生|
|2020/09/16|rakuten cron追加でcedynaをうわがいてしまうと言う。幸い気がついて実害はほぼなし|
|2020/09/23|洗濯の合間に慌ててやってcronが動いてしまう。もともと構造的欠陥なので根本対処入れる。conohaで再開忘れ、さらにonamaeへの戻しでmysqlスキップされたという状況でDNS切り替えて久々の大障害。さらに初のconohaバックアップが10分立っても終わらない事態で4時間かつpush忘れという|
|2020/10/01|conoha バックアップから起動したらcrondが動き出す。mysqlはrestoreされず、さらにcrondが動き出すと言う。|
|2020/10/02|crondを止めるというのをonamae本体でやってしまい。1日クロールせず！大障害|
|2020/10/10|firewalldでIP指定してからDockerでMySQLに接続できなくなっていた！（外部から接続扱い）。家から接続できないのに気がつき、ようやく修正。|
|2020/10/20|クレジット スケジューラー移行後、ChromeDriverが古くて後続こけるという。半日で気がついたがなにか防止策を！暫定として２３時にcron|
|2020/11/06|nodeのタスクがこけて、後続にあったmyappsが入ってないのにcron起動！そもそも実行順序がおかしいので変えた。|
|2020/11/10|xtrabackup復元初でSQLは問題なしだがPHPアプリがlocalhostでは接続できず。consumer動かして２０分間のデータロス！さらにxtrabackupのブランチPUSH忘れて失う！！！|
|2020/11/26|jarコピー復元初でクラスパス設定漏れかつまたブランチを今度はcommitスラ忘れて失う|
|2020/12/07|cron開始忘れで20分ほどロスト！そろそろrecover後に自動化しなければ|
*2020年のトラブル [#j1974928]
**スナップショットが終わらない問題 [#hb58c9cd]
3/11 19:53からスナップショットロールバックが終わらない。21:50頃問い合わせ
3/12 キャプチャーをつけて対応依頼
電話10回以上時間帯を変えてかけるもつながらず
結局データ不整合で3/18 22:00に復帰
**漏れ串 [#sa71f64b]
S3検証でまさかのオープンproxyとなること5か。あまりにCONNECTが多いから調べてみたらという状況でログをみること！
**CloudFlare API不発 [#z9f06b06]
2020/01/21に遭遇。エラーではないのにdnsが切り替わらない。2日後に試したら自然復旧してたので向こうのバグだろう。
**pip install psycopg2 [#te84a23e]
2020/01/21に遭遇。同じバージョンで12月構築したときは大丈夫だったのだが・・・。conoha1/26再構築バージョンでは解消！だがonamae VPSでは解消せず。
2020/01/21に遭遇。同じバージョンで12月構築したときは大丈夫だったのだが・・・。conoha1/26再構築バージョンでは解消！だがonamae VPSでは解消せず。2020/10ごろに試してみたら解消していた。
-setuptools古い 変わらず
-pip古い 変わらず
**mysql restoreされず [#nd8c51ee]
もともと使ってないDBをリストアするという潜在バグを抱えていたのだが、ansible側がDB指定で取り込みしてなかったため助かっていた。
しかし2020/09以降はきちんと指定のDBのみ取り込むようになったため顕在化。
*それ以前のトラブル [#l9ad7de5]
**DNS切り替わらない問題 [#y7bce497]
-Windows 10バッチマシンからDNSがいつまでたっても昔のIPを参照している問題
-最初はドメイン記載ミスでワイルドカード扱いになりGMOにいっていた
-それを解消したけどダメ、次はDNS設定。しかしコマンドラインからは正しく新IPが出る。
https://www.glamenv-septzen.net/view/1346
*OOMKiller対策 [#eb8dc34d]
**Oom Killerになりそうなプロセスを見る [#r428fa33]
dstat --top-oom
**Oom Killer発動したら再起動させる [#bb192457]
vm.overcommit_memory=1 #over commitの無制限許可。2だと不許可
vm.panic_on_oom=1
kernel.panic=30
https://blog.supersonico.info/?p=321
上記設定とhtop(多分無実)を入れたあとに不安定になった可能性があるので導入は控える。over commitの無制限許可が真犯人。
*年度毎の記録 [#b5488a69]
**2020 [#nca26ea8]
|項目|計画日|実施日|備考|
|お名前.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が相変わらず落ちるので外すか真面目に検討せよ。４時間かかった！|
|お名前.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|２日ほど運用実績を作った。移行に夢中で有楽町おり忘れ！|
|お名前.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分、再構築は１時間見ておく|
|お名前.com VPS to ConoHa 1G|2020/05/29|05/29 19:15-19:45|午前セットアップして、１９時からpython3バージョンとlet's encrypt導入。|
|ConoHa 1G to お名前.com VPS|2020/05/29|05/29 21:40-21:55|python3でエラー続発で手動回避。db recoverで時間がかかる現象再発。conoha利用は全部で６時間|
|お名前.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のレポジトリトラブルで２時間。月曜日にimageから復帰させて復帰。recover時にpython3非対応バグ発覚！|
|ConoHa 1G to お名前.com VPS|2020/06/15|06/15 20:24-20:35|3月のトラブル以来初のsnapshotからの復帰。なんだかんだで３時間利用|
|お名前.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のスナップショットから復元で１時間はきつい。|
|お名前.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のスナップショットから復元で１時間はJava系を後回しにすればできたかもだが、安全を考えて２時間利用|
|お名前.com VPS to ConoHa 1G|2020/07/15|07/15 18:21-28|事前に１時間で作成し、移行|
|ConoHa 1G to お名前.com VPS|2020/07/15|07/15 19:50-20:00|再インストール後、パッチ当て、コンバートしてスナップショットとって２時間。|
|お名前.com VPS to ConoHa 1G|2020/07/29|07/29 20:19-24|datadog再現テスト。事前に１時間で作成し、移行|
|ConoHa 1G to お名前.com VPS|2020/07/29|07/29 20:30-20:40|secureのsnapshotから復元。toolsがうまくいかない|
|お名前.com VPS to ConoHa 1G|2020/08/12|08/12 18:42-49|sentry導入復元テスト。事前に１時間で作成し、移行|
|ConoHa 1G to お名前.com VPS|2020/08/12|08/12 20:04-20:14|secureのsnapshotから復元。トラブル調査で気がつけば２時間すぎたので３時間。|
|お名前.com VPS to ConoHa 1G|2020/08/21|08/21 9:33-39|今更ながらだがlet's encrypt復元とAnsibleデフォルトーパーミッション変更対応テストでコケまくる。セットアップ1時間して一旦落として、実施|
|ConoHa 1G to お名前.com VPS|2020/08/21|08/21 10:22-10:33|secureのsnapshotから復元だが、60分は無理だ！2時間|
|お名前.com VPS to ConoHa 1G|2020/08/28|08/28 10:42-50|Firewalld変更。Apacheログ変更。javaログ出まくり問題解消反映。セットアップ０リセット|
|ConoHa 1G to お名前.com VPS|2020/08/28|08/28 11:37-11:48|setupから間髪入れずにsecureのsnapshotから復元だが、2時間切れない！|
|お名前.com VPS to ConoHa 1G|2020/09/03|09/03 8:21-30|セットアップから２時間目標を目指す！|
|ConoHa 1G to お名前.com VPS|2020/09/03|09/03 10:40-11:50|GPGキーの問題で伸びてしまう！|
|お名前.com VPS to ConoHa 1G|2020/09/08|09/08 16:24-32|GPGKEY問題解消確認とxtrabackupインストールチェック|
|ConoHa 1G to お名前.com VPS|2020/09/08|09/08 17:15-17:25|セットアップから2時間でだが、この場合はほぼ余裕なし！|
|お名前.com VPS to ConoHa 1G|2020/09/15|09/15 9:33-40|もはや毎週恒例。td-agentが今回の目的！バージョン上がりすぎてその場でエラー対応とかあったけど事前にできるだろう！|
|ConoHa 1G to お名前.com VPS|2020/09/15|09/15 11:01-11:11|間髪入れず1時間で折り返す。secureからスタートで2時間行けそうだったが仕事で会議並行なので安全みて3時間|
|お名前.com VPS to ConoHa 1G|2020/09/23|09/23 17:16-24|家のIP更新ができてなく、jartic手動移動で後で原因究明！|
|ConoHa 1G to お名前.com VPS|2020/09/23|09/23 17:40-17:50|間髪入れず1時間で折り返す。secureからスタートで2時間行けそうだったが仕事で会議並行なので安全みて3時間|
**2019 [#w2715624]
|項目|計画日|実施日|備考|
|お名前.com VPS to KAGOYA V2 KVM|2019/01/09|01/09 10:01-10|GeoIP.dat形式が古すぎて404になってた&本業アタフタで２日間稼働|
|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|２４時に構築＆移行して、元のVPSは朝の間にコンバート、昼に構築して夜に１日で戻す黄金パターン。久々なので手順忘れて、せっかく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|果たして１時間で成功するか？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|結局３時間利用したが、焦りすぎて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|前日に１時間ほどで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|
**2018 [#g0fac5d7]
ついにさくらの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/10-11のjarticを失う|
|Sakura to お名前.com VPS|2018/03/28|03/28 23:00-10|今月4度目！大丈夫だろうと45分にDNS切り替えたら20分程度で伝播してＤＢ移行前に切替発生でエラー。あと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手前まで３０分と思ったたら、なんと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系のバッチがこけるこける！１日後発覚なので反省せよ！Lifeに至っては20日後に発覚という・・|
|お名前.com(7.5) to kagoya 2G|2018/09/24|09/24 00:45-25:00|たまに流してないとダメなので！しかし０時から始めたらmvn compileが時間かかり中断。４５分ギリでナンとか間に合わす|
|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|半日様子見てスワップなしでは厳しいと判断したが、スワップあれば平気。と思った２日後にlost connection３−４回でやっぱり厳しいか？|
|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||
**2017 [#qd672008]
|項目|計画日|実施日|備考|
|Sakura 移行|2017/01/15|01/15|思い立ったら１時間で実施！|
|Aaure A2移行→A1へ|2017/02/06|02/06|事前にセットアップまで終えておき、一気に切り替え移行元がSakuraだと余裕。課金切れ伸ばすべくA1へ変更だが１０分かかる。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過去２年ロスト発覚！|
|さくらのクラウド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 復活で１２日夜に実施。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が原因と判明するまでに１日|
**2016 [#o5751779]
|項目|計画日|実施日|備考|
|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含め全移行。６日夜停止でA2は一日約４００円！|
|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同居しても問題なし！月替わりの計算だと１０００円以上残して１ヶ月持つがこれはあてにならん！|
|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のリダイレクトの設定がまずかったようだ。二回もキャッシュクリア。移行は１３分で終わったが途中で切れやがった！|
|Azure A1 to A1 移行|12/19|12/20|MariaDBが落ちたのとFirewalldが止まっていた期間があったため、今回は段階移行の練習。エクスポートインポート20分でDB段階移行5分。またjavaパスとクラウドフロントリダイレクトループミスあり|
**自宅サーバーを一時的に使う計画 [#oda1948b]
-セットアップは最低限とする
-MySQLはslave稼働しておき、切り替えるだけにする。
-昔あった切り替えタスクとread_onlyを外す（入っているはず）を手元で練習だな。あといい加減IPで持ったほうが良い
|www.rutake.com|完全に家でも良い|
|wiki.rutake.com|完全に家でも良い|
|tools.rutake.com|DBのみVPSに向ける|
|blog.rutake.com|負荷次第だが、ちと長時間は厳しいかな？|
**MySQL再起動問題 [#t3403805]
再起動に5分。recoveryの後Index再作成でも走るのかと思ったが、シャットダウン時に落ちないプロセスがいて終了を待っていた模様。バグと出ていたので再発するようであればリブートはなくす方向で！3/28のみ発生。3/30は発生せず
**MariaDB落ちる問題 [#e621c567]
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化全体計画 [#m8bcd654]
|項目|計画日|実施日|備考|
|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は午後までに移行。起動スクリプトコミット漏れ発覚で注意|
*2012/04 [#i78bc206]
さくらのVPS512から1Gへ移行。
**スケジュール [#r33a9b11]
-2012/04/04
apacheコンテンツ移行。DBインポート完了。設定まだ。wiki.rutake.com移行完了
-2012/04/05
DB設定完了。cakephp,blog.rutake.com移行完了
-2012/04/09
SVN移行完了。SSLはIP指定をしているのでそこを変えないといけなかった。
-2012/04/11
Cronジョブ移行。バックアップでDBパスワードが変わっていたためそれなりにシェルを変更
**トラブル [#kb24b02b]
-PostgreSQLのEUC_JPのＤＢを作成するときにそのままだとエラーが出るようになった。-T template1で回避
-PostgreSQLの仕様変更により、date型をsubstrする場合は明示的にtext型にする必要が生じた。substr(userdate::text,4,3)
-MySQLの全部のデータを移行したが、ユーザ認証のみできない。コマンドラインから権限変更もできない状態だったので、phpMyAdminから該当ユーザ削除→追加で復旧。後日flush privilegesでＯＫということが判明
*2013/07 自宅内サーバー移行 [#kb36d165]
一か月かけて準備。普段からrsyncでデータの同期はとっていた。
**トラブル [#b2ba146d]
IP変えて再起動したら反応せず。コンソールから復旧させたが、原因不明だった。
ファイヤーウォールでSquidのポートを通していなかった。こちら設定漏れが多いので注意。Sambaのユーザー移行漏れ！
*2013/12 さくらVPS再構築 [#hde59188]
**下準備 [#nf5415ef]
まずは、それほどアクセスのないページや自分専用コンテンツなどを自作サーバーに移行する。基本的にhttpd.confとssl.confを持ってきて、SVNのアクセス制限元を変更するぐらいで動いた。ssl.conf持ってこないとSSLに強制接続になるので今後の課題。
**移行対象 [#w0a4193e]
+tools.rutake.com以下のアプリ
+wiki.rutake.com
**要塞化 [#m034be80]
-SSHDのアクセス元制限。ポートを閉じる。
**tools.rutake.comのpostgres移行 [#l97e164c]
+postgres自動起動の設定
+DBインポート(DB作成必要)
+PHPツール移植(ツールは問題なしだが、DB接続で下記問題発覚)
-トラブル発生
psql: FATAL: Ident authentication failed for user "postgres"
SQLSTATE[08006] [7] FATAL: Ident authentication failed for user "postgres"
-pg_hda.confを下記のように編集し再起動。ローカルからのUNIX接続をOKにした。
# "local" is for Unix domain socket connections only
local all all trust
-PHPからの接続は元の設定をコメントアウトし、パスワード認証をかけるようにした。
#host all all 127.0.0.1/32 ident sameuser
host all all 127.0.0.1/32 md5
-12/4 toolsのpostgres部分移行完了(一部svn登録モレモジュールがあり消滅･･･)
-CakePHPをTools配下へ移植
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
-12/5 cakephpのツールを移行完了。残る大物はblogのみ
-12/7 バックアップを実施だが、mysqlがパスワードなしでバックアップできている理由が不明。コマンドラインにもろ記載が後日判明
-12/30 blogの移行テスト。DB移動とblog以下一括移動が一番楽とのことでそれで実施。コンテンツ領域20MとDBが2M
目的のディレクトリの一階層上に移動
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
-12/31 空室情報取得バッチの移植に苦労。理由は<?phpを入れてなくてバッチ実行クラスが見つからないというなんとも初歩的なもの。翌日に移植完了とhtml形式の違いで取得できなかったものにも対応。
-1/1 テーブル移行
移行元
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
-1/1 httpdのカウントテーブル作成
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 ',';
-1/6 svn移行
svnadmin dump /home/svn/repos | gzip > /var/tmp/myrepos.tar.gz
-1/6 夜移行
サーバー再インストールからコンソール上がりきるまで10分は見ておいたほうがよい。DNSがなかなか切替わらず見切り発車で実施。SSLの秘密鍵のバックアップを忘れてSSL月だと起動失敗したのでSSLは後日。blogとwikiは移行完了。cronの改行コードがおかしくてエラーとなっていた。LFじゃないとＮＧ
-1/16 セキュリティ設定
SVN移行,hosts設定,
-1/17 IP設定
210.148.59.13,serverToken除去,php.iniの設定変更など
*移行漏れ [#m739996b]
SSL証明書,.htpasswd
*移行前の下準備 [#b99b4b1c]
+公開鍵のバックアップ(OK)
+blog関係バックアップ
+cron関係チェック(OK)
+yumの履歴(OK)
+SVNバックアップ(OK)
-2/4 UTF-8移行
createdb homedb_uft -E UTF-8 -T template0
ダンプSQLをUTF-8に変換
SET client_encoding = 'UTF-8';
-4/19 cakephp戻し
データベース移行は順調。
シンボリックリンクを介してのリライトはＮＧのようなのでディレクトリ名変更
DBアクセス。ユーザーを追加していなくてアクセス失敗。
simple_dom_htmlライブラリを入れてなくて失敗
-6/02 pukiwiki更新検討
*2015/04 攻撃を受けてセキュリティ強化とアプリケーション分離と作り直し [#f517d5fa]
**基本方針 [#r20f5c21]
内部向けは自宅サーバーにおいておくか？
wikiはアクセス数が減少しているのでどうする？
旧MTのコンテンツを廃止したい。
**対象 [#k17c1894]
**作業手順 [#te71317b]
**トラブル [#i72ea941]
*2015/11 一部アプリケーション分離 [#da7a7b5b]
**移行スケジュール [#x3598b57]
|11/17-12/07|KAGOYA VSPでCentOS7検証。wiki|
|12/07-|Azureにてより自動構築重視の設定。wiki,postgresqlのtools|
**Ansible状況 [#pcaaab93]
|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だとセットアップ５分、リカバー２分で終わる|
***チェックリスト [#uf6ff65a]
+認証周りがキチンとされているか?(管理画面に入ること)
+旧コンテンツ(blog/techmemo)やwikiのリダイレクトが完璧であること。
+アクセス制限が移行されていること
***postgresのユーザーに権限付与(シーケンスリード権限がなかった) [#h6742e68]
GRANT ALL ON テーブル名 TO ユーザー名;
GRANT ALL ON シーケンス名 TO ユーザー名;
***cron移行周りのはまり（現在進行中) [#pc9505e3]
-ntpdateが見えない
フルパスに変更
-さくらでaws configureの内容が見えてない。翌日cron経由だと動かなくて発覚。
→単なる設定ミス。
aws s3 lsで設定の確認をすること
-未解決
/etc/cron.daily/s3_backup.shがさくらだけ上記のエラーがでる。
5分ごとに実行だとでないのに！
*wordpressのサブディレクトリからサブドメインへ移行 [#v9577c13]
+http://blog.shun-ichiro.com/howto/move-wordpress/
#counter
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
