チャレンジ：
作業中のプロジェクトをあるサーバーから別のサーバーに転送します。私たちが持っています：
実稼働サーバー、プロジェクト用に構成および構成された新しいサーバー。サーバー設定の複雑さについては詳しく説明しません。原則として、どのOSでもどのサーバーでもかまいません。 主なことは、システム全体に完全にアクセスできることです。 つまり 管理者権限。 また、サーバーはいつでも訪問者を受け入れる準備ができている必要があります。 つまり virtualsを構成する必要があり、DBMS、WEBサーバーなどがインストールされている
最初の方法は簡単です：
「私たちは動いています、明日来てください」という碑文のあるページを作業中のサーバーに置いて行きます！
実際、スクリプトから始めるのが最善です。 SVNまたはCVSがあれば理想的です。 この場合、ワンクリックでスクリプトをアップロードできます。 原則として、FTPも簡単にアップロードできますが、何かを修正してすぐにリロードする必要がある場合、特に異なるディレクトリに散在している場合は、すべての変更されたファイルを急いでアップロードすることで少し問題になる場合があります。
スクリプトをアップロードした後、データベースに移動します。 データベースのサイズがギガバイト/テラバイトでない場合は、テストベースを作成してダンプ全体を埋めることができます。 ダンプがまだ非常に大きい場合は、テストベースで構造と必要なテーブル（システムが起動するように）のみをアップロードしてテストできます。 これは、訪問者のためにサイトを開く前の中間テストに必要です。 テストベースに加えて、作業ベースを作成し、そこでダンプ全体を埋めますが、設定にはテストベースの使用を残します。
仮想ホスト 2つの異なるドメインで動作できるように構成する必要があります。 なんで？ もう一度テストします。 たとえば、site.comサイトは現在閉じられていますが、新しいサーバーですべてが正常であることを確認する必要がありますか？ これが2番目のドメインの目的です。 どこで入手できるかは2番目の質問です。 サブドメインがない場合は、test.site.comを一時的に追加して、新しいサーバーに登録できます。 まあ、または単にホスト（OS内）に任意のドメインを登録すれば、これは機能するはずです。 また、このドメイン用にスクリプトを正しく構成する必要があることにも注意してください（もちろん、ドメインにバインドされている場合を除きます）。
コンテンツの輸血。 サイトにカスタムコンテンツがある場合は、新しいサーバーにもアップロードする必要があります。 これは、OSとスキルに応じて、さまざまな方法で実行できます。 この一般的に些細な作業については説明しません。
すべてうまくいった場合は、テストドメインに移動してみてください。 この場合、正しい構成で、サイトは正しく機能するはずです。 システム全体のチェックを行います-ユーザーを登録し、メールの送信、ファイルのアップロード、サービスの仕事、クラウン、デーモンなどをチェックします。 すべてうまくいけば、スクリプトを実際のデータベースに切り替えて、DNS（実際のドメインのIP）を変更できます。 DNSサーバーを介して更新が進むにつれて、新しいサーバーに新しい訪問者がますます到着します。 新しいサーバー上の碑文のあるページを削除することを忘れないでください。 彼女はここではまったく役に立たない:)
推定時間-30分から3〜4時間（DNSの更新時間を除く）
次にもっと楽しい...
2番目の方法-サイトを閉じずにオンザフライで移動します。
より複雑で、スクリプトの変更とデータベース複製のセットアップが必要です。 そして、システムでのいくつかの操作。 また、システムの管理にはより多くの時間と優れたスキルが必要です。 システム管理者と一緒にこれを行うことをお勧めします。
最初は最初のケースと同じです-仮想、DBMS、WEBサーバーなどを設定します サイトだけが閉じません！ 訪問者を行かせてください。 さらに楽しい-スクリプトを編集します。 移動を開始する時点を含むグローバル定数を追加する必要があります。 プロジェクトの多くの場所でこの定数に依存するため、どこにでも表示されるはずです。 私は注意したい-この定数は、システムがユーザーコンテンツを使用する場合にのみ必要です。 たとえば、ユーザーは写真、アバター、音楽などをアップロードします。 この場合、移動を開始する瞬間から新しいコンテンツを新しいサーバーにアップロードする必要があり、古いサーバーは現在の場所に残しておく必要があります。 現在のコンテンツの新しいサーバーへのコピーを開始しただけでは、すべてをコピーしている間は新しいものがないという保証はありません。 誰かが定数をどうするかをすでに推測しているかもしれません。 しかし、より詳細に説明します-たとえば、2009年1月3日の00:00:00に移動を開始する必要があります。 この時点で、すべてのユーザーコンテンツは、この時点の後の新しいサーバーにある古いサーバーに保存する必要があります。 これを行うには、コンテンツがダウンロードされるすべての場所でスクリプトを編集する必要があります。 時間チェックを追加する必要があります。サーバー時間が一定時間より短い場合は、コンテンツをそのままにしておき、新しい場合は、新しいサーバーにアップロードします。 充填はさまざまな方法で行うことができます。 NFSまたはdrbd（* nixの下）をマウントできます。 FTP、SCP、またはその他の方法でコンテンツをアップロードできます。 もちろん、システムのセキュリティと安定性に注意する必要があるため、コンテンツ配信システムの選択は特定の状況に依存します。 しかし、どのコンテンツがどこにあるのかを理解する方法は？ そして、新しいコンテンツを古いコンテンツから分離する方法は？ データベースにコンテンツを追加する時間がある場合は便利です-これによりタスクが大幅に簡素化されますが、そうでない場合は現在の状況から続行する必要があります-DBMSがグローバルオブジェクトID（OID）をサポートしている場合、その日付以降に最初のIDを取得できます再び自動的に）またはコンテンツが個別に保存されている各テーブルのIDを取得し、既にそれらにバインドしようとします。 たとえば、この問題を解決しました。 次は？ 次に、新しいサーバーのセカンダリドメインを構成する必要があります。 たとえば、site.comがサブドメインを使用してコンテンツにアクセスするのと同じサイトであるとします：video.site.com、audio.site.comなど。 また、私たちの生活が楽になります。 サブドメイン：new.site.comを追加し、その中にすべてのサブドメインを登録します：video.new.site.com、audio.new.site.com、またはその逆-サブドメインごとにもう1つ、new.videoを書き込みます。 site.com、new.audio.site.comなど 主なことは、それらが新しいサーバーを指し、このアドレスに新しいコンテンツがあることです。 そして、少なくとも残り-私たちの定数に応じてコンテンツへのすべてのリンクを置き換える-つまり 日付X以降、リンクの一部は新しいコンテンツを指し、一部は古いコンテンツを指します。 パスが1か所に記述されており、グローバルにアクセスできる場合、すべてのリンクがテンプレートに固定されていれば、その場でリンクを置き換えることは難しくありません...まあ、あなたはあなたが今誰であるかを理解しています:)しかし、すべてが見た目ほど単純ではありません。 コンテンツが表示されるすべての場所を修正する必要があります...残念ながら、それらの多くが存在する可能性があります。 優れたプロジェクトアーキテクチャがあり、すべてのエンティティに対して、データベースからオブジェクトを取得するためのメソッドを備えたクラスがあると便利です。 しばらくこれらのメソッドに大まかに適合し、そこでチェックを行うことができます。 たとえば、Audioクラスのretrieveメソッドでのみオーディオオブジェクトを取得します。 この場合、このメソッドに検証を追加して、ベースURLを変更できます。 ただし、ページに古いコンテンツと新しいコンテンツのリストがある場合は、このページ専用のテンプレートを編集する必要があります。 ああ。
この状況を回避するには、コンテンツテーブルに1つのフィールドのみを追加します（アーキテクチャの段階で考えた方がよいでしょう）。これは、このコンテンツを取得する場所を示します。 たとえば、ストレージ（smallint）フィールドには1,2,3 ...が含まれており、テンプレートでは、これに基づいて必要なURLを単純に置き換えます（1はvid1.site.com、2はvid2.site.comなど）。 同様に、高負荷の作業プロジェクトの複数のサーバーにコンテンツを配布することをお勧めします。 しかし、それは別の話です。
UPD：場合によっては、プロキシはこれらのダンスを恩恵で回避できます-コンテンツに対するすべてのリクエストは新しいサーバーでラップされ、そこでコンテンツが見つからない場合、古いサーバーにプロキシされます。 先端をありがとうmgyk 。
そのため、現時点では、コンテンツの配布と時定数に応じた正しいリンクの置換に関する問題を解決しました。 さらにベース。
問題は同じです-2つの塩基を並行して使用できる必要があります。 すでにクラスターがある場合は非常に良いです。 これにより、1つの重要な問題を解決します。レプリケーションサーバーがあります。 このサーバーがマスターをサポートしており、サーバーをその場で追加できる場合でも、これは非常に優れています。 必要なのは、サーバー間の安全なチャネルを上げ、それを介してレプリケーションを構成することです。 稼働中のサーバーでウィザードを起動し、稼働中のサーバーでレプリケーションを構成すると、データベース全体が遅延します（少なくともそうなるはずです）。 現時点では、それは「スレーブ」として機能します メインベースとのみ同期します。
レプリケーションサーバーがメインサーバーにインストールされていない場合は、インストールする必要があります。 インストール中に、DBMSの再起動が必要になる場合があります。これにより、サイトが中断する可能性があります。 だから「猫で」練習する方がいい 他のどこか。
レプリケーションが不可能な場合、私たちは行き詰まっています...
おそらく、多くの人がレプリケーションは最良の方法ではないと言うでしょう。 はい、そうかもしれません。 それは少し遅くなり、リアルタイムでシステム全体をロードしますが、これは実際には長くありません。 メインコンテンツをアップロードし、すべてのDNSを更新するまで、わずか数時間。 30時間もかかりませんでした。
したがって、データベースが閉じられている問題を検討します。 通常どおりに構成および同期されます。 少しだけ残って、辛抱してください。 あなたのサイトはすでに別のサーバー上にあります:)
スムーズな移行を開始します-新しいサーバーのIPをメインドメインに追加します。 ゾーンが更新されると、ユーザーは新しいサイトに移動します。 これは大切な日付の後に始めなければなりません。 また、古いサーバーのすべての新しいコンテンツが新しいサーバーにアップロードされ、データベースが正常に機能することを確認してください。 速度が低下する可能性があります。 それはすべてチャンネルに依存しますが、写真、音楽、ビデオなどをその中に保存しなければ、同期は迷惑になりません。
すべてが正常に行われていると確信したら、古いコンテンツを注ぎ始めます。 ただコピーしてください。 心配しないでください、変更されません。 もちろん、すべてが正常に機能する場合。 すべてのコンテンツがアップロードされたらすぐに、ドメインから古いIPを削除します。 新しいものだけが残ります。 ゾーンが更新されると、すべてのユーザーが新しいサーバーに転送されます。 約1日後、念のため、ドメインの仮想の古いサーバーに、DNSキャッシュの更新を求めるページを投稿します。 これは誰かがそれをキャッシュした場合です。 新しいサーバーで複製サーバーを停止します。 チェックせずに古いスクリプトを入力します。 すべてがうまくいけば-おめでとうございます-あなたは新しいサーバーにいます。 何かがうまくいかなかった場合-それは私のせいではありません:)
急いで古いサーバーを停止してホスティング事業者に渡さないでください。 さらに数週間お待ちください。 突然、何かがオーバーフローしなかったため、古いコピーがあり、データを復元できます。
また、スクリプトを変更するときは注意してください。新しいサーバーにコンテンツをアップロードしないでください。 これを行うには、場所の追加チェックを行う必要があります。 たとえば、新しいサーバーにのみ存在するファイルを追加します。ファイルがある場合は、コンテンツを送信しないことを意味します。
実際にはそれだけです。
ご清聴ありがとうございました。これが誰かのお役に立てば幸いです。