(Возврат на основную страницу)
Выбор базы данных для высокой доступности: анализ SQL Server и Oracle. Часть 2 (См. Майкл Оти и Даниэль Оти. Выбор базы данных для высокой доступности: анализ SQL Server и Oracle. Часть 1 // SQL Server для администраторов. 2006. № 4.)
Зеркальное отображение базы данных
Зеркальное отображение базы данных в SQL Server 2005 является еще одной важной опцией, которая позволяет противостоять незапланированным простоям, вызванным сбоями в работе сервера или БД. Как следует из названия, зеркальное отображение базы данных обеспечивает отказоустойчивость на уровне базы данных. В случае отказа работы основной базы данных оно почти сразу активирует вторую, резервную, расположенную на резервной системе с SQL Server. Зеркальное отображение БД может быть установлено для одной или для нескольких баз данных одного сервера. Таким образом, потери данных сводятся к нулю. Резервная БД будет всегда обновляться с помощью транзакции, выполняющейся на основном сервере баз данных. Влияние работы зеркального отображения на пропускную способность транзакций либо минимально, либо равно нулю.
В отличие от служб Windows Clustering Services, которые работают на уровне сервера, зеркальное отображение базы данных реализовано на уровне базы данных. Зеркальное отображение обеспечивает почти моментальный переход на другой ресурс, всего за несколько секунд, в то время как в кластере переход на другой ресурс обычно занимает около 30 секунд — иногда больше, в зависимости от уровня активности базы данных и размера баз данных на сервере, на котором произошел сбой. Зеркальное отображение обеспечивает дополнительную защиту от сбоев в работе дисковой подсистемы, так как в данном случае нет дискового пространства общего доступа, как в решении с кластерами. Также для зеркального отображения базы данных фактически нет ограничений в расстоянии, в то время как высокодоступные решения с кластерами имеют ограничение примерно в 100 миль для обеспечения передачи сигнала о «сердцебиении». В отличие от кластеризации, которая требует специфичных конфигураций аппаратного обеспечения, зеркальное отображение базы данных работает со всем стандартным аппаратным обеспечением, которое поддерживает SQL Server. На рис. 1 показана общая схема работы зеркального отображения БД.
Зеркальное отображение реализовано с помощью трех систем: основного сервера, резервного сервера и свидетеля.
Основной сервер (Primary) — это система с SQL Server, которая предоставляет службы баз данных на текущий момент. По умолчанию все клиенты подсоединяются к основному серверу. Резервный сервер (Mirror) нужен для поддержания зеркальной копии базы данных основного сервера. Он не ограничен предоставлением только резервных служб. Другие базы данных на нем могут поддерживать другие приложения, не имеющие отношения к основному серверу. Свидетель (Witness) выступает в роли независимого третьего лица, которое определяет, какая система является основным сервером.
Зеркальное отображение БД работает через отправку журнала транзакций между основным и резервным серверами. Таким образом, оно является доставкой журнала в реальном времени. Когда клиентская система записывает транзакцию на основном сервере, эта операция сначала записывается в журнал транзакций перед записью в файл данных. Затем запись этой транзакции отправляется на резервный сервер, где она записывается в журнал транзакций этого сервера. После того как операция записывается в журнал на резервном сервере, он отправляет подтверждение на основной сервер. Это позволяет двум системам знать, что запись была получена и что теперь те же данные содержатся в журналах транзакций обоих серверов. В случае операции фиксации (Commit) основной сервер ждет подтверждения от серверазеркала, пока он не отправит ответ обратно клиенту о том, что операция завершена. Резервный сервер находится в состоянии постоянного восстановления, чтобы файлы данных обновлялись входящими данными журнала транзакций.
Чтобы обеспечивать высокую доступность для клиентских приложений, зеркальное отображение БД работает в связке с элементом Transparent Client Redirection, который являтся обновлением слоя Microsoft Data Access Components (MDAC). Transparent Client Redirection позволяет автоматически перенаправлять системы конечных пользователей на резервный сервер в случае недоступности основного сервера. Так как новая возможность, Transparent Client Redirection, реализована на уровне MDAC, для использования ее преимуществ не нужно менять клиентские приложения. Слой программного обеспечения MDAC знает об основном и о резервном серверах, получая имя резервного сервера во время начального соединения с основным сервером. Если соединение между клиентом и основным сервером прервется, MDAC попытается повторно соединиться с основным сервером. При неудаче этой попытки MDAC автоматически перенаправит следующее соединение на резервный сервер.
Зеркальное отображение базы данных может быть объединено со снимками баз данных в SQL Server 2005 для создания сервера отчетности, который использует данные на серверезеркале. Снимки баз данных обеспечивают снимок базы данных, доступный только для чтения, на определенный момент времени. На рис. 2 показан пример совместного использования зеркального отображения базы данных и снимков баз данных для создания базы данных отчетности, доступной только для чтения.
Обычно данные на серверезеркале находятся в режиме восстановления, что означает, что они не могут использоваться в приложениях. Однако вы можете создать снимок БД с зеркала, который создаст копию зеркальной базы данных, доступной только для чтения. Этот снимок может быть свободно использован в режиме только для чтения для приложений отчетности.
Доставка журнала в SQL Server 2005
Доставка журнала является высокодоступным решением, обеспечивающим восстановление после сбоев, которое может использоваться для защиты базы данных от сбоев в работе основного сервера. Доставка журнала, доступная в SQL Server 2005, а также в более ранних версиях SQL Server, была разработана в качестве недорогой защиты от сбоев в работе сервера. Доставка журнала транзакций может быть реализована на любой аппаратной платформе, на которой возможен запуск SQL Server и которая может быть настроена на работу с любыми выпусками SQL Server. Работа по доставке журнала начинается с восстанавления полной резервной копии основной базы данных на резервном сервере. С этого момента журналы транзакций отправляются с основного сервера и автоматически применяются на базе данных резервного сервера. Вы можете настроить доставку журналов с задержкой по времени для применения журналов на резервном сервере, чтобы обеспечить защиту от ошибок пользователей. Это время, устанавливаемое пользователем, дает вам окно, которое может защитить от распространения ошибок пользователей, таких как случайные удаления, неверный ввод данных, ошибки приложения и другие проблемы в данных.
Доставка журнала состоит из следующих компонентов:
• Основной сервер содержит рабочую базу данных. Запланированные задачи SQL Server Agent (jobs) выполняют периодические сохранения резервных копий журнала рабочей БД для отслеживания изменений, сделанных на рабочей базе данных.
• Резервный сервер содержит невосстановленную копию основной базы данных. Запланированные задачи SQL Server Agent (jobs) резервного сервера периодически копируют резервные копии журнала с основного сервера и восстанавливают их на резервной базе данных.
• Сервер слежения. Этот сервер отслеживает состояния основного и резервного серверов.
В отличие от служб Windows Clustering Services или зеркального отображения базы данных доставка журнала не имеет автоматического процесса переключения ролей между основным и резервным серверами. Вы можете использовать доставку журнала вместе с Windows Clustering Services для защиты от местных непредвиденных ситуаций, а также от сбоев в работе локального сервера. Доставка журнала позволяет вам поддерживать копию рабочей базы данных на одном или нескольких резервных серверах и изменение режима работы одного из резервных серверов с резервного на основной в случае сбоя в работе сервера или непредвиденных ситуаций.
SQL Server 2005: репликация
Транзакционная репликация — это еще один инструмент, который может решить проблемы, связанные со сбоями в работе сервера. В то время как репликация разработана в основном не для высокодоступных решений, так как она может отправлять транзакции с основного сервера на резервный, вы можете использовать транзакционную репликацию в качестве недорогого механизма резервного копирования сервера баз данных. На рис. 3 показана общая схема работы транзакционной репликации в SQL Server 2005.
Транзакционная репликация SQL Server состоит из трех основных компонентов:
• Издатель является источником реплицируемых данных.
• Подписчик является тем, кому предназначены реплицируемые данные. Подписчиков может быть несколько.
• Распространитель управляет рассылкой данных от издателя подписчику.
Транзакционная репликация использует снимок исходной базы данных для начальной синхронизации баз данных издателя и подписчика. Транзакции фиксируются у издателя, запоминаются и передаются подписчику (подписчикам).
Преимущество использования репликации заключается в том, что резервный сервер постоянно доступен и может быть использован как сервер отчетности. Однако изза того, что транзакционная репликация разработана не для высокой доступности, процесс переключения резервного сервера в режим основного сервера является ручным, а не автоматизированным. В добавление возврат основного сервера к его исходной роли после сбоя требует полного восстановления базы данных. Как и доставка журналов транзакций, транзакционная репликация может быть использована вместе с Windows Clustering Services для защиты данных от местных непредвиденных ситуаций с помощью реплицирования транзакций на резервный сервер.
Oracle 10g: Real Application Clusters (RAC)
Oracle поддерживает набор опций высокой доступности, очень похожий на тот, что есть в SQL Server 2005. Вы можете использовать Windows Clustering Services с восемью узлами, применяя Oracle Fail Safe. Oracle также поддерживает слабосвязанные кластеры (эквивалент доставки журнала) и транзакционную репликацию Oracle для защиты вашей организации от сбоев в работе сервера. Начиная с Oracle 9i, а также в Oracle 10g Oracle предлагает другую технологию, обеспечивающую отказоустойчивость оборудования, — Real Application Clusters от Oracle (RAC). Технология RAC доступна как в Oracle 10g Standard Edition, так и в Oracle 10g Enterprise Edition. RAC в Oracle 10g Standard Edition имеет ограничение в четыре процессора. Дополнительные средства RAC для управления, мониторинга и разбиения на разделы доступны только в Enterprise Edition. Переход с Oracle 10g Standard Edition на Enterprise Edition является дорогостоящим. Цена редакции Standard Edition на один процессор составляет $15 000, но возрастает до $40 000 на один процессор в редакции Enterprise Edition.
RAC состоит из нескольких соединенных между собой компьютеров — узлов. Программное обеспечение Oracle RAC позволяет объединенным узлам функционировать как единая среда для вычислений. Как и Windows Clustering Services, Oracle поддерживает RAC на ограниченном наборе аппаратных платформ. Вы можете найти список поддерживаемого аппаратного обеспечения и операционных систем на http://metalink.oracle.com. Oracle поддерживает RAC с 64 узлами. Максимальное количество экземпляров, которые могут быть соединены вместе, зависит от платформы операционной системы. На рис. 4 показана общая схема Oracle RAC.
В случае сбоя в работе узла возникает небольшая задержка, во время которой клиентские соединения находятся в ожидании, пока происходит обновление блокировок и повторная синхронизация узлов RAC. Oracle RAC использует архитектуру с дисковым пространством общего доступа, так что для обеспечения защиты от сбоев в работе дисков вам может понадобиться использовать функциональность компонента Data Guard от Oracle, который доступен только в редакции Enterprise Edition.
Системы с Oracle RAC обеспечивают два способа обработки отказа соединения для поддержания высокой доступности клиентского доступа:
• Переход на другой ресурс на уровне соединения. Если отказ возникает при первом соединении, приложение может повторно попытаться соединиться с другим активным узлом в кластере с помощью того же имени виртуального сервера.
• Прозрачный переход приложения на другой ресурс (TAF, Transparent Application Failover). Если отказ соединения возникает после установления, это соединение может использовать другой активный узел. Так как TAF хранит состояние текущей транзакции, он может потребовать большего количества ресурсов, чем переход на другой ресурс на уровне соединения. Чтобы использовать TAF, код приложения должен быть изменен для использования последних особенностей Oracle Call Interface (OCI) и должен включать код обработки состояния потерянной сессии. Также понадобится откатить транзакции, производившие изменения, и информация о состоянии сервера не будет переведена на другой ресурс.
Как и Windows Clustering, RAC требует, чтобы узлы имели механизмы мониторинга жизнедеятельности экземпляров. Эта возможность мониторинга узлов позволяет кластеру RAC быстро синхронизировать ресурсы во время перехода на другой ресурс. Кластеры Oracle RAC обеспечивают быстрый переход на другой ресурс на серверной стороне. Такой быстрый переход выполняется благодаря совместной архитектуре в Real Application Clusters. Другими словами, множество экземпляров Oracle одновременно активны на нескольких узлах, и эти экземпляры синхронизируют доступ к одной и той же базе данных. Все узлы также имеют параллельное владение и доступ ко всей системе хранения. Когда происходит сбой в работе одного из узлов, все другие узлы кластера попрежнему имеют доступ к системе хранения. Не нужно передавать права на владение дисковым пространством, а код сервера баз данных уже загружен в память. Процесс синхронизации узла RAC, следующий за переходом на другой ресурс, начинается с удаления узла, в работе которого произошел сбой, из кластера и продолжается с предположительным контролем ресурсов этого же узла. После перехода на другой ресурс любые незавершенные запросы начинают выполняться заново.
Oracle 10g Data Guard
Как и зеркальное отображение базы данных в SQL Server 2005, Oracle Data Guard использует данные журнала транзакций рабочей базы данных для поддержки промежуточной согласованной копии рабочей базы данных на резервном сервере. Data Guard может автоматически переключать режим работы резервной базы данных, превращая ее в рабочую базу данных в случае сбоев на рабочем сервере. Oracle Data Guard может поддерживать до девяти разных резервных копий рабочей базы данных. Data Guard работает в одном из трех режимов:
• В режиме максимальной защиты данные синхронно отправляются из основной базы данных в резервную. Транзакции не фиксируются, пока данные повторного выполнения не станут доступными в резервной БД. Если данные повторного выполнения не могут быть записаны на каждый из резервных серверов, обработка на основном сервере останавливается.
• Режим максимальной доступности работает в основном как режим максимальной защиты. Однако обработка в основной базе данных продолжается, как только данные повторного выполнения записываются на первый резервный сервер. Отсутствие доступа к резервному серверу не остановит обработку на основном сервере.
• В режиме максимальной производительности данные повторного выполнения асинхронно переносятся на резервные базы данных, в то время как основной сервер продолжает обработку транзакций. Транзакции фиксируются на основной базе данных без ожидания уведомления в получении данных повторного выполнения от резервной базы данных.
Примечание Функциональность Data Guard доступна только в Oracle Enterprise Edition.
Заключение
Высокая доступность не берется ниоткуда. Она достигается только с помощью укрепления соединения людей, процессов и технологии. План, нацеленный только на технолоию, никогда не достигнет высоких показателей доступности изза множества важных факторов, влияющих на основу доступности с помощью взаимодействия людей и процессов. Подготовка нужной аппаратной и программной платформ является только отправной точкой. С этой позиции, высокая доступность является результатом хорошего планирования и методик эксплуатации вместе с соответствующими технологиями.
Необходимость в высокой доступности диктуется вашими бизнестребованиями, а не наличием определенной технологии. В то время как создание высокодоступной среды всегда является желательным, важно помнить, что чем более высокий уровень доступности вам нужен, тем выше будут затраты. Таким образом, понимание уровня доступности, удовлетворяющего требования вашего бизнеса, является очень важным. И SQL Server 2005, и Oracle 10g имеют особенности, которые могут быть использованы для обеспечения очень высоких уровней доступности. Однако не все возможности этих платформ БД имеют одинаковую стоимость или отличаются одинаковой простотой в использовании. Microsoft SQL Server 2005 предоставляет вашей организации функциональность, обеспечивающую высокую доступность на уровне предприятия за меньшую стоимость и являющуюся более простой в использовании, чем в Oracle 10g.
Пока не грянул гром
Надежная стратегия резервного копирования очень больших баз данных (VLDB)
В случае аварии быстрое и эффективное восстановление ваших баз данных жизненно необходимо. Вы должны быть способны быстро применить план резервного восстановления, который следует заранее проверить и тщательно задокументировать. Успешный план позволит определить время возможного перерыва в работе и объем утраченных данных при восстановлении БД вашей компании. Резервное копирование и восстановление данных — очень важные и необходимые пункты любого плана аварийного восстановления, ваши стратегии резервирования и восстановления должны минимизировать возможные потери данных и время неработоспособности. Когда размеры баз данных измеряются сотнями гигабайтов или даже терабайтов, планировать минимизацию простоя и быстрого восстановления становится достаточно трудно, т. к. размеры БД увеличивают время восстановления и усложняют резервное копирование.
Создание, тестирование и обслуживание базы данных, где недопустимы даже малейшие потери данных и простои, — задачи нетривиальные. В вопросах высокой доступности очень важно определить, как долго БД может оставаться в неработоспособном состоянии. SQL Server предоставляет много возможностей для обеспечения высокой доступности, таких как создание отказоустойчивого кластера, применение репликации или передача журналов (log shipping). Однако несмотря на то, какие возможности вы выбрали и какой уровень отказоустойчивости предоставляет аппаратное обеспечение, вам всегда необходима надежная стратегия резервного копирования. Независимо от размеров базы данных или требований к доступности всегда необходимо иметь возможность восстановления. Например, при случайной модификации или удалении данных есть только один способ продолжить работу — восстановить базу данных из резервной копии в состояние до произведенных изменений.
Независимо от того, по какой причине потребовалось восстановление — будь то случайное удаление данных, отказ оборудования, природное бедствие или другой незапланированный инцидент, — ваша стратегия резервного копирования будет основой надежного плана восстановления. Вы можете восстановить резервную копию на другой сервер или в другое место на диске или можете легко передать ее в отдаленную географически местность с помощью электронных каналов связи или на съемных носителях. Резервное копирование обходится недорого и требует немного дополнительного аппаратного обеспечения, за исключением, может быть, самих носителей, таких как лента. Но при этом вы должны потратить время на изучение всех особенностей и потенциальных ловушек для того, чтобы автоматизировать процесс создания резервной копии, насколько это возможно, и сделать процесс восстановления как можно быстрее. (Более подробную информацию о восстановлении баз данных смотрите в статье Кален Дилани (Kalen Delaney) «Все о восстановлении» и «Безопасный транзит» по ссылкам http://www.sqlmag.com/Articles/ArticleID/24340/24340.html, http://www.sqlmag.com/Article/ArticleID/25983/Safe_Transit.html.) В SQL Server 2000 возможности резервного копирования и восстановления данных достаточно просты для автоматизации и комбинирования в гибкий и эффективный процесс восстановления. Они включены во все редакции SQL Server 2000. Кроме того, используя дополнительные возможности, о которых пойдет речь в этой статье, вы можете минимизировать время простоя и уменьшить потерю данных даже в случае полного отказа сервера.
Распределенные разделенные и индексированные представления
В этой статье речь пойдет о распределенных разделенных представлениях (distributed partitioned view, DPV). Вы, вероятно, слышали это модное словечко из области масштабирования SQL Server и, может быть, даже применяли DPV. Иногда их очень сложно создавать, ведь при этом важно не упустить ни одной детали.
Функциональность DPV позволяет создавать представления, связывающие несколько баз данных на одном или разных серверах. Представления позволяют выполнять над собой операции вставки, обновления, удаления и выборки. С помощью DPV вы можете разбить одну большую таблицу на несколько меньших частей, обработка которых идет быстрее и которыми проще управлять. Эти части помещают на отдельные серверы, которые называют объединенными (federated servers). Такой подход предоставляет почти неограниченные возможности масштабирования: как только производительность сервера падает, отрежьте еще кусок данных и поместите на отдельный сервер.
Примечание Распределенные разделенные представления доступны только в SQL Server Enterprise и Developer Edition.
(Возврат на основную страницу)
