I've been reading posts on here about database mirroring and it's an almost overwhelming amount of options and information, but as I'm still new to most of the SQL database scene, I was hoping to find a more definitive answer to my situation:
My company has two 2008 R2 SQL Server databases, which exist on the same network and contain the same information. They are both updated simultaneously as new system data comes in from the automated processes they record, so all the records in both databases match perfectly. The concern in this scenario is that when one database goes down, the other is meant to kick in as the backup, and then when the problematic database is back up, it will be missing the records that were created during down time.
What would be the best method for retroactively syncing data between the two after one of them has crashed and been brought back online?
As many of the other posts have asked more questions back about what the company will / will not allow per the DBA or other permissions that might exist, I'd like to just state that it is safe to work off the assumption that all other concerns or conflicts have been taken care of, and we purely need to just migrate data to keep each database up to date with the other after a crash. In terms of a master / slave relationship, I don't believe one currently exists, as neither database is getting its data from the other (so long as they are both running); rather, it's coming from a tag-based program that monitors the afore-mentioned automated system
Did some looking into using the Publication / Subscription method through the REPLICATION folder you can find in SSMS and this seems plausible. The options appear as if it allows for immediate and continuous data sharing - would this be a viable option?