Использование репликации баз данных в облачной среде

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

Пример простой среды, использующей репликацию, показан на рис. 4.9.

В этой структуре имеется единственный сервер главной базы данных, работающий на запись (master), который распространяет копии главной базы данных на один или несколько подчиненных серверов (slaves). В общем случае1 процесс, осуществляющий репликацию данных с главной базы данных в подчиненные, не является атомарным в отношении оригинальной транзакции. Иными словами, сам факт успешного подтверждения транзакции на главном сервере еще не значит, что она будет успешно реплицирована в подчиненные базы данных. Системы, которые могут это гарантировать, обычно обеспечивают атомарность. В результате подчиненные базы данных могут быть рассинхронизированы с главной, потому что, хотя подчиненная база данных и может быть рассинхронизирована с главной, она все же должна сохранять внутренне непротиворечивое состояние (иными словами, оставаться неповрежденной).

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

Рис. 4.9. Схема простой среды на базе репликации (направление стрелки указывает на зависимость)

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

Восстановление после сбоя сервера главной базы данных окажется более сложным. Если вы пользуетесь облачными сервисами Amazon, вы столкнетесь с дополнительными препятствиями, которых вы не встретите в стандартной среде с репликацией.

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

Дальнейшее восстановление базы данных с использованием подчиненного сервера может пройти одним из двух способов.

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

± Построение нового главного сервера баз данных и экспортирование базы данных в ее текущем состоянии с подчиненного сервера на новый главный сервер.

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

ВНИМАНИЕ!

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

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

Подробную информацию о репликации MySQL можно найти в книге [3].

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100