Потеря данных MySql - посмертный анализ - RackSpace Cloud Server

После недавней "экстренной миграции" облачного сервера RS базы данных mysql на снимке нашего сервера оказались на несколько дней позже даты резервного копирования. И все же файлы, загруженные через уязвимое веб-приложение, были записаны в файловую систему. Связанные метаданные, которые были записаны в базу данных, были утеряны, но сами файлы были скопированы.

После того, как я смог вручную получить доступ к файлам данных mysql до запуска сервера mysql (сервер был настроен на запуск mysql при загрузке), я смог увидеть, что время обновления для ib_logfile1, ib_logfile0 и ibdata1 устарело.

Как и в случае с этим плакатом, потеря данных mysql после сбоя сервера выглядит так, как будто какой-то контроллер кэширования сказал серверу OS / mysql, что он зафиксировал данные, которые все еще находились в кэше, и был потерян, а не очищен.

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

Любые предложения относительно того, как это могло произойти?

ОБНОВЛЕНИЕ ВТОРОЕ:

Смотрите мой ответ ниже, который объясняет, что случилось.

ОБНОВИТЬ:

Подробности конфигурации, согласно запросу.

Информация о RackSpace Cloud Server:
ОС: Ubuntu 10.04 LTS (Lucid)
Оперативная память: 1024 МБ
Дисковое пространство: 40 ГБ
Центр обработки данных: ORD1
Уровень обслуживания: неуправляемый
root@restore-testing:~# dpkg -s mysql-сервер...
Архитектура: все
Источник: mysql-dfsg-5.1
Версия: 5.1.61-0ubuntu0.10.04.1...
root @ restore-testing: ~ # cat / etc / fstab
proc / proc proc по умолчанию 0 0
/dev/xvda1       /           ext3 по умолчанию, ошибки =remount-ro,noatime    0 1
/dev/xvdc1 нет своп sw          0 0
Источник

2 ответа

Решение

Хотя некоторые настройки 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 продолжать сбрасывать данные на устаревшие inode?

Быстрый тест позже, и ответ - да. MySql не замечает, что он пишет в недействительные дескрипторы файлов, когда его данные и файлы журналов были заменены, но пул буферов в памяти способен удовлетворить все запросы. Учитывая размер нашей базы данных (небольшой) и объем запросов (низкий), пул буферов, вероятно, продолжал бы обрабатывать наши запросы в течение некоторого времени.

Источник

Я вижу, что это происходит в зависимости от метода сброса данных Innodb.

Пожалуйста, посмотрите innodb_flush_method, используемый вашей установкой MySQL. В зависимости от установленного значения (O_DSYNC или O_DIRECT) InnoDB может либо удвоить буфер для ОС и буферного пула InnoDB, либо только для буферного пула InnoDB. Если для переменной задано кэширование только в пул буферов, я могу быстро увидеть, как исчезают данные, если при восстановлении операционной системы пул буферов в процессе. Я написал пост в DBA StackExchange об этом.

Вот еще одна ссылка, касающаяся использования MySQL в облаке против голого металла ( нажмите здесь) . Он называет три потенциальные проблемы / проблемы, связанные с перемещением MySQL в облачную среду:

  • Виртуальные IP-адреса
  • Конфигурация памяти
  • Медленные диски

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

Кстати, в StackOverflow есть хороший пост о плюсах и минусах MySQL в облаке.

Чтобы еще больше подчеркнуть этот аспект, облачные среды предоставляют географическую репликацию экземпляра mysql от Восточного побережья до Западного побережья. Когда я лично провел 30-дневную оценку службы базы данных XEROUND (мне были предоставлены два общедоступных IP-адреса), я увидел очень плохую прерывистость (около 5-6 минут) между IP-адресами. Можете ли вы представить себе потерю данных во время этого окна из-за сбоя на обоих концах? Ваша потеря данных произошла из-за экстренного ручного вмешательства.

РЕКОМЕНДАЦИЯ

ИМХО, я бы переключил ваши базы данных MySQL на голое железо и использовал бы либо DRBD, либо MySQL Replication для избыточности данных. Вы можете поддерживать все облачные сервисы для веб-серверов и серверов приложений.

Источник
Другие вопросы по тегам