CORESERVERアカウント統合

phpMyAdmin 3.5.6へバージョンアップ
・実際は、「phpMyAdmin 2.10.1」からの「差し替え」
※メモ(2.1.0→3.5.0)

---

1.ダウンロード
・phpMyAdmin-3.5.6-all-languages.zip

2.(何かあっても戻せるよう)既存ディレクトリをリネーム
▼/public_html/log/phpmyadmin_20130208/
・「phpmyadmin」→「phpmyadmin_20130208」

3.設定ファイルコピー
・既存「config.inc.php」をコピペ配置

4.リネーム後、アップロード
▼/public_html/log/phpmyadmin/
・「phpMyAdmin-3.5.6-all-languages」→「phpmyadmin」

---

・後は、確認して終了のはずだったのだが、ここで、30分近く悩む
・リンククリックすると、「/log/phpmyadmin/」へ確かにアクセスされるんだけど、リダイレクトされるような感じで一瞬画面がチラついた後、すぐに真っ白へと変化し、ずーとその状態が続いたまま
・どゆこと？
・アドレスは合ってるのに…
・クッキー削除してもダメ
・ログインし直してもダメ
・「config.inc.php」の書き方が変更されたのかと思い、「config.sample.inc.php」見てみるも不明
・前回メモ見ても、これでイケるはずなんだけど…
・もしかして、「3.5.0」と、「3.5.6」は違うの？
・関係ないと思ったけど、「履歴」「キャッシュ」等、全削除してもダメ
・どーゆーことよコレ？ てイライラがピークに達した時に、気付いた
・アレ？

「phpmyadmin」じゃなくて、「phpMyAdmin」になっとる！

・修正したら、無事、イケました
・何かもう、「ホント頼むよ、オレ」、て感じです ……

1.「提供サブドメイン設定ページ」へアクセス
・ログイン後、「CORESERVERアカウントの登録・管理・購入」リンクをクリック

2.「移行対象提供サブドメイン」を一旦削除
・「移行対象提供サブドメイン」をメモした後、一旦削除

3.「移行対象提供サブドメイン」を登録
・移行先アカウントで、先程メモした「移行対象提供サブドメイン」を新規登録

※「提供サブドメイン」自体の説明はこちら

▼/public_html/log/phpmyadmin/config.inc.php
・「移行対象先アカウント」の「config.inc.php」へ追記後、アップロード

・「移行対象先アカウント」コントロールパネルにて、空のDB作成
・今回大量に移行するので、混乱しないよう、極力「DB名」「パスワード名」を変更しないようにする
・2日がかりでやっと終わる
・1件1件、コンパネよりDB作成するしかないので、非常に面倒な作業

・ここまでは順調
・問題はここから

---

「サーバー間コピー」検討する理由
・下記「注意書き」から、当初利用しない方向で検討していたが、一部でパミッションが維持される、という情報もあり、だったら挑戦してみようか、という気になった

---

懸念事項
・DB更新ストップせずに「アカウント統合」するのは難しいので、ここからの作業は一気に行わなければいけない
・今回実施は、データ移行ではなく、アカウント統合。既存ディレクトリ名が被っている場合はどうすれば良い？

---

被っているディレクトリ名
問題なし … 上書き前提
▼/lib/sessiontmp/
▼/lib/smarty/
▼/local/lib/
▼/log/

要検討
▼/lib/PEAR/ … ▼/lib/PEAR/pear.conf。移行先ファイルは大昔のアカウント名でもはや不要
▼/Maildir/
▼/public_html/log/ … 移行しない。但し、▼/public_html/log/SQLiteManager-1.2.4/は移行
▼.bashrc
▼cron_amazoncache.sh … CRON
※「サーバー間コピー」は、同名ディレクトリやファイルが存在していた場合、どういう挙動をするのか？
・「転送方式 ?」見て気が付いたんだけど、特別なことをしているわけではなく、ただのFTPなんだね
・つまり、今回のケースで言えば、「ミラー」とか使えない(利用した瞬間に目の前が真っ暗になると思われ)
・該当転送方式は、「差分」？ ただ、これだと上書きはされないわけね
・うわー、めんどくせー
・普通に、全ファイルコピーしてくれればいいんだけど。そう言うのは普通にFTPでやれってか。それでもいいんだけど、そうすると、今後はパミッションを改めて設定するのが面倒
・大体、FTP利用している「サーバー間コピー」で、本当にパミッションが維持されるの？
・もしかして、SSH接続して、scpコマンドでいける？

疲れてきたので明日もう一度考えるがとりあえずの方向性
・「サーバー間コピー」差分利用
・まずは、簡単なディレクトリで試してみる
・「名前が被っているディレクトリ」については、とりあえずリネームしておき、後で手動対応

全データベースバックアップ保存
※事前に、過去に保存した「dump」データを整理しておく
※「作業中」「作業終了」ステータス確認手段はない

CORESERVER凶悪仕様
・「全データベースバックアップ保存」したデータは、ファイル名変更しないと「コントロールパネル」より、復元できない。理由は、個別保存した場合とファイル名が異なる仕様になっているから。具体的には、「_ユーザー名」を削除しなければいけない。分かるかそんなもん！
・結局、リネームが必要なため、ダウンロード後、ファイル名一括変更
・また、要件不明だが、ある一定以上のテーブル数、もしくは容量のdumpデータは、「コントロールパネル」から保存できない。その際、ファイルが出来なかったり空だったら、dump取得失敗に気が付くのだが、テーブルが空のdumpデータが作成されてしまう(ファイルサイズも存在する)ため、余計に紛らわしい。もちろん、エラーメッセージも表示されない

---

phpMyAdminでのエクスポート失敗
・上記大容量(?)DUMPデータは、phpMyAdminでも取得不可
・もちろん、失敗しても、エラーメッセージ等は何も表示されない

---

SSH接続後、コマンドで、DUMPデータ取得
・大容量データは、最終的に、この方法で取得するしかないらしいい
・ところが、超久しぶりにコマンド打つためか、何遍やっても、マニュアル見てね、エラーになる
・原因は、MySQLへログインした状態でdumpデータコマンド打っていたから
・それにしても、もう少し気の利いたエラーメッセージ表示させてほしいものだ
ユーザ名@サーバ名:~> mysqldump -u データベースユーザ名 -p データベース名 > 任意ファイル名dump.sql;
・これで、ようやくイケた、と思ったら、何だよ。またエラーかよ！
mysqldump: Got error: 23: Out of resources when opening file './★/■.MYD' (Errcode: 24) when using LOCK TABLES
--skip-lock-tables をつけてmysqldump実行
ユーザ名@サーバ名:~> mysqldump --skip-lock-tables  データベースユーザ名 -p データベース名 > 任意ファイル名dump.sql;
Enter password:
・ようやく取得できた
・やっぱ、コマンドが最強なのかー

・ローカル＝移転先
・リモート＝移転元
・移転先サーバ管理画面より、リモートFTP「ID」「パスワード」入力
・今回は、統合なので、差分(削除なし)選択

事前に、移転先で、名前が被る「ディレクトリ」や「ファイル」は、念のため、リネームしておく
・000_lib
・000_local
・000_log
・000_Maildir
・000_.bashrc
・000_cron_amazoncache.sh

---

「サーバー間コピー」実行

気が付いたこと(処理中)
・処理が走っている間は、更新する度に、「▼/」に作成される「.servercopy.log」ファイルサイズが随時更新されていく。また、「.servercopy.sh」が表示される

「処理終了」確認方法
・更新しても、「.servercopy.log」ファイルサイズが変動しなくなる
・「.servercopy.sh」が表示されなくなる
※但し、上記は「30分を超える場合は、一旦終了されます」の場合も、影響を受けるものを思われ
・最終的には、ファイルを開き、最後に下記表示があるか、要確認

