В этом вопросе есть кое-что интересное - особенно в отношении идеи простоя. Часть идеи заключается в том, что если приложение чувствительно к простоям, то время восстановления также должно учитываться. (В качестве крайнего аргумента, никакие резервные копии не требуют простоя, если только вам не нужны эти резервные копии, в этом случае время простоя может приближаться к бесконечности ).
Немного о EBS
Тома и снимки EBS работают на уровне блоков - следствие этого позволяет делать снимки во время работы экземпляра, даже если том EBS используется. Однако в моментальный снимок будут включены только данные, которые на самом деле находятся на диске (то есть не в файловом кеше). Это последняя причина, которая порождает идею последовательных снимков.
- Рекомендуемый способ - отключить том, сделать его снимок и подключить его - обычно это не практично.
- Следующим лучшим вариантом является сброс кэшей записи на диск, замораживание файловой системы и создание снимка
Интересным моментом здесь является то, что в обоих вышеописанных случаях вам не нужно ждать завершения моментального снимка, чтобы снова прикрепить / разморозить и возобновить запись на диск - после того, как снимок был инициирован, ваши данные будут согласованы с этим моментом времени. Обычно для этого требуется всего несколько секунд, в течение которых ваш диск заблокирован от записи. Кроме того, поскольку большинство баз данных структурируют свои файлы на диске разумным образом, существует высокая вероятность того, что вставки будут оказывать минимальное влияние на существующие блоки, что минимизирует объем данных, добавляемых в моментальный снимок.
Рассмотрим точку резервного копирования
Тома EBS уже реплицированы в зоне доступности - так что существует определенная степень избыточности. Если ваш экземпляр завершается, вы можете просто присоединить том EBS к новому экземпляру и (после преодоления отсутствия согласованности) возобновить, где вы остановился Во многих отношениях это делает том EBS очень похожим на несовместимый снимок, при условии, что вы можете получить к нему доступ. Тем не менее, большинство пользователей EC2, вероятно, помнят каскадные сбои томов EBS с начала 2011 года - тома были недоступны в течение нескольких дней, а некоторые пользователи также потеряли данные.
RAID1
Если вы пытаетесь защититься от сбоя диска EBS (это происходит), вы можете рассмотреть вариант установки RAID1. Поскольку тома EBS являются блочными устройствами, вы можете легко использовать mdadm, чтобы настроить их в нужной вам конфигурации. Если один из ваших томов EBS не соответствует спецификациям, достаточно легко вручную его отключить (а затем заменить на другой том EBS). Конечно, у этого есть недостатки - увеличенное время для каждой записи, большая подверженность переменной производительности, удвоенная стоимость ввода-вывода (монетарий, а не производительность), никакой реальной защиты от более распространенного отказа AWS (распространенная проблема в прошлом году была невозможность отсоединения томов EBS, которые были в заблокированном состоянии), и, конечно, несогласованное состояние диска при сбое.
S3FS
Опция для некоторых приложений (определенно НЕ для баз данных) - монтировать S3 в качестве локальной файловой системы (например, через s3fs). Это медленный процесс, в нем отсутствуют некоторые функции, которые можно ожидать от файловой системы, и он может работать не так, как ожидается (возможная согласованность). Тем не менее, для такой простой цели, как сделать загруженные файлы доступными между экземплярами, это может иметь смысл. Очевидно, это не для чего-то, что требует хорошей производительности чтения / записи.
MySQL bin-log
Еще одним параметром, специфичным для MySQL, может быть использование bin-log. Вы можете настроить второй том EBS, в котором будет храниться ваш bin-журнал (чтобы минимизировать влияние добавленных записей в вашу базу данных), и использовать его вместе с любыми дампами базы данных, которые вы принимаете. Возможно, вы даже сможете сделать это с s3fs, что может иметь смысл, если производительность приемлема (хотя rsync, вероятно, будет лучше, чем пытаться использовать s3fs напрямую, и вам определенно захочется сжать то, что вы можете).
И снова мы возвращаемся к идее цели. Рассмотрим, что произойдет с приведенными выше предложениями:
- Тома EBS недоступны:
- RAID1 - бесполезен, так как вы не можете получить доступ к данным
- bin-log - бесполезно, если вы не экспортировали его в S3 - возможно, задержка, если вы это сделали
- Экземпляр неожиданно завершается:
- RAID1 - ваши диски доступны, но не согласованы, база данных может самостоятельно восстановиться после несоответствия
- bin-log - ваши данные должны быть доступны, хотя вам может потребоваться просмотреть последние несколько событий
- Кто-то запускает DROP DATABASE от имени root:
- RAID1 - у вас есть две идеальные копии несуществующей базы данных
- bin-log - вы должны быть в состоянии воспроизвести события до непосредственно перед командой, так что вы должны быть в порядке
На самом деле RAID1 в основном бесполезен, а bin-log занимает слишком много времени - оба могут иметь свои преимущества при определенных обстоятельствах, но они далеки от идеи резервного копирования.
моментальные снимки
Важно отметить, что моментальные снимки являются дифференциальными и хранят только фактические блоки, которые содержат данные (и сжимаются). В отличие от тома EBS, где, если у вас том объемом 20 ГБ, но используется только 1 ГБ, вы по-прежнему платите за «подготовленное» хранилище (20 ГБ). С моментальным снимком вы платите только за то, что используете. Если данные не меняются между снимками, то (теоретически) плата не взимается. (Снимки взимаются за ПОЛОЖЕНИЯ / ПОЛУЧЕНИЯ и использованное хранилище).
Кроме того, я настоятельно рекомендую, чтобы данные вашего приложения (включая базы данных) не сохранялись на вашем корневом томе (который вы, возможно, уже настроили). Одним из преимуществ является то, что, надеюсь, ваш корневой том видит минимум изменений - это означает, что его снимки могут быть менее частыми (или будут иметь минимум изменений), что снижает стоимость и простоту использования.
Также важно упомянуть, что вы можете удалить старые снимки в любое время - даже если они являются дифференциальными, они не влияют на другие снимки. При этом каждый блок, выделенный для моментального снимка, не будет освобожден до тех пор, пока не останется моментальный снимок, который все еще ссылается на этот блок.
Проблема с периодическими дампами - это, во-первых, время между дампами (возможно, решаемое с помощью bin-журнала MySQL), а также сложность восстановления. Требуется время, чтобы импортировать большой дамп и воспроизвести все события из бинарного журнала. Кроме того, создание дампа не лишено последствий для производительности. Возможно, такие дампы, вероятно, требуют гораздо больше памяти, чем снимок. Настройка тома EBS исключительно для баз данных и создание моментальных снимков, которые были бы предпочтительны в большинстве случаев (при этом создание моментального снимка также имеет некоторое влияние на производительность).
Прелесть снимков и томов EBS заключается в том, что они могут использоваться в других случаях. Если ваш экземпляр не загружается, вы можете присоединить корневой том к другому экземпляру для диагностики и устранения проблемы - или просто скопировать с него свои данные - и можете переключать корневые тома всего за пару минут простоя (остановите экземпляр, отсоедините корневой том, присоедините новый корневой том, запустите экземпляр). Эта же идея относится и к тому, что ваши данные хранятся во втором томе EBS. По сути, вы просто раскручиваете новый экземпляр из своего пользовательского AMI и подключаете к нему текущий том EBS - это помогает минимизировать время простоя.
(Можно привести аргумент (и я, вероятно, не рекомендую его), что вы можете установить две копии MySQL на одном сервере (главный-подчиненный), используя два тома EBS, а затем завершить работу своего ведомого устройства, чтобы сделать снимок его Объем EBS - он будет согласованным, без простоев - но затраты на производительность, вероятно, не стоят того).
AWS имеет автоматическое масштабирование, которое будет поддерживать постоянное количество экземпляров (даже если это число равно 1), однако вы бы развернули его из снимка - поэтому, если ваш снимок бесполезен, то предпосылка не очень полезна ,
Еще пара моментов - вы можете развернуть столько экземпляров, сколько захотите, из одного снимка (в отличие от тома EBS, который можно подключить только к одному экземпляру в любой момент времени). Кроме того, тома EBS ограничены для использования в зоне доступности, в то время как моментальные снимки могут использоваться в пределах региона.
В идеале, с моментальным снимком, если ваш сервер выходит из строя, вы можете просто запустить новый, используя последний моментальный снимок - особенно если вы отделяете свой корневой том от ваших данных, плохое обновление должно привести к минимуму времени простоя (так как вы просто перенесите том EBS, содержащий ваши данные, и сделайте его снимок, чтобы сохранить все, что может быть повреждено из-за несогласованности).
В качестве примечания, Amazon заявляет, что частота отказов томов EBS увеличивается с количеством данных, измененных на них с момента последнего снимка.
Окончательные рекомендации
- Используйте снимки - они великолепны - они сокращают время простоя намного больше, чем его вызывают
- Разделите данные и корневой том, возможно даже разместив базы данных на собственном томе, и снимок перед обновлениями, если это необходимо
- Используйте бинарный журнал, чтобы оставаться как можно более «горячим» - загрузите это (сжатое) на S3
- Убедитесь, что вы действительно извлекаете данные из экземпляра (даже если данные на томе EBS не повреждены, сам том может быть временно недоступен).
Рекомендуемое чтение:
(Я верю, что написал слишком много, но недостаточно сказал - но, надеюсь, вы найдете что-то стоящее для чтения).