Live data migration - double read vs double write

Question

Pretty often I have a need to migrate the location where some data is stored - to a new column, a new table, or even a new data store. And usually this needs to be done with no down-time. I can see two approaches. Either:

1. Change all live writers to write new data to both locations
2. Do a one-time migration of data from the old location to the new location
3. Change all readers to read data from only the new location
4. Stop writing new data to the old location

or:

1. Change all readers to read data from both locations, preferring the new location
2. Change all writers to write new data to only the new location
3. Do a one-time migration of data from the old location to the new location
4. Stop reading data from the old location

I'm curious to hear thoughts or experiences on which approach is preferable, or if they have pros and cons. Is one or the other a more established practice?

Answer 1

If you don't just copy the data, but also transform it in some way and you have a new feature that can only work with the new data, then the second approach means that you can deploy that new feature already with partial data while the transformation is still being done on the old data.

The first method on the other hand allows for a very easy rollback if something goes wrong.

Answer 2

When I have done this, I have taken essentially your first approach - for instance, when encrypting a database or changing its key. I say “essentially” because the double-write state can last quite some time, since there is no need to hurry and the database works well during it.

The one refinement is that there is a tidemark at any given moment, representing how far the copying process has progressed. A write below the tidemark is doubled (to old and to new). A write above the tidemark is written only to the old database, since the new data will be transferred to the new database when the copying process gets there.

One of the great attractions of this approach is that it can fail at any time without doing any harm: the “old” database is still fully live and the “new” one just gets discarded.