Всем привет! Сегодня я хочу начать серию постов, в основу которых положены публикации известного и уважаемого человека в мире SQL Server - Пола Рэндала, в которых он описывает 30 наиболее распространённых мифов в работе с SQL Server. Пол писал по посту каждый день, на протяжении всего апреля. Подобную скорость обеспечить навряд-ли смогу :) но обещаю по мере сил развенчивать новые и новые мифы вместе с Полом. Итак, к делу! Миф №1 – После сбоя, выполнение текущих транзакций будет продолжено
После того как на сервере происходит аппаратный либо программный сбой, начинается ряд операций по восстановлению системы после сбоя. И если транзакция не была зафиксирована на сервере до сбоя, то не существует способа автоматически воссоздать контекст транзакции и "воскресить" выполнявшуюся транзакцию на резервном сервере, какой бы способ обеспечения отказоустойчивости вы бы ни избрали: отказоустойчивый кластер, зеркалирование, доставка журналов или SAN репликация. В отказоустойчивом кластере, когда происходит сбой на основном сервере, поднимается экземпляр на резервном. В процессе восстановления после сбоя все не завершённые транзакции (в том числе и аварийно завершённые) откатятся (механизм восстановления после сбоя более подробно описан в статье Ведение журнала и восстановление в SQL Server). При зеркалировании БД лог транзакций зеркальной базы постоянно пополняется записями лога основной БД. После чего эти инструкции выполняются на зеркальной базе. Этот механизм позволяет обеспечить согласованность основной и зеркальной баз. Когда происходит переключение серверов (ручное, либо автоматическое в результате сбоя) лог транзакций зеркальной базы переходит в режим восстановления после сбоя, в ходе которого все незавершённые транзакции будут откачены. После восстановления сервер разрешает соединения с базой данных. Механизм доставки журналов подразумевает периодическое снятие бэкапа лога транзакций БД первичного сервера, копирования и восстановление на произвольном количестве вторичных серверов. После сбоя администратор баз данных поднимает один из вторичных серверов. При этом он имеет возможность снять резервную копию лога транзакций с первичной БД (уже после отказа БД) и накатить её на вторичную. И опять таки, в этом случае, как часть процесса востановления произойдёт откат всех незафиксированных транзакций. В SAN репликации все I/O операции которые просходят на локальном SAN дублируются на удалённом, что позволяет иметь удалённую копию БД. Когда происходит сбой, система соединяется с удалённым SAN, и происходит процесс восстановления после сбоя, точно так же, как и в отказоустойчивом кластере (это упрощенное объяснение, - но идея ясна). *Единственный* способ, позволяющий поддерживать непрерывное соединение с БД во время сбоя – использование виртуализации с функцией "live migration", которая подразумевает то, что когда виртуальная машина поднимается, соединения не знают, что они обращаются к другому физическому узлу, на котором находится виртуальная машина. Но какой бы механизм вы ни использовали – если *соединение* разорвано, все данные выполняющихся в данный момент транзакций будут потеряны. Поэтому ваше приложение должно разрабатываться с учётом таких ситуаций: корректно обрабатывать разрыв соединения с базой данных и возможно выполнять повторный запуск команд. Read more: Denis Reznik's blog
После того как на сервере происходит аппаратный либо программный сбой, начинается ряд операций по восстановлению системы после сбоя. И если транзакция не была зафиксирована на сервере до сбоя, то не существует способа автоматически воссоздать контекст транзакции и "воскресить" выполнявшуюся транзакцию на резервном сервере, какой бы способ обеспечения отказоустойчивости вы бы ни избрали: отказоустойчивый кластер, зеркалирование, доставка журналов или SAN репликация. В отказоустойчивом кластере, когда происходит сбой на основном сервере, поднимается экземпляр на резервном. В процессе восстановления после сбоя все не завершённые транзакции (в том числе и аварийно завершённые) откатятся (механизм восстановления после сбоя более подробно описан в статье Ведение журнала и восстановление в SQL Server). При зеркалировании БД лог транзакций зеркальной базы постоянно пополняется записями лога основной БД. После чего эти инструкции выполняются на зеркальной базе. Этот механизм позволяет обеспечить согласованность основной и зеркальной баз. Когда происходит переключение серверов (ручное, либо автоматическое в результате сбоя) лог транзакций зеркальной базы переходит в режим восстановления после сбоя, в ходе которого все незавершённые транзакции будут откачены. После восстановления сервер разрешает соединения с базой данных. Механизм доставки журналов подразумевает периодическое снятие бэкапа лога транзакций БД первичного сервера, копирования и восстановление на произвольном количестве вторичных серверов. После сбоя администратор баз данных поднимает один из вторичных серверов. При этом он имеет возможность снять резервную копию лога транзакций с первичной БД (уже после отказа БД) и накатить её на вторичную. И опять таки, в этом случае, как часть процесса востановления произойдёт откат всех незафиксированных транзакций. В SAN репликации все I/O операции которые просходят на локальном SAN дублируются на удалённом, что позволяет иметь удалённую копию БД. Когда происходит сбой, система соединяется с удалённым SAN, и происходит процесс восстановления после сбоя, точно так же, как и в отказоустойчивом кластере (это упрощенное объяснение, - но идея ясна). *Единственный* способ, позволяющий поддерживать непрерывное соединение с БД во время сбоя – использование виртуализации с функцией "live migration", которая подразумевает то, что когда виртуальная машина поднимается, соединения не знают, что они обращаются к другому физическому узлу, на котором находится виртуальная машина. Но какой бы механизм вы ни использовали – если *соединение* разорвано, все данные выполняющихся в данный момент транзакций будут потеряны. Поэтому ваше приложение должно разрабатываться с учётом таких ситуаций: корректно обрабатывать разрыв соединения с базой данных и возможно выполнять повторный запуск команд. Read more: Denis Reznik's blog
Posts
0 comments:
Post a Comment