While this is cool and I dig it, I'm really, really thankful for maintenance windows at the current job. In the real world, 99.9% of systems aren't used 24/7/365. Just do the cutoff when everyone is asleep. Then restart everything to be sure.
Thaxll
We need more details on 6. This is the hard part, like you swap connection from A to B, but if B is not synced properly and you write to it then you start having diff between the two and there is no way back.
Like B is slightly out of date ( replication wise ) the service modify something, then A comes with change that modify the same data that you just wrote.
How do you ensure that B is up to date without stopping write to A ( no downtime ).
mattlord
Blog post author here. I'm happy to answer any related questions you may have.
show comments
WaitWaitWha
I split step 4 in their "high level, this is the general flow for data migrations".
4.0 Freeze old system
4.1 Cut over application traffic to the new system.
4.2 merge any diff that happened between snapshot 1. and cutover 4.1
4.3 go live
to me, the above reduces the pressure on downtime because the merge is significantly smaller between freeze and go live, than trying to go live with entire environment. If timed well, the diff could be minuscule.
What they are describing is basically, live mirror the resource. Okay, that is fancy nice. Love to be able to do that. Some of us have a mildly chewed bubble gum, a foot of duct tape, and a shoestring.
show comments
ksec
Missing 2024 in the Title.
redwood
Worth underlining that this is data migrations from one database server or system to another rather than schema migrations
While this is cool and I dig it, I'm really, really thankful for maintenance windows at the current job. In the real world, 99.9% of systems aren't used 24/7/365. Just do the cutoff when everyone is asleep. Then restart everything to be sure.
We need more details on 6. This is the hard part, like you swap connection from A to B, but if B is not synced properly and you write to it then you start having diff between the two and there is no way back.
Like B is slightly out of date ( replication wise ) the service modify something, then A comes with change that modify the same data that you just wrote.
How do you ensure that B is up to date without stopping write to A ( no downtime ).
Blog post author here. I'm happy to answer any related questions you may have.
I split step 4 in their "high level, this is the general flow for data migrations".
4.0 Freeze old system
4.1 Cut over application traffic to the new system.
4.2 merge any diff that happened between snapshot 1. and cutover 4.1
4.3 go live
to me, the above reduces the pressure on downtime because the merge is significantly smaller between freeze and go live, than trying to go live with entire environment. If timed well, the diff could be minuscule.
What they are describing is basically, live mirror the resource. Okay, that is fancy nice. Love to be able to do that. Some of us have a mildly chewed bubble gum, a foot of duct tape, and a shoestring.
Missing 2024 in the Title.
Worth underlining that this is data migrations from one database server or system to another rather than schema migrations