Forum Discussion
Redundant Mirrored Database Data for Downstream Dependency Protection
Hey thanks for reaching out... No I don't think I've really got an answer. I think it's just a current limitation of fabric... I think the real solution is to make it to where ownership can be transferred of a mirrored database or make it to where the item id doesn't get destroyed if you have to rebuild a mirrored database. I'll mark this as solved.
Hi dbWizard
Your approach is technically sound for low tolerance for analytics downtime.
But please keep these points in mind Each additional data copy increases storage costs and introduces potential synchronisation lag between the operational source and analytics consumers. The redundancy also creates additional complexity in data lineage tracking and governance, as organisations must now manage two separate data stores that theoretically contain identical information
mirroring is near real time,try to implementing incremental data loading patterns that detect changes in the mirrored database and apply them to the lakehouse in near real-time
Thank you for your input. The delays are definitely a considerations but downstream processes breaking I think outweighs any potential slowness in data moving around. I realize it's best to have one copy of data.. however, I need to be able to count on the data being there and the process running smoothly. Reseeding a db is a huge hit on IO at source as well. Hopefully more improvements come.