New answers tagged high-availability
With a standard edition you basically have two options, log shipping and mirroring. Unfortunately, neither of these solutions gives you an automated or managed solution for your third requirement of migrating connections. However, you could base connections on a set of configuration files and swap them out for a "failover" scenario. If you can swing an ...
A restore failing on the secondary will have no impact on the primary. You want to monitor your secondary DBs to make sure this hasn't happened.
Your architecture is not right for asynchronous replication. I strongly recommend against runing a Master-Master standard replication in a fully automated system, as you will run into precisely the issue you are describing. While you may not be writing to both servers at the same time, the fact that you are replicating in a non-syncronous way means that you ...
This is not a hack. It is the intention of them: Use auto_increment_increment and auto_increment_offset http://dev.mysql.com/doc/refman/5.6/en/replication-options-master.html#sysvar_auto_increment_increment
Although replication may not be High Availability in design, it depends on your definition of HA. Certainly it has been used for HA by many people. If replication is down long enough it can be marked as Inactive. To automatically reactivate a replication, you could try using Kin's response: SQL Server replication subscriptions marked as inactive This ...
It turns out that changes in table structure (schema) is automatically handled, so changes in the primary database should be also reflected in the secondary ones. Schema changes and data changes are essentially the same. It works like traditional mirroring today : what happened in the log on the primary happens on the secondary. Not everything that ...
Top 50 recent answers are included