Amazon AWS MySQL RDS кластер с внешним AWS?
Сейчас я использую AWS RDS multi-AZ с отличными результатами, проблема в том, что я хочу, чтобы моя инфраструктура была отказоустойчивой между регионами. Я ищу какой-нибудь инструмент для создания кластера с RDS и моими серверами.
Как я читаю, вы не можете кластеризовать напрямую из RDS на другой сервер, просто читайте реплики, но не между регионами и вне AWS.
Хотя я собираюсь делать какой-то mysqldump каждые 15 минут или что-то вроде этого, но это неэффективно, и восстановление может быть трудно поддерживать.
По вашему опыту, что лучше всего сделать, запустить мой mysql и настроить кластеризацию на моих машинах или сделать что-то еще. Таким образом, существует какая-то холодная репликация, которая не влияет на производительность? Я имею в виду, что каждые 5 минут синхронизация меняется. Я могу позволить себе потерю нескольких данных, но не простоев;)
Любые идеи, будут апре
2 ответа
Доступны межрегиональные копии для чтения. http://aws.typepad.com/aws/2013/11/cross-region-read-replicas-for-amazon-rds-for-mysql.html
Настройка собственного кластера MySQL (с репликацией в нескольких регионах) будет занимать много времени, обходиться дорого и требовать консультации специалиста для помощи в настройке и обслуживании. Сказав, что это может быть более надежным, чем текущее решение RDS (только если вы сделали это правильно), поскольку оно может пережить провал всего региона.
Если вам действительно нужно 100% времени безотказной работы, вам стоит обратить внимание на собственное решение. У вас есть деньги, время и ресурсы для этого? Можете ли вы позволить себе инвестировать тысячи и тысячи долларов или было бы дешевле иметь немного простоя?
У RDS были проблемы прежде (только в 2012). Интересно, что следующий сайт сообщает, что этот риск может быть значительно минимизирован с помощью "параметра восстановления на определенный момент времени"...
http://www.networkworld.com/news/2012/102312-amazon-outage-263617.html
Как и в случае с EBS, AWS напомнил клиентам, что, если они включат опцию восстановления на определенный момент времени, они смогут запустить новые экземпляры базы данных, используя резервную копию затронутой базы данных в другой зоне доступности.
Другим вариантом может быть просто убедиться, что у вас есть доступ к резервным копиям. Например, если у вас есть ежедневные резервные копии, вы можете отправить их на S3 для быстрого доступа (или, может быть, за пределами Amazon раз в неделю, если вы параноик). В случае сбоя EBS/RDS вы можете создать новый экземпляр RDS и быстрее восстановить его из S3 в случае серьезных проблем в RDS. Это решение предполагает, что у вас все в порядке с несколькими часами простоя в пользу того, что вам не придется много работать над каким-либо сумасшедшим решением для разных регионов.
Наконец, в зависимости от вашего приложения может быть дешевле попробовать воспользоваться нереляционной базой данных. Я знаю, что вы заявили, что вам нужна реляционная БД, однако реорганизация некоторых или всех приложений для использования нереляционной БД может быть проще и дешевле, чем сворачивание собственного MySQL через мультирегионы (нереляционные также дают Вы другие преимущества в масштабе и т. д.). Это решение предназначено не для всех, и может оказаться в слишком сложной для вас корзине (однако будущие проекты могут быть проще реализовать таким образом!).