Moving from one production server to another

Task:

move a working project from one server to another.

We have:

working server, new server configured and configured to run the project.

I will not delve into the details of server settings, as this can be, in principle, any server under any OS. The main thing is that you have full access to the entire system. Those. admin rights. As well as the server should be ready at any time to receive visitors. Those. virtuals must be configured, installed DBMS, WEB server, etc.
')

The first way is simple:

We hang on the working server page with the words "We move, come tomorrow" and go!

Actually it is best to start with scripts. It would be perfect if you had SVN or CVS. In this case, the scripts can be poured in one click. In principle, FTP can also be easily downloaded, but if you need to correct something and quickly reload it, then it may be a little problematic to rush all the modified files in a hurry, especially if they are scattered in different directories.

After filling scripts go to the database. If your base is not gigabyte / terabyte in size, then you can try to make a test base and upload the entire dump there. If the dump is still very large, then you can fill only the structure and the necessary tables (so that the system “starts”) into the test database and test it. This is necessary for intermediate testing before you open the site for visitors. In addition to the test base, create a working one and fill in 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 site.com 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, you can temporarily add test.site.com and register it on a new server. Well, or just write in the hosts (in your OS) any domain and it should work. It should also be noted that your scripts must be properly configured for this domain (unless of course they are bound to domains).

Shimmering content. If your site has custom content, it should also be transferred to a new server. This can be done in different ways depending on your OS and your skills. I will not dwell on this, in general, a trivial task.

If everything went well, try to enter the test domain. In this case, if properly configured, the site should work correctly. Make a full system check - register a user, check sending mail, upload files, work of services, crones, daemons, etc. if everything is good, switch the scripts to a real base and you can change DNS (IP at the real domain). As the update on DNS servers passes, more and more new visitors will arrive at your new server. Do not forget to remove the page with the inscription on the new server. She is absolutely useless here :)

Estimated time - from 30 minutes to 3-4 hours (without taking into account the update time of DNS)

Further more fun ...

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

More complex and requires changes to the scripts, as well as database replication settings. And some manipulations with the system. It also requires more time and good skills in administering the system. It is better to do it 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 more fun - rule 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 to move and the new content should be uploaded to the new server, and the old one should remain where it is. If we simply start copying the current content to a new server, then no one will give us a guarantee that as long as we copy everything, nothing new will appear. Someone may have already guessed what to do with the constant. But I will explain in more detail - for example, we must begin the move 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 have to edit the scripts in all places where content is loaded. We need to add a check for time and if the server time is less than the time of the constant - leave the content where it is, if more - upload to the new server. Fill can be done in various ways. You can mount NFS or drbd (under * nix). You can upload content via FTP, SCP or other means. Of course, you have to worry about the security and stability of the system, so the choice of means of content delivery again depends on the specific situation. But how to understand what content is where? And how to separate the new content from the old? Well, if you have time to add content in the database, this makes the task very easy, if it is not ... then you need to proceed from the current situation - if the DBMS supports global object IDs (OID), then you can get the first ID after the specified date ( again automatically) or try to get the ID for each table where the content is stored separately and attach to them already. For example, we solved this problem. What's next? Next, we need to configure the auxiliary domain for the new server. For example, let your site be all the same site.com uses subdomains to access content: video.site.com, audio.site.com, etc. it will also make life easier for us. Add a subdomain: new.site.com and in it we prescribe all our subdomains: video.new.site.com, audio.new.site.com well, or vice versa - for each subdomain we prescribe another one: new.video. site.com, new.audio.site.com, etc. the main thing is that they point to a new server and at this address there was a new content. And the least thing left is to replace all the links to the content depending on our constant - i.e. after the date X, some of the links will point to new content, and some to old. If your paths are registered in one place and are available globally, it will not be difficult to replace links on the fly if all links are hammered into templates ... well, you know 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 may be a lot of them. It is good if you have a good project architecture and all entities have classes with methods for retrieving objects from the database. It is possible at the time to roughly fit into these methods 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 contains a list of old and new content, you will have to edit the template specifically for this page. Alas.

To avoid such a situation, add just one field to the content tables (it’s better to think about it at the architecture stage), 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 for this - for 1 - vid1.site.com, for 2 - vid2.site.com, etc. It is also recommended to do something similar for the distribution of content across multiple servers in a working project with a high load. But that's another story.

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

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

The problem is the same - you need to be able to use 2 bases in parallel. Very well, if you already have a cluster. With it we solve one important problem - we have a replication server. If this server is supported by the master-master and you can also add servers 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. On a live server, we raise the master, set up 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 like a “slave” i. Only synchronized with the main database.

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 may cause interruptions in the work of the site. So it is better to practice "on cats" i. somewhere else.

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

Perhaps many will say that replication is not the best way. Yes, perhaps it is. It will slow down a little, and in real-time mode it will load the entire system, but this is not really for long. Just for a few hours, until you transfer the main content and all DNSa are updated. It took me no more than 30 hours.

So, the problem with the base will be considered closed. It is configured and synchronized normally. It remains just a little bit, be patient. Your site is already one foot on another server :)

Starting a smooth transition - add the IP of the new server to your primary domain. As the zone is updated, users will go to your new site. This should start to do after the cherished date. Also make sure that all new content from the old server is poured onto the new one and the database is working as it should. Now she can slow down. It all depends on the channel, but if you do not store pictures, music, video, etc. in it, then the synchronization will not strain.

As soon as you are convinced that everything is going as it should, start pouring old content. Just make a copy of it. Do not worry, he has not changed. Of course, if everything works as it should. As soon as all content is uploaded - remove the old IP from the domain. There must be only a new one. As the zone is updated, all users will switch to the new server. About a day later, just in case hang up on the old server in the virtual for the domain, a page with a request to update the DNS cache. This is if someone zaksirovalsya. 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 - I'm not guilty :)

Do not rush to stop the old server and give it to the hoster. Hold another couple of weeks. Suddenly something did not overflow, so you will have an old copy and you will be able to recover the data.

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

Actually that's all.

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