Step 1. Set up one-way replication of all data on the old server to the new one.
Create a copy of the site on a new server. We test, launch, see how the site reacts to requests. If everything works fine, set up database replication. What does it mean? When a request from visitors arrives at the old server, it notifies the client about the new data. The new server receives all data about changes from the old server within a matter of seconds (most often, even in 1 second).
Thus, on the new server, the copy of the database is constantly updated and remains current. As for static information (files, cache), here you need to establish one-way synchronization from disk to disk. You can use both simple technologies and more complex (distributed file systems). In our experience, rsync running in an infinite loop is sufficient. It is quite suitable for solving such problems, although the issues of statics synchronization can be solved using any other known and convenient methods.
As a result, we get 2 servers. The old one contains the old site, which users still visit. And even after we make changes to the DNS, for at least another 5 minutes, users will get to the old server.
All information from the old server is replicated to the new server. It turns out that we have a complete replica of the old site on the new server. An important point: files are replicated with a slight delay. you must first calculate what exactly has changed.
Step 2. Testing the new server.
After setting up replication, we test the site on the new server. In order for your local computer to access a new copy of the site without changing the DNS settings, you need to make a change to the hosts file (in Windows it is usually C: \ Windows \ System32 \ drivers \ etc \ hosts) by adding a line like IP.address .new.server (e.g. 13.13.13.13) yourdomain.com www.yourdomain.com
If you need to perform a mechanical check of a large number of records, we do it using a script that sequentially executes a series of requests and compares them with the responses.
Step 3. Set up proxying to redirect web traffic to the new server.
Before making changes to DNS, we transfer the work of the site on the old server to the new one. To do this, we will use the proxying mechanism, which is available in both NGINX and Apache HTTP Server.
In the configurations of the web server, we indicate that if something came to the old server with the address 6.6.6.6, you should contact the new server 13.13.13.13 with the same request, and then send its response back to the client on your behalf. The client accesses the old server, where the site no longer exists, but there is a proxy web server. The proxy web server with the address 6.6.6.6 accepts requests from the user, secretly addresses them to 13.13.13.13. Thus, the clients, although they are referring to the old server 6.6.6.6, are actually already working with the site on the new server 13.13.13.13.
Another advantage in working with a proxy server is that it can be set to fall-back (fallback): if the required file is not on the 13.13.13.13 server, then you need to look for it in the local directory. This solves the problem of file syncing lag.
Step 4. Disconnect the old server.
Change the site's DNS records to 13.13.13.13. When a visitor arrives who is still accessing 6.6.6.6 (within the first 300 seconds after the changes are made, such requests will still come), the proxying web server processes his requests by passing it to the new web server with the address 13.13.13.13. And when the user directly addresses the new address 13.13.13.13, it will be processed by the new server normally. This eliminates the problem of database splitting, since clients work with the same database, with the same set of files, with the same site.
We are waiting for the time that we indicated in the TTL (if you remember, even before the transfer, we set it to 300 seconds), and wait for the requests to the old server to stop arriving. In order to finally make sure that all clients and requests from them go directly to the new server, we wait a day and confidently turn off the old server computer tech help.
Done! Now your site has successfully moved to the new server.
Seamless migration service cost
You can transfer the site yourself. We are always ready to help with advice and quality instructions. Or entrust the move to us, and we will do everything for you. We do site transfer using a "stub" or "splitting" method for free. The seamless migration technique requires training and knowledge, and also takes more time, so this service is paid. The cost of seamless moving service is 100% of the server cost for 1 month, but not less than 30 euros. Our experts will help you transfer a high-load project painlessly, smoothly and without compromising the site's performance.
Summing up
Although migrating a website from server to server is a responsible and painstaking process, our seamless migration technique allows you to do this without downtime and loss of customer orders.
If you need help changing hosting, please contact us! We will help you transfer a project of any size painlessly and smoothly. The main thing: site migration is not scary at all, if you entrust it to an experienced and skillful provider.
No comments:
Post a Comment