気が付いたこと(処理後)
・ファイルの最終更新日時も維持される

---

失敗した点
1.「移転元」にある不要なディレクトリ
2.「/public_html/log/」ディレクトリをリネームし忘れ

1.「移転元」にある不要なディレクトリ
・ただのディレクトリだったらまだ良かったのだが、元々「移転先」にあったディレクトリがそのまま今回の「移転元」に残っていた
※以前、「移転先」→「移転元」へサーバ間コピーしたことがあるため
・既に「移転先」ではデータ更新しているため、今回の措置により「移転元」に残っていた古いディレクトリが、コピーする際上書きしたらOUT
2.「/public_html/log/」ディレクトリをリネームし忘れ
・移転先の「▼/public_html/log/phpmyadmin/config.inc.php」ファイルは重要なので、リネームしたつもりが、「▼/log/」と勘違いして、結局、リネームし忘れた

---

失敗による影響
・下記にある通り、差分(削除なし)「サーバー間コピー」では、ファイルが上書きされることはない
差分(削除なし)
1.「移転元」にある不要なディレクトリ
・ファイル上書きは免れたが、かつて存在して途中で不要と判断したファイルがコピーされたかもしれない
・「.servercopy.log」で検索してみたけど、件数が多過ぎて対応不可。どうやら、アンインストールしたモジュール絡みが大半のようで、余計なファイルは増加したが、ファイル自体上書きされているわけではないので、このまま放置することにする
2.「/public_html/log/」ディレクトリをリネームし忘れ
・同名ファイル名は上書きされないので、大勢に影響なし
※同名ディレクトリとか、全く関係なく、フィイル名が同じか、だけで判断している
・「/public_html/」内で同じファイル名があればスルー。なければファイルコピーする仕様

---

リネーム戻し
・000_local … 重複している内容はなかった。移転先にあった「▼/local/lib/dojo150/」を統合して終了
・000_log … 中身空に付き、片方削除
・000_Maildir … 中身同じに付き、片方削除。恐らく以前サーバー間コピーした際の名残がそのまま残っているものと思われ(その後、メール未利用)
・000_cron_amazoncache.sh … 下欄参照
.bashrc
・移行元

export GEM_HOME=$HOME/packages/lib/ruby/gem

export RUBYLIB=$HOME/packages/lib/

export PATH=$PATH:$HOME/packages/bin

・移行先

export PATH=$HOME/local/bin:$HOME/lib/PEAR/PEAR:$HOME/lib/ZendGdata/library:$HOME/lib/ZendGdata/library/Zend:$PATH:$HOME/local/lib/ruby/gem/bin:

export RUBYLIB=$HOME/local/lib/:$HOME/loca/lib/ruby

export GEM_HOME=$HOME/local/lib/ruby/gem

・移行後 … 一つ一つ確かめていくのはしんどいので、とりあえずくっつけてみた

export PATH=$HOME/local/bin:$HOME/lib/PEAR/PEAR:$HOME/lib/ZendGdata/library:$HOME/lib/ZendGdata/library/Zend:$PATH:$HOME/local/lib/ruby/gem/bin:$HOME/packages/bin

export RUBYLIB=$HOME/local/lib/:$HOME/loca/lib/ruby:$HOME/packages/lib/

export GEM_HOME=$HOME/local/lib/ruby/gem:$HOME/packages/lib/ruby/gem

lib
・「▼/lib/sessiontmp/」「▼/lib/smarty/」は重複分がないため、片方削除
・問題は、「▼/lib/PEAR/」ディレクトリ
・パッと見、移転先の方が古い感じなので、統合はせず、移転先の方は予備として保管しておくことにする
・「PEAR」は、以前設置したサイトで利用しているのかもしれないが、詳細不明
・「bin」パスとか見たら、移転先内容は、ずっと以前に変更する前のユーザー名のままのようだ
・不要な物は随時削除していかないと、ファイルは肥大化して、後で収集つかなくなるから。今みたいに！

