On Oct 12, 2013, at 19:39, Jeroen Geilman <jer...@adaptr.nl> wrote: > On 10/12/2013 07:16 PM, DTNX Postmaster wrote: >> On Oct 12, 2013, at 17:04, teknet9 <tekn...@o2.pl> wrote: >> >>> Thank you for advise. >>> I have many users i can not allow for any downtime (not even few seconds). >>> Also i can not loose any single email. >>> Your solution will not guarantee that. >>> >>> I am looking for true HA solution. >>> >>> That is why both servers needs to work at the same time for 1-2 months >>> to allow users to test new account and to migrate when ready. >>> During migration both servers needs to work correctly (two way sync) >> Don't run them side by side, but cut over. This is much less of a disruption >> for your users than having them test their account and whatnot. Testing is >> your job, not theirs. >> >> Follow the suggestions already given. Whether Jeroen's suggestion or a >> straight cut-over with hot sync followed by a cold sync will work best for >> you will depend on the specifics of your setup. If you prep this properly >> you can probably do this within a planned downtime window of half an hour, >> maybe even less. > > Agreed. > > My proposal was mostly based on swapping out the server, which can circumvent > DNS expiries if that's what he is worried about. > But even so it would be trivial to keep the old server running as an incoming > relay after the migration, so he doesn't have to wait for the MX to expire. > > I'm curious what you meant by "hot sync" and "cold sync" exactly - from your > reply it seems it's not quite the same I was suggesting.
What works best depends on the differences between the old and the new server. Your suggestion works great, and is in several cases the better way to go, for example if one is making big changes in setup, software and so on. The hot and cold sync works great if the software stays similar enough that you can use rsync to replicate your dataset from the old server to the new one. Let's say you have 100 GB worth of IMAP mailboxes that need to be migrated. One starts by rsync'ing the whole dataset while everything runs, a 'hot' sync, without worrying about any messages that may be added or removed during the initial run. Right before your maintenance window one runs another hot sync, turns off relevant daemons, and then runs the final 'cold' sync. The dataset that the cold sync sees should be stable, as it's no longer being written to, and only a fraction of the total dataset size. This means it completes in a few minutes, during which one drops the IP address on the old server, adds it on the new one, starts all relevant daemons there, et voila! If one prepped thoroughly, this can be done with very limited downtime, without the need to wait for those crazy ISP resolvers that ignore a low TTL one might set for a migration. It is of course an all-or-nothing approach, and may not always be suitable if you are making big changes. But it can be scripted, tested etc. before you throw the switch. A big advantage is that clients aren't bothered with TTLs and whatnot. If planned correctly, hardly anyone should notice. Mvg, Joni
