![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
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バッチ全部こけて１０時間ロスト |
| 2019/02/06 20:15 | DNSに影響されるバッチなのか移行後にバッチデータが旧サーバーにimportされること二回。手間取って24:05までKAGOYAサーバーにDNS向いてた |
| 2019/04/23 07:00 | jarticのコピーを早くやりすぎて自分のtoolがコピーされない事態に！！最後にやれ！ |
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 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してから再実施 |
| KAGOYA V2 KVM to お名前.com VPS | 2019/05/21 | 05/21 09:20-35 | centos7.5でもdnfダメ。手動upgrade後にsnapshot取得後convertで60分！順調だったので通勤往路で完璧！ |
ついにさくらのVPS卒業！
| 項目 | 計画日 | 実施日 | 備考 |
| 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 |
| 項目 | 計画日 | 実施日 | 備考 |
| 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が原因と判明するまでに１日 |
| 項目 | 計画日 | 実施日 | 備考 |
| 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パスとクラウドフロントリダイレクトループミスあり |
| 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じゃないとＮＧ
SVN移行,hosts設定,
SSL証明書,.htpasswd
createdb homedb_uft -E UTF-8 -T template0 ダンプSQLをUTF-8に変換 SET client_encoding = 'UTF-8';
データベース移行は順調。 シンボリックリンクを介してのリライトはＮＧのようなのでディレクトリ名変更 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だとセットアップ５分、リカバー２分で終わる |
GRANT ALL ON テーブル名 TO ユーザー名; GRANT ALL ON シーケンス名 TO ユーザー名;
aws s3 lsで設定の確認をすること
/etc/cron.daily/s3_backup.shがさくらだけ上記のエラーがでる。 5分ごとに実行だとでないのに！