CORESERVER凶悪仕様
・データベース復元に失敗しても、エラーメッセージを表示しない

・エラー頻発するため、phpMyAdminでのインポートを断念

※データベース数が多い場合、phpMyAdminより個別インポートしていく方法は、想像を絶するくらい大変
・理由は幾つもあるが、その最たるものは、並び順
・CORESERVERコンパネだと、作成日時順で表示されるが、(全データバックアップした)DUMP取得データにその概念はないため、選択する際、気が遠くなるぐらい大変な思いをする

---

・後日、復元モレを1件発見
・サイトへアクセスしたら、DBテーブルが存在しないので、画面真っ白になっていた
・コンパネに番号が振られていないので、DB件数が多いと非常に作業しづらい
・もしかしたら、まだモレがあるかもしれない
・2/21 … 復元モレ、新たに1件発見

・VALUE DOMAIN:バリュードメイン (ユーザー名:★★)
・DNSレコード/URL転送の変更
・当サービス内サーバーの自動DNS設定
・ドメイン選択
・変更前

a * ◆◆◆.◆◆◆.◆◆.◆◆

mx @ 10

txt @ v=spf1 ip4:◆◆◆.◆◆◆.◆◆.◆◆ ~all

・変更後

a * ◆◆◆.◆◆◆.◆◆.☆☆

mx @ 10

txt @ v=spf1 ip4:◆◆◆.◆◆◆.◆◆.☆☆ ~all

・「サーバー側でのドメインウェブ設定」意味分からず

9.ドメイン設定

▼/cron_amazoncache.sh
・「移行前」も「移行後」も内容は同じだった(リネームする必要なかった)

#!/bin/sh



#SHELL

cd /virtual/★★/public_html/

find . -type f -regex '.*/amazon/cache/[^/]*' -exec rm -f \{\} \;

exit

---

・その他については、コンパネ「CRONジョブ」メニューより、1件1件コピペしていくしかない

・phpMyAdmin開いただけでエラー表示されるようになってしまった

▼/public_html/log/php.ini

memory_limit = 256M

▼/public_html/log/.htaccess

php_value memory_limit 256M

・効果なし
・相変わらず、エラー表示され続ける

管理画面 … 「/public_html/log」ディレクトリに解析済みログを保存する
・止める
・同ディレクトリ内不要ファイル削除
・サイズ … 167MB
・ファイル数 … 6119ファイル
※ドメイン変更した場合、過去のアクセスログは、手動で削除しない限りそのまま残る仕様らしい

---

・効果なし
・相変わらず、エラー表示され続ける
・phpMyAdminが利用できないのは痛いわ
・phpinfo確認したら、「memory_limit 90M」になっていたので、「php.ini」「.htaccess」90Mへ変更

疑問
・memory上限は、90M？ それとも単に指定の仕方が悪いだけ？
・上限を超えるメモリ指定したら、どうなるの？


・つまり、90MBは越えられないってこと？
・つまり、この状態では、phpMyAdmin利用不可
・理由は、テーブル数が多いからってこと？
・おいおいおいおいおいおいおいマジかよ！
・もの凄く苦労して、統合したのに、今更元に戻せってか
・何か方法ないのかよ！

・そんな数全然いってないよ
・第一、データベース作成できても、メモリ制限で呼び出し出来なかったら、意味ねーじゃんよ
・それかアレか。phpMyAdminバージョン上げたからメモリ食うようになったとか、もしかしてそういう話？

---

