AWS RDS - автоматическое резервное копирование и снимок с таблицами MyISAM

Проблема заключается не в создании моментальных снимков. Это может пойти не так, когда вы на самом деле пытаетесь использовать один из снимков.

Снимки RDS работают путем записи моментального снимка, если ваш экземпляр RDS, лежащий в основе объема EBS (вы не можете видеть этот том, но он там - RDS работает на EC2 со "скрытыми" экземплярами и томами).

Снимки EBS захватывают все содержимое жесткого диска точно так же, как они существовали в тот момент, когда начинается процесс моментального снимка.

То, что заканчивается на снимке, - это, по сути, то же самое, что и на сервере MySQL, если вы выполнили sudo killall -9 mysqld - это как если бы сервер остановил все, сразу, без каких-либо действий, делает, чтобы очистить для изящного отключения. С RDS все не так драматично, потому что RDS действительно принимает некоторые меры предосторожности, но в корне это характер происходящего.

Когда вы создаете экземпляр RDS из моментального снимка, первое, что случается при запуске экземпляра, - это то же, что ваш гипотетический сервер будет делать, когда вы перезапустите убитый демон MySQL Server: InnoDB Crash Recovery.

Восстановление InnoDB Crash

Для восстановления после сбоя сервера MySQL единственным требованием является перезапуск сервера MySQL. InnoDB автоматически проверяет журналы и выполняет переключение базы данных к настоящему. InnoDB автоматически откатывает незафиксированные транзакции, которые присутствовали во время сбоя.

https://dev.mysql.com/doc/refman/5.7/en/innodb-recovery.html#innodb-crash-recovery

Восстановление при сбоях - это механизм InnoDB, который возвращает все в гармонию в его внутренние структуры данных и гарантирует, что все данные не повреждены, точно так же, как ваше приложение оставило его. Это возможно, потому что InnoDB является механизмом транзакционного хранения. Это означает много разных вещей, но в этом случае именно это означает, что InnoDB не просто меняет данные таблицы при изменении таблицы. Он проходит процесс, который может быть упрощен примерно так:

• сохраните предлагаемые изменения на диске¹
• действительно внести изменения
• отметьте изменения как завершенные

Это означает, что до тех пор, пока изменения не будут завершены, InnoDB может быть прерван и впоследствии сможет забрать, где он остановился, без искажения или потери данных.

MyISAM не имеет таких механизмов. Он просто записывает файлы данных напрямую. Даже если таблица MyISAM активно не используется, ее все равно придется ремонтировать, когда сервер подходит, чтобы очистить свои структуры. В некоторых случаях восстановление таблицы может быть невозможно, и все или часть данных в таблице будут потеряны.

Если ваши снимки MyISAM очищаются и блокируются, когда происходит моментальный снимок, они находятся в состоянии покоя на диске, как если бы сервер фактически был изящно отключен до момента создания моментального снимка, поэтому они будут стабильными в моментальном снимке.

Но процесс моментального снимка всегда будет успешным, потому что моментальный снимок просто дублирует все, что есть на диске, так как оно появляется в тот момент, когда моментальный снимок запускается.

Проблема в том, что захваченный снимок может не использоваться, и вы не можете узнать, будет ли этот снимок полностью жизнеспособным.

¹ Обратите внимание, что первый шаг "сохранить предлагаемые изменения на диске" связан с системной переменной innodb_flush_log_at_trx_commit которая делает систему более медленной, если она установлена в 1 но также является самым безопасным параметром, поскольку ваш запрос на самом деле не выполняется до этого первого шага готово. Параметр 2 по-прежнему достаточно безопасен, поскольку он все еще записывает изменения, но продолжает, не требуя, чтобы операционная система подтвердила, что они действительно были записаны на жесткий диск, прежде чем ваш запрос вернет успех... но в случае сбоя транзакция приложение полагает, что было совершено, может или не может сохраниться.