Анализ альтернативных архитектур управления транзакциями в облачной среде

       

AWS MySQL/R


Для исследования архитектуры с репликацией (рис. 3) мы использовали MySQL Replication версии 5.0.51 на некотором наборе машин EC2. В этом варианте мы использовали для хранения базы данных (более дешевые) локальные диски машин EC2, поскольку долговечность данных обеспечивалась архитектурой репликации. EBS использовалось только для журналов эталонной копии. Эти журналы требовались для перехода к использованию резервного оборудования после отказа мастер-сервера.

В MySQL Replication используется протокол ROWA/эталонная копия, описанный в подразделе 3.3, для синхронизации всех запросов на обновление, а запросы от приложений на чтение могут обрабатываться любым сервером-сателлитом. Репликация не является прозрачной. Поэтому в каждом сервере приложений поддерживаются подключения к мастер-серверу и к одному серверу-сателлиту. Запросы обновляющих транзакций обрабатываются мастер-сервером, в то время как запросы только читающих транзакций направляются серверам-сателлитам, ассоциированным с сервером приложений. Как и при использовании AWS MySQL Tomcat использовался как интегрированный сервер Web и приложений, и число машин для этого уровня изменялось в зависимости от рабочей нагрузки.

Мы также экспериментировали с MySQL Cluster версий 5.0.51 и 7.0.8a. Использование MySQL Cluster сулило горизонтальное масштабирование при наращивании числа серверов [17]. К сожалению, обе эти версии MySQL Cluster показали в наших экспериментах производительность, худшую, чем у одиночной системы MySQL (AWS MySQL), и поэтому мы не представляем полученные результаты в этой статье. Мы не можем объяснить, почему нам не удалось воспроизвести результаты [17] в "облачной" среде Amazon.



Содержание раздела