・その後、色々試して、以下のことが判明
・「php.ini」は設定しなくても、「.htaccess」だけで数値変更可
・但し、「php_value memory_limit」を、一番先頭に記述しなければいけない(少なくとも、AuthUserFile より後では不可)
・記述方法は、「php_value memory_limit 256M」「php_value memory_limit 512M」「php_value memory_limit -1」など
・「php_value memory_limit 256MB」とBを付けると変更されない
・変更値は、phpinfo内 Configurationの「PHP Core」 Directiveme「mory_limit」の「Local Value」で確認可能
・但し、ここが重要な点だが、この変更された値がそのまま適用されるわけではなく、サーバに送信された段階で恐らく上限値でリミットカットされるもの、と思われる
・つまり、実質的には、ローカルで数値が変更されただけで、サーバ側にその変更は反映されない仕様。つまり、90MB制限は越えられない
・Local数値は変更されるが、実質変更できないという状況は、ここと同じ。もの凄くがっかりしたよ
・どうしようもないから、とりあえず、サポートへ問い合わせたけど、過去の経験上、スルーされるか、無理です、て言われるかの何れかだろう
・そうすると、どうなるんだ？

---

残る選択肢は？
1.元に戻す
・アカウント統合する前の状態に戻す

2.phpMyAdminバージョンを下げてみる
・phpMyAdmin利用時のみ発生している
・バージョンを下げればもしかしたら利用メモリが減るかも？ という何の根拠もない推測に基づく

3.phpMyAdmin以外のGUIツールを探す
・メモリを食わずに、DB操作できるツールは何か他にないの？

4.サーバ移転
・「CORESERVER」「XREA」より完全撤退
・何れは実施するつもりだけど、今すぐは無理

5.データベース削除(もしくは整理)
・削除するためにも、中身の確認は必要
・何れは実施するつもりだけど、今すぐは無理
・しかも原因が、「データベース数」にあるのか、「テーブル数」にあるのか、「データ量」にあるのか不明なため、非常に手を付けづらい

6.「config.inc.php」を整理、もしくは都度変更
・読み込み時にメモリを食うのであれば、読み込む対象を減少させれば良いのではないか
・例えば、面倒くさいけど、必要なものだけを都度読み込むよう、「config.inc.php」を操作する、とか

---

・結局、6.「config.inc.php」を整理、もしくは都度変更でいこうと、色々触っている内、いつの間にかエラーが表示されなくなった
・あれ？ と思い、エラーが表示されていた状態に戻してみても、やっぱり何も表示されない
・いや、これで正常で状態なのだが、今度は逆に、何で急にエラーが表示されなくなったのかが解せない
・キャッシュ？ メモリにキャシュとかあるの？

・結局、原因不明
・それにしても、Fatal error: Allowed memory size は昨日から出続けて、その都度処理が強制中断するからイライラさせられっぱなしで、調べること少なく見積もっても4時間強
・それなのに、挙句の果ては、何時の間にか直ってました、だァー、そんなの許されるわけがない、オレ的に
・もう、何か脱力感が凄い。色々と…

・パミッション維持されてないじゃん
・画像保存しようとしたら、いきなりエラーかよ！
▼/img/
・「777」 → 「775」になっとる
▼/xoops_trust_path_◎◎/cache/
▼/xoops_trust_path_◎◎/session/

・今、2013/02/18 11:0217：46
・パミッションは、件数が多いので、気が付いた都度変更することにしたので、とりあえず、移行が一旦ようやく終了したよ
・作業開始してから、10日経過後にようやくできたわ

---

しんどかったことランキング
・実際に作業してみてしんどかったことランキングを発表
・ちなみに、過去に一度「サーバ間移行」経験あり
・今回のような統合を実施したのは、初めて

---

1位 … 「全データベースバックアップ保存」すると、コントロールパネルより、復元できない
・ファイル名を変更すれば復元できるのだが、パニくってたこともあり、気が付くまでもの凄い時間がかかった(一度諦めphpMyAdminでインポートしていったら、あまりの件数の多さに途中で挫折した)

---

2位 … 「Fatal error: Allowed memory size」エラー
・結局、最後までエラー解決できず (いつの間にか表示されなくなったが、理由は最後まで不明)
・借りてるプラン毎に「上限制限値」が存在し、それを越えることは(恐らく)出来ない … CGIモードへ変更すれば可能。下欄参照
・CORESERVER プランだと、「memory_limit 90M」
・phpinfoで確認できる

