Moving from one production server to another

    Task:

    Transfer a working project from one server to another.

    We have:

    production server, a new server configured and configured for the project.

    I will not delve into the intricacies of server settings, as it can be, in principle, any server under any OS. The main thing is that you have full access to the entire system. Those. administrator rights. And also the server should be ready at any time to receive visitors. Those. virtuals must be configured, a DBMS, a WEB server, etc. are installed

    The first way is simple:

    We hang on the working server a page with the inscription "We are moving, come tomorrow" and go!

    Actually, it's best to start with scripts. It would be ideal if you had SVN or CVS. In this case, you can upload scripts in one click. In principle, FTP can also be easily uploaded, but if you need to correct something and quickly reload it, then it may be a little problem in a hurry to upload all the changed files, especially if they are scattered in different directories.

    After uploading the scripts, go to the database. If your database is not gigabyte / terabyte in size, then you can try to make a test base and fill in the entire dump. If the dump is still very large, then you can only upload the structure and the necessary tables (so that the system starts up) in the test base and test on it. This is necessary for intermediate testing before opening a site for visitors. In addition to the test base, create a working one and fill the entire dump there, but leave the use of the test base in the settings.

    Virtual host It should be configured so that it can work with two different domains. What for? Again for testing. For example, your site.com site is now closed, but you need to make sure that everything will be fine on the new server? This is what the second domain is for. Where to get it is the second question. If you do not have subdomains, then you can temporarily add test.site.com and register it on a new server. Well, or just register in the hosts (in your OS) any domain and this should work. It should also be noted that your scripts must be correctly configured for this domain (unless of course they are bound to domains).

    Transfusion of content. If your site has custom content, it must also be uploaded to a new server. You can do this in various ways, depending on your OS and your skills. I will not dwell on this generally trivial task.

    If everything went well, try going to the test domain. In this case, with the correct configuration, the site should work correctly. Make a full system check - register the user, check the sending of mail, file uploads, the work of services, crowns, daemons, etc. if all is well, switch the scripts to the real database and you can change the DNS (IP for the real domain). As the update progresses through DNS servers, more and more new visitors will arrive on your new server. Do not forget to remove the page with the inscription on the new server. She’s completely useless here :)

    Estimated time - from 30 minutes to 3-4 hours (excluding the time of updating CSNs)

    Further more fun ...


    The second way - moving on the fly without closing the site.

    More complex and requires changing scripts, as well as setting up database replication. And some manipulations with the system. It also requires more time and good skills in administering the system. It is better to do this together with the system administrator.

    The beginning is the same as in the first case - setting up virtuals, DBMS, WEB server, etc. Only the site does not close! Let the visitors go. Further fun - edit the scripts. We need to add a global constant that will contain the point in time from which our move will begin. We will rely on this constant in many places of the project, so it should be visible everywhere. I want to note - this constant is needed only if the system uses user content. For example, users upload pictures, avatars, music, etc. In this case, we need to know - from what moment we start moving and the new content should be uploaded to the new server, and the old one should remain where it is. If we just start copying the current content to a new server, then no one will give us a guarantee that while we copy everything, we have nothing new to appear. Someone may already have guessed what to do with the constant. But I will explain in more detail - for example, we must start moving at 00:00:00 01-03-2009. At this point, all user content should be stored on the old server, after this point - on the new one. To do this, you will have to edit the scripts in all places where the content is downloaded. We need to add a time check and if the server time is less than the constant time - leave the content where it is, if more - upload to a new server. Filling can be done in various ways. You can mount NFS or drbd (under * nix). You can upload content via FTP, SCP or other methods. Of course, you should take care of the security and stability of the system, so the choice of a content delivery system again depends on the specific situation. But how to understand what content is where? And how to separate new content from old? It’s good if you have the time to add content in your database - this greatly simplifies the task, but if it isn’t ... then you need to proceed from the current situation - if the DBMS supports global object IDs (OIDs), you can get the first ID after the specified date ( again automatically) or try to get an ID for each table where the content is stored separately and already attached to them. For example, we solved this problem. What's next? Next, we need to configure the secondary domain for the new server. For example, let your site be the same site.com uses subdomains to access content: video.site.com, audio.site.com, etc. it will also make our life easier. Add a subdomain: new.site.com and register all of our subdomains in it: video.new.site.com, audio.new.site. com or vice versa - for each subdomain we prescribe one more: new.video. site.com, new.audio.site.com, etc. the main thing is that they point to a new server and there is new content at this address. And the least remains - to replace all links to content depending on our constant - i.e. after date X, part of the links will point to the new content, and part to the old. If your paths are written in one place and accessible globally, it will not be difficult to replace links on the fly if all the links are nailed into templates ... well, you yourself understand who you are now :) But not everything is as simple as it seems. You will have to fix all the places where the content is displayed ... Unfortunately, there can be a lot of them. It’s good if you have a good project architecture and for all entities there are classes with methods for obtaining objects from the database. You can roughly fit into these methods for a while and do a check there. For example, you get an audio object only in the retrieve method in the Audio class. In this case, you can add your verification to this method and change your base URL. But if your page has a list of old and new content, you will have to edit the template specifically for this page. Alas.

    To avoid this situation, add only one field to the content tables (it is better to think about it at the stage of architecture), which will indicate where to get this content. For example, the storage (smallint) field contains 1,2,3 ... and in the templates you simply substitute the necessary URL based on this - for 1 - vid1.site.com, for 2 - vid2.site.com, etc. It is also recommended that you do something similar to distribute content across multiple servers on a high-load working project. But that's another story.

    UPD: in some cases, proxy can avoid these dances with a boon - all requests for content are wrapped on a new server and there, if no content is found, they are proxied to the old one. Thanks mgyk for the tip.

    So, at the moment, we have solved the problem with the distribution of content and the substitution of the correct links depending on the time constant. Further base.

    The problem is the same - you need to be able to use 2 bases in parallel. Very good if you already have a cluster. With it, we solve one important problem - we have a replication server. If this server supports the master, and even you can add the server on the fly, then this is just super. All we need is to raise the secure channel between the servers and configure replication through it. We raise the wizard on a live server, configure replication with our working server and it delays (at least should) the entire database itself + constantly keeps it up to date, which is very important. At the moment it works as a “slave” ie only synchronized with the main base.

    If the replication server is not installed on the main server, you will have to install it. During installation, you may have to restart the DBMS, which can cause interruptions in the site. So it’s better to practice “on cats” ie somewhere else.

    If replication is not possible, then we are at a dead end ...

    Perhaps many will say that replication is not the best way. Yes, maybe it is. It will slow down a little, and in real time it will load the whole system, but it really will not last long. Just a few hours, until you upload the main content and update all DNS. It took me no more than 30 hours.

    So, we consider the problem with the database closed. It is configured and synchronizes normally. Remained quite a bit, a little, be patient. Your site is already one foot on another server :)

    We begin a smooth transition - add the IP of a new server to your main domain. As the zone is updated, users will go to your new site. This must begin to be done after the cherished date. Also make sure that all new content from the old server is uploaded to the new one and the database works as it should. Now it can slow down. It all depends on the channel, but if you do not store pictures, music, video, etc. in it, then synchronization will not be annoying.

    Once you are convinced that everything is going as it should, start pouring old content. Just make a copy of it. Do not worry, it will not change. Of course, if everything works as it should. As soon as all the content is uploaded, remove the old IP from the domain. Only the new one should stay. As the zone is updated, all users will be transferred to the new server. About a day later, just in case, on the old server in the virtual for the domain, post a page asking you to update the DNS cache. This is if someone cached it. Stop the replication server on the new server. Fill in old scripts without checks. If everything is fine - congratulations - you are on a new server. If something went wrong - it's not my fault :)

    Do not rush to stop the old server and give it to the hoster. Hold a couple more weeks. Suddenly, something did not overflow, so you will have an old copy and you can restore the data.

    Also, be careful when you make changes to scripts - they should not try to upload content to the new server. To do this, you need to make an additional check for their location. For example, add some kind of file that will only be on the new server and if it exists, then do not send content.

    Actually that's all.

    Thank you for your attention and invite , I hope this helps someone.

    Also popular now: