Экспорт (0) Печать
Развернуть все

Вопросы высокого уровня доступности и аварийного восстановления с помощью базы данных SQL Azure

Обновлено: Апрель 2014 г.

При миграции локальной базы данных SQL Server в базу данных SQL Azure (базу данных SQL) часто возникают вопросы о том, как реализовать стратегию резервного копирования и восстановления для защиты данных от ошибок пользователей, сбоя оборудования, ошибок приложения, завершения работы центра обработки данных из-за природных катаклизмов и других аварий базы данных. В отличие от локального развертывания база данных SQL предназначена для маскирования управления файлами базы данных и операциями от администраторов. Обратите внимание на то, что сервер базы данных SQL — это логический сервер, который определяет группу баз данных. Базы данных, связанные с сервером базы данных SQL, могут размещаться на разных физических компьютерах в центре обработки данных Microsoft. Отдельная логическая база данных может совместно использовать место в одной физической базе данных с другой логической базой данных. В многопользовательской среде Azure традиционные средства резервного копирования и восстановления SQL Server не работают.

Авторы: Кун Ченг (Kun Cheng), Селсин Тюркарслан (Selcin Turkarslan)
Рецензенты: Стив Ховард (Steve Howard), Адриан Бетун (Adrian Bethune)

Каждый экземпляр базы данных SQL имеет три реплики на трех разных физических компьютерах в центре обработки данных, одну первичную и две вторичных. Все операции чтения и записи проходят через первичную реплику, и все изменения асинхронно реплицируются во вторичные реплики.

База данных SQL использует схему фиксации на основе кворума, в которой данные сначала записываются на первичную и одну вторичную реплику, только после этого транзакция считается зафиксированной. При отказе оборудования первичной реплики подключение структура базы данных SQL обнаруживает сбой и переходит на вторичную реплику. Таким образом, в центре обработки данных есть как минимум две физические, согласованные на уровне транзакций копии данных. Три реплики для каждого экземпляра базы данных Microsoft SQL Azure защищают данные от сбоя отдельных серверов, устройств или сетевого соединения. Помимо избыточных реплик структура базы данных SQL Azure создает определенное число внутренних копий данных, взятых с интервалами в 5 минут для всех баз данных, имеющихся в центре обработки данных. Эти копии хранятся в центре обработки данных и обеспечивают защиту от одновременных или катастрофических аппаратных или системных сбоев.

Среда базы данных SQL предназначена для поддержания доступности сервера вместе с обеспечением целостности данных в случае аппаратного сбоя. Во время отработки отказа экземпляр базы данных SQL может быть недоступен на короткий момент. На случай отработки отказа приложение должно иметь логику выполнения повторных операций. После сбоя приложение может использовать ту же строку подключения, чтобы повторно установить подключение к вторичной реплике после отработки отказа. Дополнительные сведения о предотвращении потери соединения см. в статье Управление ресурсами в базе данных SQL Azure на веб-узле TechNet Wiki.

Ошибка пользователя или приложения является самой частой причиной потери данных или повреждения сценариев во многих приложениях программного обеспечения. Пользователь может удалить таблицу или приложение по ошибке или отправить транзакцию дважды. За подобными типами ошибок тяжело следить. Следующие службы и инструменты помогают справиться с подобными проблемами:

  • Служба самостоятельного восстановления (для номеров SKU Premium, Standard и Basic)

  • Копирование базы данных

  • Cлужбы экспорта и импорта базы данных SQL

  • Службы SQL Server Integration Services и программа bcp

Самостоятельное восстановление. В текущей предварительной версии базы данных SQL вы можете восстановить отдельную базу данных до временной точки в определенном интервале. Интервалы формируются ежедневно и достигают 35 дней. Дополнительные сведения см. в разделе Резервное копирование и восстановление баз данных SQL Azure.

С помощью копии базы данных можно создать копию базы данных на том же или на другом сервере в этом же центре обработки данных. Это асинхронная и согласованная на уровне транзакций операция в сети. Поскольку операция является асинхронной, вы можете выдать команду copy и контролировать ее выполнение, запрашивая системное представление sys.dm_database_copies (база данных SQL).

Для того чтобы скопировать экземпляр базы данных SQL, ваше имя входа должно являться членом роли dbmanager уровня сервера на целевом сервере и быть владельцем базы данных-источника на исходном сервере. Учетные записи должны иметь одинаковые имена входа и пароли на обоих серверах баз данных SQL: исходном и целевом. Частота копирования базы данных зависит от потребностей вашего бизнеса. Для восстановления после ошибки пользователя или приложения рекомендуется создавать копии ежедневно и иметь две или три работающие копии, удаляя самую старую копию каждый день после создания свежей копии.