---

3位 … パミッションが維持されない
・維持されているのもある？
・件数が多いと、かなり大変
・詳細は、これから見ていく(というか、もう面倒くさいので、気が付いた都度、随時変更していく)

---

4位 … 「データベース作成」及び、「データベース復元」
・コントロールパネルより、1件1件行うしかない
・件数が多いと、かなり大変

しんどさの割合を100%で表すと、体感的には大体こんな感じ
・1位 … 「全データベースバックアップ保存」すると、コントロールパネルより、復元できない … 50%
・2位 … 「Fatal error: Allowed memory size」エラー … 35%
・3位 … パミッションが維持されない … 6%
・4位 … 「データベース作成」及び、「データベース復元」 … 4%
・その他 … 5%

・経験値を積んだから次やるときはもっとうまくやれると思うけど、正直、CORESERVER間の移行はもうないと思う(さくらVPSへ移行予定)
・CORESERVERには、いい加減うんざりです……
・今回についても、結局、バッドノウハウしか身についていない気がする(この経験値を他で活かせない)

・内容も適切だったけど、それよりも何よりも、あのCORESERVERサポートから、返信が返ってきたことに驚いた。しかも、「問い合わせ翌日」に
・どうしちゃったの？ CORESERVERって感じ

・回答内容で初めて知ったのだが、「php.ini」は、CGI版PHPでのみ有効
・具体的には、「.htaccess」で「CGIモード」指定すれば、「php.ini」を読み込み、その内容が反映される
▼/virtual/★★/public_html/log/.htaccess

AddHandler application/x-httpd-phpcgi .php

AuthUserFile /virtual/ibj/public_html/log/.htpasswd

AuthGroupFile /dev/null

AuthName LOG

AuthType Basic

<Limit GET POST>

require valid-user

</Limit>

▼/virtual/★★/public_html/log/php.ini

memory_limit = 512M

・この状態で、「▼/virtual/★★/public_html/log/phpinfo.php」を設置し、ブラウザよりアクセスすれば、「memory_limit」の値が、「Local Value」だけではなく「Master Value」も、512Mへ変更されていることが確認できる

・ちなみに、「memory_limit」の値が、「90M」から「512M」へ変更されてびっくりするぐらい起動が早くなったかと言えば、体感的には全くそんなことはない
・ただ、「Fatal error: Allowed memory size」エラーで処理が途中で強制終了することがなくなったので、ストレスを感じなくて済むようになった
・めでたしめでたし

---

サポート体制が改善された？
・ちょっと不明点があったので、ついでに再問い合わせをしたら、また翌日に、返信が来た
・これはどういうことなのだろう？
・考えられるのは、サポートの外部委託先を変更した？ あるいは、運営体制自体が変わった？

以前、大規模障害が発生した際、ネットで見た都市伝説
・XREA立ち上げた頃のネットワークに詳しいメンバーはとっくに居なくなり、今の会社に技術が詳しいメンバーはほとんどいない。もう終わった
・今のCORESERVERは、XREA立ち上げた組織とは、全くの別会社

・真意の程は定かではないが、サポート機能があまりにひどかったのは、事実だと思う
・それが、いつの間にかまともになってる！
・どうしたの？ 一体…

---

確認済事項
・「.htaccess」CGI設定により、「php.ini」でのメモリー変更値を認識していることを、phpinfo「Master Value」で確認
・「user.ini」はPHP5.3以降でのみ利用可
参照URL
http://php.net/manual/ja/configuration.file.per-user.php

未検証事項
・モジュール版の場合には、「.htaccess」ファイルにて、php_value ディレクティブを利用
参照URL
http://php.net/manual/ja/configuration.changes.php
※php_value にて設定する場合、ディレクトリ内に php.iniならびにunser.iniが存在していると動作が不安定になる。名前を変更、もしくは、削除しておく