После недавней «экстренной миграции» облачного сервера RS оказалось, что базы данных mysql на нашем образе моментального снимка сервера устарели на несколько дней с даты резервного копирования. И все же файлы, которые были загружены через уязвимое веб-приложение, были записаны в файловую систему. Связанные метаданные, записанные в базу данных, были потеряны, но для самих файлов были созданы резервные копии.
Как только я смог вручную получить доступ к файлам данных mysql перед запуском сервера mysql (сервер был настроен на запуск mysql при загрузке), я смог увидеть, что время обновления для ib_logfile1, ib_logfile0 и ibdata1 прошло несколько дней.
Как и в случае с этим плакатом, потеря данных mysql после сбоя сервера, это как если бы какой-то контроллер кеширования сообщил серверу OS / mysql, что он зафиксировал данные, которые все еще находились в кеше, и они были потеряны, а не сброшены.
Я не могу понять, как загруженные файлы были записаны, а данные базы данных - нет. Я бы подумал, что любой кеш очистит всю систему, а не процесс за процессом.
Есть предложения относительно того, как это могло произойти?
ОБНОВЛЕНИЕ ВТОРОЕ:
Смотрите мой ответ ниже, который объясняет, что произошло.
ОБНОВИТЬ:
Подробная информация о конфигурации по запросу.
RackSpace Cloud Server Details: OS: Ubuntu 10.04 LTS (Lucid) RAM: 1024 MB Disk Space: 40 GB Datacenter: ORD1 Service Level: unmanaged
root@restore-testing:~# dpkg -s mysql-server ... Architecture: all Source: mysql-dfsg-5.1 Version: 5.1.61-0ubuntu0.10.04.1 ...
root@restore-testing:~# cat /etc/fstab proc /proc proc defaults 0 0 /dev/xvda1 / ext3 defaults,errors=remount-ro,noatime 0 1 /dev/xvdc1 none swap sw 0 0
Я вижу, что это происходит в зависимости от метода очистки данных Innodb.
Пожалуйста, посмотрите innodb_flush_method используется вашей установкой MySQL. В зависимости от набора значений (O_DSYNC или O_DIRECT) InnoDB может либо удвоить буфер для ОС и пула буферов InnoDB, либо просто пула буферов InnoDB. Если для переменной задано кеширование только в пул буферов, я могу быстро увидеть, что данные исчезают, если восстановление ОС уничтожило пул буферов в процессе. Я написал сообщение об этом в DBA StackExchange..
Вот еще одна ссылка, касающаяся использования MySQL в облаке по сравнению с голым железом ( Кликните сюда ). Он называет три потенциальных проблемы / проблемы, которые возникают при переносе MySQL в облачную среду:
Даже если эти ограничения были преодолены после выхода этой статьи, разумно переосмыслить, где будут находиться критически важные данные. Это особенно верно с учетом того, что только что произошло с вашими данными.
Кстати У StackOverflow есть хороший пост о плюсах и минусах MySQL в облаке.
Чтобы развить этот момент с другого аспекта, облачные среды обеспечивают географическую репликацию экземпляра mysql от Восточного побережья до Западного побережья. Когда я лично провел 30-дневную оценку службы базы данных XEROUND (мне предоставили два общедоступных IP-адреса), я увидел очень плохую прерывистость (около 5-6 минут) между IP-адресами. Можете ли вы представить потерю данных во время этого окна из-за сбоя на любом конце? Ваши данные были потеряны в результате экстренного ручного вмешательства.
IMHO, я бы переключил ваши базы данных MySQL на «голый металл» и использовал DRBD или MySQL Replication для избыточности данных. Вы можете поддерживать все облачные сервисы для веб-серверов и серверов приложений.
Хотя некоторые настройки innodb_flush_method в сочетании с определенным оборудованием может привести к потере данных с отказом оборудования, без комбинации innodb_flush_method и innodb_flush_log_at_trx_commit объясните, как файлы ib_logfile1 и ib_logfile2 могут быть устаревшими на несколько дней.
Я перенес серверы примерно на отметку времени файлов базы данных. Я медленно отключил mysql на обоих серверах и rsync'd / var / lib / mysql с одного на другой. Веб-приложения появились и зарегистрировались на новом сервере.
Но что, если я забыл monit unmonitor mysql на целевом сервере и перезапустил mysql? Может быть, я заменил файлы данных и журналов на работающем сервере mysql? Будет ли mysql продолжать беспечно сбрасывать данные в устаревшие inodes?
Быстрый тест позже, и ответ - да. MySql не замечает, что он выполняет запись в недопустимые дескрипторы файлов, когда его файлы данных и журнала были заменены, но пул буферов в памяти может удовлетворить все запросы. Учитывая размер нашей базы данных (небольшой) и объем запросов (низкий), буферный пул, вероятно, продолжал бы обрабатывать наши запросы в течение некоторого времени.