Несмотря на то что мы рекомендуем выполнять копирование ежедневно, копирование базы данных может выполняться еще чаще. Рекомендуется выполнять резервную копию базы данных не чаще чем раз в час. Каждый процесс копирования базы данных, выполняемый независимо от всех других процессов копирования, создаст копию базы данных, согласованную на уровне транзакций в конце процесса копирования. Каждая копия учитывается в максимум 150 базах данных для каждого сервера базы данных SQL, и плата за нее взимается как за отдельную базу данных. Потому слишком частое копирование может привести к тому, что в вашей учетной записи исчерпается предел доступных баз данных, а средства будут тратиться на оплату практически одинаковых копий базы данных. Дополнительные сведения см. в разделе Копирование баз данных в библиотеке MSDN по базе данных SQL.

Помимо средства копирования баз данных можно использовать службу SQL Database Import/Export Service. С помощью данной службы можно импортировать или экспортировать данные и схему в пакете с расширением .bacpac. Пакет содержит в сжатом формате все совместимые с базой данных SQL объекты, например таблицы, представления, индексы, ограничения, триггеры, хранимые процедуры, имена входа, пользователи и т. д. Служба может напрямую импортировать или экспортировать файлы BACPAC из экземпляра базы данных SQL в хранилище больших двоичных объектов Azure и в обратном направлении. Доступ к службе импорта-экспорта можно получить на портале управления Azure. Для прямого импорта или экспорта между локальным SQL Server и базой данных SQL без использования хранилища больших двоичных объектов Azure используйте классы из пространства имен Microsoft.SqlServer.Dac

В отличие от средства копирования баз данных служба экспорта и импорта не формирует резервные копии, согласованные на уровне транзакций. Для создания резервной копии рекомендуется заблокировать базу данных и остановить транзакции перед экспортированием данных и схемы. Также можно использовать операцию копирования базы данных, чтобы сначала создать согласованную на уровне транзакций копию, и выполнить экспорт из копии. Дополнительные сведения об импорте и экспорте см. в разделе Как импортировать и экспортировать базу данных

Средства Bulk copy utility (BCP.exe), SQL Server Integration Services (SSIS) и System.Data.SqlClient.SqlBulkCopy также схожи со службой Import/Export Service. В данный момент база данных SQL поддерживает программу BCP, массовое копирование, API-интерфейс и службы SSIS для перемещения данных. Необходимо создать объекты схемы в базе данных SQL перед загрузкой данных. Использование BCP или служб SSIS в качестве механизма массового копирования позволяет контролировать, какие объекты перемещаются в базе данных и какие данные перемещаются из этих объектов. Также можно указывать различные параметры, например размер пакета и количество потоков для получения лучшей пропускной способности, в зависимости от полосы пропускания и задержки сети.

Для защиты от потери данных в случае катастрофы в центре обработки данных следует создать хранилище резервных копий базы данных вне пределов того центра обработки данных, на котором размещена база данных приложения. Для этого рекомендуем использовать следующее.

  • Георепликация для SKU Premium и Standard.

  • Восстановление в другом регионе Azure для SKU Basic.

  • Копирование базы данных и службу экспорта и импорта базы данных SQL (описанную в предыдущем разделе) для SKU Web и Business.

Дополнительные сведения о георепликации см. в разделе Активная георепликация для базы данных SQL Azure. Для версий баз данных Azure Web и Business рекомендуется использовать следующие средства управления стратегией резервного копирования и восстановления.

  • Реализуйте стратегию копирования и восстановления для обработки ошибок приложений и пользователей с помощью следующих средств:

    • Копирование базы данных

    • Cлужбы экспорта и импорта базы данных SQL

    • Службы SQL Server Integration Services и программа Bcp

  • Реализуйте усовершенствованную стратегию резервного копирования и восстановления для обработки масштабных разрушений в центре обработки данных с помощью следующих средств:

    • Служба импорта-экспорта для миграции копий базы данных в один или несколько вторичных центров обработки данных и дополнительно в собственный локальный SQL-сервер.

Дополнительные сведения о резервном копировании, восстановлении и аварийном восстановлении в Microsoft Azure см. в разделах Непрерывность бизнес-процессов в базе данных SQL Azure и Техническое руководство по непрерывности бизнес-процессов для Azure в библиотеке MSDN.

Показ:
© 2014 Microsoft