4 ms·
I've done this many times with fightlogg.in This is the process: 1. Set up new server on new host (nginx/postgres/python/everything than needs set up) 2. Wait
by freework 12y ago
I've done this many times with fightlogg.in
This is the process:
1. Set up new server on new host (nginx/postgres/python/everything than needs set up)
2. Wait until 3AM or whenever traffic is at a lull.
3. Put up a message saying something about "server migration in progress".
4. Run pg_dump of the database on the old server.
5. scp that dump over to the new server
6. pg_restore that dump to new database server
7. Add an entry to new server's pg_hba.conf to allow connection from old server
8. change old server's app config to use the new postgres server (instead of localhost)
9. Move over A records.
The only downtime is the amount of time to do steps 6, 7 and 8. My entire DB is less than 1GB so it takes like 3 minutes to migrate.
This is made easy by me only having one datastore to move over. If the project has more than one datastore, it would probably take all day to migrate everything over.
- kawsper 12y ago> "The only downtime is the amount of time to do steps" Don't you have downtime already at step 3?
- stevekemp 12y agoThe only difference I'd make here is using rsync for the transfer of the dump. If you're migrating a large database, frequently MySQL in my experience, you can run rsync in advance. With rsync you can cut the downtime between disabling the old-host and promoting the new-host to the time it takes the transfer the changes applied since your previous rsync. For small hosts/data-sets this might not matter, but for large ones you'll get a real saving.