4 ms·
- pick a relational database (ie: mysql or postgres) - learn how to backup the database (I suggest via the official documentation) - restore that backup (on a
by readonly 7y ago
- pick a relational database (ie: mysql or postgres)
- learn how to backup the database (I suggest via the official documentation)
- restore that backup (on a different environment)
- validate the restore is complete (compare the data)
- if the backup and restore are good, now you can start learning how to migrate without the stress that you'll lose historical data
- tzmudzin 7y agoYou‘re absolutely right, but we all can be talking about different subjects here: - database restore - database migration (your case) - data migration to a different platform and presumably different data model (the bank‘s case, or my answer here) Not sure which case the question was reffering to, though...
- xenihn 7y agoHow about all 3 :)
- interblag 7y agoThis is 100% the way to learn this, and a great answer to the original question. Should also emphasize though that for a migration of the scale discussed in this article doing a SQL backup + restore is almost certainly not the right approach. At this kind of scale + uptime requirement, you'd want to do a migration like this gradually - hydrating the new system with data and keeping it up-to-date with changes for a period of weeks/months while doing testing + validation (and ideally also doing a gradual cutover, although that might not be realistic given banking infrastructure/application design). Probably the relevant approaches to look into after reviewing basic backup/restore are things like log-shipping or change-data-capture, although choosing the right approach would be highly dependent on the underlying technology, architecture, and requirements...