2012年9月28日
しもブロ移転
[ReTweet This!] カテゴリ：サーバ移転/下北沢ブ口イラーえすえぬえっす しもブロのサーバを下北沢から大阪のどこかに移転しました。今まで、下北沢の社内サーバでこっそり運営していましたがハードがぶっ壊れそうな予感があったので、うちが使ってるVPSに移転。まー、サーバの電気代だけで5000円くらい、夏の間はエアコンつけっぱなしで1万円弱かかっていたからねー。移転先のVPSなんて月額1480円でスペックも遙かに上。もう、自宅自社サーバの時代は終わりました、、、。
折角なので移転の流れでも書いてみよう。
0.新サーバでテストする、ちゃんと動いてるねー
1.DNSのTTLを短くするよ
2.旧サーバをメンテナンス表示
3.旧サーバのDBをdumpするよ
4.旧サーバから新サーバにコンテンツやらDBdumpデータを移動させるよ（rsync一発）
5.新サーバでDBをrestoreするよ
6.新サーバに仮のホスト名をつけてテストするよ
7.DNSのレコードを書き換えるよ、この瞬間から新サーバにトラフィックが流れはじめるよ。DNSの浸透言うな！ 適切なTTLにしておけば問題ナッシング。アホなbotは延々旧サーバにトラフィック流してるけどな
8.旧サーバ停止もしくは爆破
と、まあ、こんな感じ。ポイントは事前テストでコンテンツとかは持って行っておいて、最後はdumpデータを移行するだけって感じかな。実作業は1時間もかからない、簡単簡単。CentOS5系からCentOS6系への移行だったからちょっとびびってたけど大丈夫だった。新サーバでAPCが悪さをしてエラーが出てたけど、APC自体eraseしちゃえ。
で、同じタイミングで俺の地元の地域SNSが盛大にやらかしていたので(9/19-25までサーバストップ)、バックアップから復旧の流れについても書き留めておく。いや、それにしても大変な復旧作業だったみたいだねーーー。
今回移転したVPSはさくらインターネットのサービスですが、過去にハード障害でVPSごと吹っ飛んだことがあり、フォーマットせざるを得ない状況に合ったので自分たちでバックアップを1日2回取っています、使ってるツールはrsyncで1日2回自動で。ちなみに、バックアップ用のサーバはカゴヤのVPSです。みんなー、Diskのコスパを考えると、カゴヤのVPSがナイスだぜーしかも京都だぜー、おいでやす。ただし、カゴヤは転送量制限が一定量でかかるので、初回のフルバックアップでいきなり転送制限がかかり1Mbpsとかに制限されちゃうから要注意だ。今は、解除されてるけどね。
そして、実際に今のサーバに障害が出たときの対応の話し。
サーバがぶっ壊れたりしたらすぐに監視システム（xymon）からアラートが俺の携帯にメールで届く。内容を確認して、こちらで復旧できるものは復旧作業を行うけど、俺ではどうにもならない場合（bootしない）はさくらインターネットのサポートに連絡して復旧を待ちます。そこで、データが飛んでしまったとか、なんか諸事情で時間がかかるみたいな話になったら、ソッコー代替サーバを準備します。
まずは障害が出ている旨表示するサーバを準備。まー、VPSたくさん借りてるのでそのくらいの表示ならすぐ出来る。そして、新サーバの準備、今借りてる他のサーバを使ってもイイし、VPS・クラウド系で新たにサーバを立ててもいいし。そうだねー、障害のひどさにもよるかなその辺りは。1日くらいで復旧するんだったらメンテナンス表示で乗り切ってもいいけど、なんかもうどうにも埒があかないパターンは新サーバ移行を前提で動くだろうな。で、サーバを準備しつつ平行してデータを京都から新サーバに持ってくる、アクセスログとか無駄にでかいファイルは後回しだぜ、あふぁーん。
そして、最後の判断。バックアップデータは1日2回だから、12時間分のデータは無くなる可能性がある。新サーバを動かしはじめたらそちらにも新たにデータがたまりはじめちゃうので、元のサーバには戻せない。そこはクライアントさんも含めて慎重に検討しちゃおう、まー、クライアントさんも判断できないから俺が判断しちゃうことも多いけどねー。
新サーバ移行を決断したらDNSのレコードを更新して（あ、障害が発生したらそのドメインのTTLはすぐに短めにするんだよー）、新サーバの稼働開始です、あー疲れた、何が疲れるってクライアントさんからバカみたいにたくさん電話がかかってくるからだよ、もー、全力で復旧してるから邪魔にしかならないし実際にその電話に対応していると作業が遅れるからホントにやめてください。
実際にはサーバ復旧が早まったりだとか、いくつかの解決経路があるけど、その経路は複数あっていい。とにかくWebサイトが見れない時間をいかに短縮できるか、サーバエンジニアはそこに全てをかけるわけです。クライアントさんのためにも、そのページを見てくれるコンシューマーの皆さんのためにも、自分のためにも。
実際のサーバ構成はそのサイトそれぞれで違うわけだし、自社でサーバ設備を持っているパターンでは代替サーバがなければメーカーのサポート待ちになっちゃうことも多い。ただ、専用サーバのコストパフォーマンスが劇的に改善している今、自社でサーバを用意することの優位性は薄れつつあると思う。某社の専用サーバが飛んでも、同じハードをいくつも用意しているので1時間くらいでサーバ自体復旧できちゃうからね、凄い時代になったもんだよ。それでも、規模の問題があるだろうから、複数台構成を遙かに超えるパターンは自社で用意した方がいろいろいいんだろうけどね。
で、例のサイトがなんであんな復旧に時間がかかったのか。最初の一報が9月19日17時、そして復旧が25日20時なので実に6日越え147時間近く復旧にかかったんだよね。最初は翌20日に復旧予定だったけど、それが24日に伸びて、22日に旧サーバからのデータの抽出完了と書かれている、、、ん？ 抽出？？ ということは、HDD自体がぶっ飛んでしまったのか？？ でもって、24日から25日に予定が変更されて、夜に復旧したんだよね。
状況から推測する限り、ハードウェアがぶっ壊れた上にHDDもなんかやばいことになった。そして、なんとかデータは取り出せたけど、今度はそのデータが多すぎで新サーバ側への移行に時間がかかった、って感じかな。俺もあのサイト使ってるからよくわかるけど、すんげーデータ量だと思う。フツーにrestoreとか出来ないレベルで、、、。いやー、大変だったんだろうな、ホントにお疲れ様でした。
ファース○サーバでデータが消えちゃった問題とか、俺もさくらに限らずいろいろなサーバで障害によりデータが消えちゃった経験をしているけど、まずはバックアップ、ホントにバックアップ。サーバは壊れる、自社のものでも専用サーバサービスでも、そしてデータが消えることもある。その前提でやらないと絶対ダメだよね、うんうん。
投稿者 ymkx : 2012年9月28日 09:56 |
2011年9月 7日
サーバ移転しました
[ReTweet This!] カテゴリ：サーバ移転とある事情で、急遽サーバ移転しました。いろいろ問題が起きなければいいけど、、、まー、閲覧する側には問題は発生しないと思います。
写真はテストでアップしてるだけなので、特に意味はありません。
投稿者 ymkx : 2011年9月 7日 11:39 |
2011年5月30日
データセンターの電力使用制限緩和が意味すること
[ReTweet This!] カテゴリ：さくらインターネット/サーバ移転/データセンター/電力使用制限問題東日本大震災の影響で、いろいろな発電所がダメージを受けているのは皆さんご存じだと思います。その影響でこの夏の電力供給が足らないとのことで、当初は一律15%の節電が全ての企業に求められていました。15%って簡単にイメージ出来ないのですが、自分の関わるところでデータセンターがこの15%の電力消費を目指すのは相当困難じゃないかな、と、考えていました。
早くからさくらインターネットの田中社長などが、データセンター事業者がこの節電を果たすのは困難と言われておりまして、どうなるのか不安でした。そして、5月25日に経済産業省が発表した電力需給対策の詳細にて、電力使用制限の適用除外と制限緩和の業種を発表し、データセンター事業者は0～10%の制限緩和業種となりました。
正確には、『安定的な経済活動・社会生活に不可欠な需要設備』で『4時間・365日電力使用の変動幅がほぼフラットな需要設備』中の『情報処理システムに関わる需要設備（データセンター、金融機関、航空、通信関係のシステム）』でデータセンター事業者が入っています。
日本経済新聞の総合面にて、さくらインターネットの田中社長は、
「顧客企業のデータを守るうえで助かる措置だ」
とコメントされており、これはさくらインターネットに限らず全てのデータセンター事業者にとっても、必要な措置だったと考えているでしょう。当然ですが、データセンターを利用している我々にとっても、今回の措置である程度心配事が減ったと考えています。
* * * * *
データセンターの電力消費推移についていまいちイメージ出来ないのですが、サーバ稼働台数が24時間で大きく変動するわけではないので、ベースで消費する電力ってのはある程度変わらずに推移していると思われます。当然、処理数が増える時間帯が電力消費が増えるのでしょうけど、真夏の場合は日中の空調設備による電力消費の方が圧倒的に大きいのではないでしょうか。そういう意味では、一般企業と同じような時間帯にどうしても電力を消費せざるを得ないと考えられます。
データセンターが15%の電力消費削減を求められた場合、どのような対応となったのでしょうか？ 一番最初に考えるのは、自家発電でその分の電力をまかなうということですが、データセンターの自家発電装置は一時的な停電などの万が一のための設備であり、数ヶ月間稼働させることを前提に作られてはいないと思われます（推測ですが）。また、稼働させたとしても発電のためのコストは通常の電力に比べれば高くなり、事業者のビジネスを圧迫しかねないでしょう。正直な話し、今回の制限緩和がデータセンター事業者に適用されなかった場合、データセンターというビジネス自体が非常に危うい状況に置かれたのではないかと思われます。
* * * * *
私が管理しているサーバについて、データセンターを利用しているものもありますが、自社に設置しているサーバもあります。なぜ自社に設置しているかというと、単純に運用コストが安いからに他なりません。ネット回線や設置コストなどデータセンターとは比較にならないくらい安いです。当然ながらデータセンターのような耐震性や安定的な電力供給、セキュリティ、回線品質を求めることは難しいですが、提供ビジネスから考えると自社サーバを選択せざるを得ませんでした。
しかし、この夏の節電目標や、大規模停電の発生する可能性、また、現時点では未定ですが電力コストの増大を考えると、自社内にサーバ設置することのメリットはかなり薄れてきたと考えられます。地震によってインフラに被害が発生しサービス提供が出来なくなるリスクも、これまでは低めに見積もっていましたが、今回の震災をうけほとんどのインフラ担当者は自社内にサーバを設置するリスクを高めに考えるようになったのではないでしょうか。
私が管理している社内に設置されたサーバは、震災前に比べ5台ほど削減しました。この削減は単純に電力消費を抑える為（震災直後の電力供給問題に際し）でしたが、残り10数台のサーバについて扱いについてリスクの観点から対応を考えました。いろいろな選択を熟考した結果、思い切ってそのほとんどをデータセンター側に移行しようと考えています。ラックを借りてサーバを設置して自社で管理するのか、レンタルサーバ的なモノを利用するのか、はたまたAWSのようなクラウドを利用するのか未定ですが、どちらにしても自社に設置するサーバは最小限に抑えたいと考えています。
この辺りは正確なことがわからないのですが、現在自社内にサーバを設置している会社の数は少なくないと思います。データセンター専業でない企業については当然ですが、電力制限緩和は適用されず何らかの形で使用電力の削減を行う必要があります
。また、今回の震災で社内に設置されていたサーバが何らかの被害を受けた会社もあるのではないでしょうか。被災地はもちろんですが、被災地からある程度距離のある会社でも、何らかの影響が出ている会社はあると思われます。
地震というリスク、電気が使用できなくなるリスク、様々なリスクを考えるとやはり重要なデータや処理を行うサーバ類はデータセンターに置くことが最もコストが安いと考えるべきなのかもしれません。この辺りは、担当者それぞれで考え方も違うのでは一概にこうだと言うことは出来ないのですが、少なくとも私は自社のサービス、特にWebサービスのようなモノについてはデータセンターに移行させる方向で検討しています。
そこで一つ提案なのですが、データセンター事業者の皆さんは企業が自社内に設置しているサーバをデータセンターに移転することによるメリットを強く打ち出してはどうでしょうか？ 単純に、地震や電力のネガティブリスクを強調するのでは無く、トータルコストではこのくらいしか変わらない、もしくは実はデータセンターの方がコストが安いといった数字があれば経営者としては大歓迎だと思います。その上で、地震などの災害によるコストには出来ないネガティブリスクも解説していただければ、これはある意味データセンターにとって大きなビジネスチャンスではないでしょうか。
また、各企業に設置しているサーバをデータセンターに集約することによって、全体の電力消費が下がるのだったら、これは最大の理由になると思います。この辺りは私の想像で、実際に集約することによって総電力消費が下がらない可能性もあるのですが、空調などの電力消費の点だけでも集約した方が総電力消費は下がると思うのですが、、、。
今回の震災後、データセンターの果たす本来の役割がクローズアップされたと思います。データセンターにサーバやデータを設置するメリットは、震災前とは比較にならないくらい大きなものになっていると思います。データセンター事業者の皆様には、ぜひその辺りの試算を行っていただき、地震大国日本でのサーバやデータの取り扱いについてインフラ担当者や経営者層に理解を深めさせていただければ幸いです。
[参考]
・電気事業法に基づく使用制限の具体的内容について [PDF] 経済産業省 2011/5/25
・電気の使用制限、データセンターは緩和措置 ITmedia 2011/5/26
・データセンター「25％節電無理」 稼働停止危機も ITmedia 2011/4/18
投稿者 ymkx : 2011年5月30日 18:00 |
2010年11月 2日
サーバ移転 その2
[ReTweet This!] カテゴリ：サーバ移転そして、サーバ移転 その1の翌日にやったサーバ移転のお話し。こちらも、2時から開始という、涙が出そうなスケジュール、、、。
サーバ移転 その1はレンタルサーバから専用サーバへの移転でしたが、こちらは某データセンターをクライアントさんが契約していて、その中のサーバ間でサイトの移転を行いました。
なんでそんなコとするの？ って、感じですが、こちらはデザインリニューアルが主でサーバ移転はおまけみたいなモノだったのですが、使っていたサーバのディストリビューションが古すぎてやばかったので、ディストリビューションを新しくして各種サーバソフトウェアのバージョンも一気に引き上げました。予備サーバがあったので、そのサーバに移転するという流れですね。
で、実は10月に先にいくつかのWebサイトが移転してて、今回は残りのWebサイトの移転でした。こちらは受発注システムとかが載っかってて、慎重に移転作業を行わなければならなかったのですが、その辺の作業は別のエンジニアが担当で、私はサーバハード及びソフトの移転作業が中心です。
旧サーバで上がっていたバーチャルIPアドレスを、新サーバに移動するなんてのがあったので、念のためデータセンターで作業をやりました。まー、この作業自体は大したことなかったんだけど一時的に新旧に同じIPが上がっちゃうトラブルがあって、実際の移転作業開始が30分くらい遅れちゃった、ごめんごめん。
このデータセンターはその会社の中では本当に古いデータセンターで、色々な事がレガシーです。ちょっと、ココには書けないようなレガシー感があったりして緊張感満載です、ああ書いちゃダメだこれ以上は。
ちなみに、この日は雷鳴とどろく大雨の中のサーバ移転。データセンター内部は全然無縁な世界ですが、入るときと出るときにずぶ濡れになりました、ギャフン。
で、データセンター内での作業は無事完了して、会社に戻るとエンジニアとディレクターが集中して作業中。私自身は、あまりメインじゃないWebサイト二つを移転して、アクセスログまわりの移転作業。やー、ローカル（ギガビット）で繋がっているのでrsyncとかしたら早いのなんの。数十ギガなんて余裕だぜー。やっぱ、rsyncとかが使える環境は楽だわ。その1の時はFTPしか使えなかっただけに、、、。
移転作業というか移転後のチェック作業が難航していましたが、なんとか予定していたオープン時間にリニューアルしたWebサイトを公開です。やー、本当にお疲れお疲れー。実は、その日は夜まで修正が続いて大変だったんだよね、オレは面接に行ってたけど、、、。
さてと、こちらのサーバ移転はあまり技術的なことを書いていませんでしたが、移転後劇的に変わったことがあったので、そのあたりを書きます。
今回ハードウェア自体のスペックは変更せず、同世代のサーバ間での移転作業でした。移転前がRAID1で移転後がRAID5でRAIDカードが若干違いますが、性能差が大きいわけでもありませんので、そのあたりで改善されたと言うことは考えづらいです。
それじゃー、何が変わったのかという話しですが、OSディストリビューションを変更しました。旧サーバのOSディストリビューションはTurbo Linux 10 Serverという、私のサーバエンジニア人生最大のミステイクだったりします。ああ、堀江師が大活躍だった時代のライブドア信者っぷりが、ここまで悪影響を与えてしまうとは、、、。悪いディストリビューションでは無いのですが、如何せんユーザー数が少なすぎる、、、情報があまりネット上にもなく本当に大変な苦労を強いられました。や、全部自分のせいですよ、ええ。
で、新しいディストリビューションはCentOS5.5。本当はRHELにしたかったのですが、来年サーバリプレイスを予定しているので、とりあえずのつなぎとしてCentOSにしておきました。
kernelは2.6.8系から2.6.18系へ、apacheは2.0.51から2.2.3へ、PHPは4.3.8から5.1.6へ、PostgreSQLは7.4.26から8.1.22と大きくバージョンアップしました。ちなみに、Perlは5.8.5から5.8.8か、枯れてるなぁ（なんか表現が違う気がする）。
で、その結果どうなったのかというと、凄まじくWebの表示が速くなりました。旧サーバでの表示が本当に遅くてイライラしていたのですが、ソフトウェアの更新でココまで速くなるとは予想だにしていませんでした。CentOS5.5なので、ソフトウェアのバージョンは最新ではないのですがPHPやPostgreSQLはメジャーバージョンが違いますからね、そりゃー速くもなるわ。
正直、デザイン的にHTMLのコーディングが変わった部分も好影響を与えていると思いますが、レスポンスが明らかに変わったので本当によかったです。稼働している某受発注システムなどは、イライラが募るようなレスポンスの悪さでしたが今回のシステム更新で受注が増加するのではないかと勝手に期待しています。って、今まで遅かったことを目茶苦茶追求されそうだぁ、、、。
というわけで、大型のサーバ移転2連チャンも無事終了、、、ホント疲れたよ、ホントに疲れた。でも、サーバ移転は自分の本業の力を試されている気分で、気合いが入りました。来年はサーバリプレイスがあるので、再び気合いを入れたいと思います。がんばろー。
投稿者 ymkx : 2010年11月 2日 13:07 |
サーバ移転 その1
[ReTweet This!] カテゴリ：Movable Type/サーバ移転自分自身の備忘録的に、先週の土曜日にやったサーバ移転の話しを書いておこうじゃないか。
某メディアサイトの移転で、F社のレンタルサーバを利用していたけどPerlModuleのインストールが出来ないだとか、アクセス集中でたまに繋がらなくなる事がある為、S社の専有サーバに移転するという案件。メディアサイトなので1日に何件か情報の更新があるのですが、CMSにはMT4を使用。ブログ的な使われ方のコンテンツもあるので、1日の更新件数は多いときは10件前後。総エントリー数は数千件と、まあまあのサイズ。アクセス数は日によってばらつきがある模様だけど、集中したときには本当に繋がらなくなっちゃうとか。画像が多いので、その辺も影響があるのかもしれないですな。ちなみに、全体の容量は2GB弱。
で、MTの移転はここ数年で10数例やっており、MT2.6からMT4へのバージョンアップ＆移転なんていう際物までやっているので、正直怖いものはない。ハズだったのですが、、、。
まずは、現在運用中のサーバ関連情報収集から。F社のレンタルサーバの中では比較的上位のプランで、コストパフォーマンス的には悪くないんだけど、カスタマイズ性が本当に低い。ImageMagickがつかえなんて、ちょっとあり得ないよねぇ、、、。
コントロールパネルが一通り揃っておりphpMyAdminが使えるので、MTで使用しているMySQLをdumpして新サーバでrestoreが最初に考えた移転方法。試しにphpMyAdminからdumpしてみるも、どうも文字コードの問題でうまくdump出来ない。文字コードを色々いじったりしてみたけど、どうにもすっきりと移行できず、色々文字変換をかけると移転後のチェックで膨大な時間が取られてしまうので、この移転方法は諦めました。
次に考えたのは、MTのバックアップ機能を使う手法。最初は全てをバックアップしてみようと思い、[システムメニュー]→[ツール]→[バックアップ]からバックアップをしようとするが、Webサーバ側のタイムアウト制限でバックアップできず。それじゃー、一個一個のブログをバックアップしようというわけで、[各ブログ]→[ツール]→[バックアップ]からバックアップを試みる。一つ一つのブログのエントリーは少ないから何とかなるかと思ったけど、5千件を超えるエントリーを誇るブログがタイムアウト、、、。昼間のアクセスが多い時間にやっていたので、夜中に試すもタイムアウト。早朝に試すも、タイムアウト。いつ試してもタイムアウト、、、むっきーーー！！
この時点で結構途方に暮れちゃったんですよね、暮れますよね？ 最悪、今アップされているデータを解析して、MTのデータベースに直接書き込んでやるか、とか（無茶です）。
原点に戻ろうということで、現在使用しているサーバを色々と調べていると、ホームディレクトリー直下にMySQLのデータディレクトリが存在していることが判明。もしかしたら、データベースファイルをそのまま新サーバに移動させたら、そのまま動いたりして？ とか、思いついて実際にやってみると、ビンゴ！ 動いたぜーーー、実際にMTで動作をチェックしたけど文字化けもなく、何事もなかったかのように動作してるし、、、。やー、PostgreSQLでは何度かやったことがあったんだけど、MySQLでもできてよかったーーー。細かいバージョンは違ったんだけど、同じMySQL5.0系だったのでそのまま動いちゃいました。
それでもちょっと怖かったので、1度 DBをmysqldumpでdumpして、DBをDROPしてから、再度DBをrestoreしました。問題ないみたい。すげー、助かったぁ～。ちなみに、データベース名でディレクトリが出来ていたので、それを旧サーバから新サーバのMySQLデータベースディレクトリに放り込んだだけです。MyISAMだったのも助かった要因かもしれないね。
というわけで、MT移行の方針も決定し実際の移転作業を行いました。
サーバ移転作業をやる場合、目茶苦茶大きくてテストが出来ないような場合を除いては予行演習を何度か行います。今回も予行演習は何回かやっていて、流れ的には下記をイメージしていました。
1. 旧サーバメンテナンス表示開始
2. DNS Aレコード変更
3. 旧サーバ最新コンテンツ取得開始（3時間程度）
4. 旧サーバデータベースファイル取得
5. 新サーバデータベースファイル設置
6. 新サーバデータベース再構築作業（ファイル設置→dump→drop db→関連ファイル削除→restore）
7. 新サーバデータベース確認作業
8. 新サーバMT動作チェック作業
9. 新サーバコンテンツ確認（更新漏れチェック）
10. メンテナンス表示解除
11. 新サーバへのアクセス開始
で、1→7までは予定時間よりもかなり短く進められ（3の前に、事前にコンテンツは取得済みで、実際の移転の際には差分だけ手動でアップ）、予定の6時間が2時間程度で終わる予定でした。が、そこにはサーバ移転の常、罠がありました、、、。
8の新サーバMTの動作チェックは問題なかったのですが、トップページの表示がなんか崩れる、、、なんか3件しか表示されないはずの場所で6件エントリタイトルが表示されてしまう現象が発生しました。その部分のMTタグを見てみるとmt:MultiBlogを使用して複数ブログから最新の3件を取り出す設定になっていました。
<mt:MultiBlog mode="context" include_blogs="1,2">
<mt:Entries lastn="3">
<li><a href="<$mt:EntryLink$>"><$mt:EntryTitle$gt;</a></li>
</mt:Entries>
</mt:MultiBlog>
mode="context"しているので、ちゃんと二つのブログから最新の3件を取り出してくれるはずなのですが、動作的にはそれぞれのブログから最新の3件を取り出しちゃっているようです、、、こまった。旧サーバでは問題なく動作していたのですが、なぜか新サーバでは異常な動作になってしまっている、、、。DBとかそういう問題とかじゃないのでかなり弱りましたが、色々調べるとmt:MultiBlogEntriesというタグでも同様の動作が可能だと判明、下記の様に書き直したところ無事動作を確認できました。
<mt:MultiBlogEntries mode="context" include_blogs="1,2" lastn="3">
<li><a href="<$mt:EntryLink$>"><$mt:EntryTitle$></a></li>
</mt:MultiBlogEntries>
ちなみに、この動作不具合は後にMT3のMultiBlogのプラグインが残っていたのが原因だったとの連絡を頂きました。そっかー、MT3時代は標準プラグインじゃなかったもんね。
というわけで、なんとか予定移転作業時間を1時間残して移転完了となりました。よかったよかったー。
投稿者 ymkx : 2010年11月 2日 12:07 |
