After the stories about moving the company's information infrastructure from place to place caught my eye, I thought that moving an average Internet content project from one site to another was also quite an interesting topic. Particularly interesting is how to do this with minimal disruption to work.

This is, of course, not about a megaportal with two iron dump trucks, but about a medium-sized project, when there are few servers, they are all rented rather than owned by you, or you have an adequate supply of resources to transfer some of the servers to new place.

Surely, there are ways how to do it better in certain conditions, but I will state my thoughts on this topic. I am sure that, as usual, this will happen, someone will complement this with his valuable experience.
')
The story is designed for a prepared audience and is not an accurate step by step guide to action.

Introduction

So, there is a typical "gentleman's set":

• Nginx - front-end server, followed by Apache or FastCGI
• Database Server - MySQL
• Servers in the new data center are a worthy replacement for the servers of the current hoster, who have already tested your patience to the last limit

The whole project can “live” on one server or on several, user files can be stored both on the frontend and on a separate server.

In the event of a move between the leased servers, it is often possible to negotiate with the new hosting provider only from the beginning of the new month, so that you can put the equipment into operation and transfer the data.

Thus, a simple service during the transfer can be reduced at least until the time of creating the database dump. Well, if the database server is already configured for replication, if not, you will have to do it.

The whole process is divided into two parts: the first is the creation of an up-to-date copy of the resource at the new site, the second is the smooth redirection of traffic due to the post-refresh updating of the caching DNS servers.

Code

The code, templates, etc. in a good case are transferred by a simple action: svn co svn: //my.repository.ru/myproject/trunk.

Base

So, you need to open two connections with the working database server, in one console write flush tables with read lock , in the other run mysqldump with the necessary parameters. This moment is implied by the moment of idle time, since most likely your project may not work correctly at this time due to the read locks (read only) of all tables, you will probably have to hang a “stub” for this time (bonnie creates a full dump of the supergabra in approximately 58 seconds) After the copy of the database is ready, in the first console, write show master status and store the values ​​obtained (the current binary log file name and position in it) to some safe place. Then simply close the console, which unlocks the tables or executes unlock tables .

The resulting file is archived and transferred to the new site. There, on a new, still smelling factory of servers, a server, we create a base and restore data to it. Then we make a replication client database from the old site from this server and initiate replication from the previously obtained location: change master to master_log_file = 'server1-relay-bin.00025', master_log = 350384183; start slave;

If you are familiar with replication and did everything correctly, then in a few minutes you will have a “live” up-to-date copy of the database in a new place. In most cases, traffic between different sites is transmitted with sufficient speed so that all the “writing” requests have time to get from server to server without queues and delays.

Note: this item can be omitted than to completely eliminate the interruption in work, if you already have a slave server that you can transfer to a new location.

Custom files

User files are very conveniently moved using rsync (man rsync). During initial preparation, you can copy the full set of storage, and during startup, start synchronization again, in order to synchronize the changes: update the changed files and transfer the new ones.

Arrow translation

Now the decisive and most interesting moment. When you already have two working copies of the project, before you make changes to the DNS, you need to "close" one site to another. This can be done with the help of the native possible nginx, namely: its proxying module. That is, just make proxying of all requests to the new server through the old one (again, stupid tautology, when is the end?): Proxy_pass https://new.server.ip: 80 / .

If everything works fine, you can update the DNS zone file (I think everyone can transfer the DNS server in their own way). From this point on, one part of the requests will be processed transparently by the old servers, the other part by the new ones. Of course, the second part will grow as the records of caching servers are updated, and the first part will disappear in about a day.

As soon as you feel that the old servers are no longer needed, you can disable or reconfigure replication as you need and tell the old hosting provider that he will not receive more than one ruble from you.