В среде баз данных сценарий разделения мозга может возникнуть, когда связь между двумя разными сайтами прерывается. В этой ситуации и производственная база данных, и резервная база данных становятся записываемыми одновременно. Основная база данных на производственном сайте остается активной, в то время как вторичный сервер (резервная база данных) на сайте восстановления после катастрофы становится записываемым и принимает роль основной базы данных.
Основной причиной активации обеих баз данных является отсутствие видимости двух разных сред (производственной и восстановления после катастрофы) для кворума. Кворум считает, что обе среды доступны и не может определить, какая база данных должна голосовать. Это может вызвать серьезные проблемы, включая проблемы целостности базы данных и несоответствия при просмотре исторических транзакций клиентов.
Если сценарий разделения мозга не будет обнаружен вовремя, будут наблюдаться несоответствия в данных, хранящихся в двух базах данных, пока они не будут согласованы. Чтобы предотвратить эту проблему, желательно остановить службу SQL Server в резервной базе данных, как только сценарий разделения мозга будет обнаружен.
Мониторинговые и оповещающие инструменты, такие как Nagios, могут использоваться для обнаружения проблем с репликацией баз данных, кластеризацией высокой доступности (HA) или любыми другими проблемами, связанными с базами данных. Специально разработанные для мониторинга баз данных плагины Nagios могут помочь выявить сценарии разделения мозга и оповестить администраторов.
После восстановления связи между основным и резервным сайтами восстанавливается возможность записи в основную базу данных, а резервная база данных становится доступной только для чтения. Базы данных возобновят свои исходные режимы до возникновения сценария разделения мозга. Однако могут возникнуть проблемы с несоответствием данных и схемы базы данных, что может ввести клиентов в заблуждение, так как только транзакции, направленные в основную базу данных, будут видны пользователям.
Для согласования данных в основной и вторичной базах данных можно использовать несколько техник:
- Удалите репликацию между основной и вторичной базами данных. Это важно, потому что в основной базе данных содержатся самые последние записи.
- Сделайте полное резервное копирование как основной, так и резервной баз данных на случай необходимости повторного доступа к записям.
- После отключения или уничтожения репликации резервная база данных становится записываемой.
- Используйте инструменты, такие как SQL Data Compare или Visual Studio, для сравнения и синхронизации данных в двух базах данных.
- Визуализируйте записи из приложения, чтобы убедиться, что исторические записи отображаются правильно.
Управление кризисами в сценариях разделения мозга требует дополнительных мер:
- Настройте свидетелей файлового обмена. Свидетель файлового обмена – это файловый обмен, доступный всем узлам в кластере высокой доступности (HA). Он предоставляет дополнительный голос кворума при необходимости, чтобы обеспечить непрерывную работу кластера в случае сбоя сайта. Свидетель файлового обмена должен быть размещен в общедоступном облачном провайдере, таком как AWS, Azure или Google Cloud.
- Настройте сценарий обслуживания как в основной, так и в резервной базах данных. Этот сценарий будет отправлять уведомление, когда связь прерывается. После получения уведомления другой сценарий остановит службу резервной базы данных, как только она станет активной.
В заключение, понимание сценария разделения мозга в SQL Server является важным для поддержания целостности базы данных и обеспечения согласованных данных. Путем реализации правильных методов мониторинга, оповещения и согласования администраторы могут эффективно управлять и разрешать сценарии разделения мозга. Если у вас есть какие-либо опыты или идеи, связанные с управлением сценарием разделения мозга, пожалуйста, поделитесь ими с нами.