Это потребительское приложение, поэтому я позабочусь о расходах на хранение - я не хочу, чтобы вокруг лежали 5-кратные копии данных. Приложение отлично разделяется, поэтому я могу использовать MySQL и не иметь проблем с масштабированием.
Amazon EBS имеет отличную возможность резервного копирования базовых данных + моментальных снимков с использованием S3. Он должен занимать мало места (с точки зрения стоимости хранения).
НО: история с magnolia.com пугает меня до чертиков: в основном безупречное резервное копирование на уровне блоков поврежденной БД или файловой системы.
Есть ли что-нибудь, что почти так же эффективно, как EBS на уровне MySQL?
Альтернативы холодному удаленному резервному копированию нет.
Любая резервная копия, которая всегда в сети и взаимодействует с действующими серверами, особенно с одним в том же центре обработки данных, может быть взломана злоумышленниками или сбой по какой-либо причине, которая убивает оригинал (пожар, наводнение и т. Д.). По этим двум причинам вам, вероятно, потребуется резервное копирование в реальном времени, близкое к реальному, на случай, если вы сделаете что-то упрямое по ошибке, и реже холодное резервное копирование за пределами площадки. Прелесть холодных внешних резервных копий в том, что они максимально изолированы от любого мыслимого сценария (спасите гнусного человека, чтобы уничтожить все ваши данные любой ценой), и хотя вы можете потерять несколько дней / недель данных, это лучше, чем потерять все.
Что касается резервного копирования плохих данных, любая система резервного копирования может незаметно создавать резервные копии поврежденных данных, для этого нужны регулярные тесты.
Если вы можете получить лучшую скорость хранения, чем EBS, с другого хоста (не сложно), вы можете настроить этот хост в качестве ведомого устройства MySQL и создать свой собственный LVM-диск для MySQL, что позволит вам регулярно выполнять моментальные снимки LVM. Независимо от того, какой механизм моментальных снимков вы используете, убедитесь, что вы очистили свои таблицы и заблокировали их чтение, чтобы сохранить целостность данных. Видеть http://lists.mysql.com/replication/1741 для получения дополнительной информации. Если вы используете подчиненное устройство только для чтения, вы, вероятно, можете просто выполнить остановку подчиненного устройства и сбросить его, хотя блокировка чтения не повредит.
В качестве альтернативы вы можете просто полностью остановить свое ведомое устройство чтения, выключив сервер SQL, а затем использовать rdiff-backup, который является инкрементным резервным копированием, только резервное копирование изменений, чтобы также скопировать файлы MySQL.
Однако настоящий ответ таков: вам, вероятно, все это не нужно. Вероятно, вам удастся время от времени автоматически выполнять mysqldump, сжимать его и выгружать на S3, периодически загружая копии на домашний компьютер для резервного копирования.
Оцените поставщика облачного резервного копирования с дедупликацией - Asigra - лидер в этой области. Если возможно, вы хотите, чтобы данные резервного копирования находились на других шпинделях и в электросетях, чем ваши основные данные.
Дедупликация должна помочь сохранить доступность за счет снижения потребления полосы пропускания.
Вероятно, вам следует настроить регулярное логическое резервное копирование, что для mysql, вероятно, означает настройку выделенного ведомого устройства для выполнения mysqldumps. Их также следует перезагружать и регулярно тестировать.
Если вы действительно обеспокоены, возможно, стоит изучить базу данных, которая будет выполнять некоторый уровень контрольной суммы данных и / или файлов журнала. Кроме того, файловая система, которая подсчитывает контрольные суммы данных, также может быть полезна для предотвращения повреждения на уровне диска.
Какой размер базы данных мы здесь рассматриваем? Лично я использую mysqlhotcopy для таблиц MyISAM и храню несколько копий. Но без лишних копий я полагаю, вы могли бы сохранить двоичные журналы. В двоичных журналах для репликации все запросы выполняются с определенной позиции. Возможно, вы могли бы создать систему, которая хранит копию фактической базы данных, а также двоичные журналы из последней резервной копии для инкрементных резервных копий.