Я много читал о aws ebs и многие, похоже, призывают людей заморозить файловую систему.в течениеснимок. Однако эта часть документации Amazon позволяет не согласиться:
Во время завершения процесса создания моментального снимка на него не влияют текущие операции чтения и записи в томе.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Почему у многих людей файловая система замораживается во время создания снимка, хотя в документации AWS говорится, что на снимок не влияет ввод-вывод?
Что делать, если моя файловая система используется для FTP?
Что делать, если моя файловая система используется для базы данных?
решение1
Короткий ответ:это действительно зависит от типа приложения, которое вы запускаете на своем экземпляре.
Длинный ответ:По сути, создание моментального снимка работающего механизма в состоянии покоя похоже на «выдергивание вилки из розетки» — то есть на внезапный, мгновенный, неожиданный сбой.
При работе с включенным барьером ввода-вывода современная журналируемая файловая система должна быть согласованной, несмотря на любые сбои. Этонетозначает, что данные в памяти не будут потеряны; скорее, зафиксированные данные будутгарантированодля хранения на постоянном носителе (например, на диске).
Это действительно применимо к любому правильно журналируемому приложению, особенно к базам данных, совместимым с ACID (неполный список: MSSQL, InnoDB, PostgreSQL, Oracle, IBM DB2 и т. д.). Опять же, это ненетозначает, что внезапное отключение питания (или восстановленный, не приостановленный снимок) не приведет к потере данных; скорее, это означает, что когда возвращается (возможно, неявный) COMMIT, все соответствующие данные находятся в стабильном хранилище.
С таким журналируемым приложением вам не нужно строго останавливать файловую систему. При первой загрузке после восстановленного снимка система ответит своими журналами (файловой системы и баз данных) и будет достигнуто согласованное состояние.
Однако есть много приложений, которые делают этонетправильно вести журнал своих обновлений, и которыетребоватьэквивалент a fsckдля возврата в согласованное состояние. Основной пример — MySQL+MyISAM: этот (очень распространенный) движок базы данныхнетСоответствует ACID, поскольку его высокая скорость записи достигается за счет пакетирования несвязанных операций ввода-вывода с малым учетом обычных барьеров ввода-вывода. Неправильное завершение работы (например, отключение питания, сбой системы или mysql, неактивированный снимок) базы данных MyISAM может быть неработоспособной, пока не mysqlcheck/mysqlrepairбудет выполнено.
Различные руководства, рекомендующие приостанавливать работу файловой системы перед созданием снимка, делают это именно по этой причине: некоторые «неподготовленные» приложения (читай: MyISAM) могут быть в некоторой степени повреждены внезапным завершением работы и последующим восстановлением, что потребует проверки согласованности.
Нижняя граница:если вы используете журналируемую файловую систему с включенными барьерами ввода-вывода (по умолчанию для ext4 и XFS)ибаза данных, совместимая с ACID, вы можете быть уверены в том, что делаете нестабильные снимки. В худшем случае вы можете увидеть некоторые нефатальные ошибки/предупреждения при монтировании снимка, но ответ журнала приведет систему в согласованное состояние. Однако, если вы используете MyISAM, лучше заморозить/приостановить вашу файловую систему перед созданием снимка.
решение2
Снимки Amazon сами по себе небезопасны, если сделаны во время работы системы. Они безопасны, если вы выключите систему перед созданием снимка. Любые данные файловой системы, которые кэшируются в буферах операционной системы или в буферах приложений (например, базы данных), не будут частью снимка. Это может привести к неустранимому повреждению.
Как Linux, так и Windows имеют механизмы, предоставляемые ОС для заморозки системы (информирования приложений о необходимости сбросить свои данные на диск). После завершения этого процесса выполняется размораживание, позволяющее приложениям продолжить работу. Между заморозкой и размораживанием делается снимок. Примечание: большинство приложений не поддерживают заморозку/размораживание, а некоторые реализуют его неправильно. Внимательно изучите документацию вашего поставщика.
Другим важным пунктом является проверка того, где ваши приложения хранят свои данные. Базы данных, согласно передовой практике, хранят свои данные, журналы и т. д. в разных файловых системах. Это означает, что вы можете начать снимок одного тома в разное время по сравнению со снимком другого тома (который может потребоваться в качестве набора для успешного восстановления приложения и его данных).
Главное — понять разницу между снимками, устойчивыми к сбоям, и снимками, устойчивыми к приложениям.
Вот статья о снимках EBS, в которой объясняются различия.
Снимки EBS: устойчивость к сбоям и устойчивость к приложениям
[Обновление после комментариев Майкла]
Снимки реализуют Copy-on-Write (COW). После запуска снимка файловая система может быть изменена. Если файловая система записывает данные в дисковый блок, подсистема COW скопирует исходный блок в свой внутренний кэш, чтобы файловая система могла быть изменена во время снимка.
Нет необходимости держать файловую систему замороженной во время снимка. Во время создания снимка создаются/копируются необходимые структуры данных тома, так что заморозка не требуется. В зависимости от системы и объема данных, кэшируемых в памяти, размера журналов ОС и приложений и т. д. цикл заморозки/снимка/размораживания может быть быстрым, всего за пару секунд.
Вот статья о различных технологиях моментальных снимков, включающая объяснение Copy-on-Write:
Использование различных типов технологий моментальных снимков хранилища для защиты данных