Назад | Перейти на главную страницу

Нестабильное поведение MySQL с внешним хранилищем

В нашем проекте мы используем сервер MySQL 5.0.90 (движок InnoDB) с внешним хранилищем. Мы храним файлы данных MySQL во внешнем хранилище. Когда внешнее хранилище не работает по какой-либо причине, мы наблюдаем нестабильное поведение. Итак, мы сделали несколько тестов.

В Windows Server 2008

Мы закрыли внешнее хранилище физически. Служба MySQL остановлена, и мы не можем связаться с сервером. Затем мы открыли хранилище и смогли запустить сервис

Журналы

  1. 120618 14:49:30 InnoDB: Ошибка операционной системы номер 21 в файловой операции.
  2. InnoDB: некоторые номера ошибок операционной системы описаны на
  3. InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  4. InnoDB: имя файла E: \ Data \ ibdata1
  5. InnoDB: вызов операции с файлом: 'aio write'.
  6. InnoDB: невозможно продолжить работу.

Мы отключили хранилище от операционной системы. Через 3-4 минуты и несколько попыток вставки (некоторые попытки вставки завершились успешно) служба MySQL остановилась, и мы не смогли связаться с сервером.

Журналы

  1. 120618 14:27:21 InnoDB: ошибка операционной системы номер 21 в файловой операции.
  2. InnoDB: некоторые номера ошибок операционной системы описаны на
  3. InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  4. InnoDB: имя файла E: \ Data \ ibdata1
  5. InnoDB: вызов операции с файлом: 'aio read'.
  6. InnoDB: невозможно продолжить работу.

Потом сделали хранилище онлайн и попробовали запустить сервис

Журналы

  1. InnoDB: первый указанный файл данных E: \ ibdata1 не существует:
  2. InnoDB: будет создана новая база данных!
  3. 120618 14:29:00 InnoDB: Установка размера файла E: \ ibdata1 на 10 МБ
  4. InnoDB: база данных физически записывает полный файл: подождите ...
  5. InnoDB: Ошибка: все файлы журналов должны создаваться одновременно.
  6. InnoDB: все файлы журналов должны быть созданы также при создании базы данных.
  7. InnoDB: если вам нужны файлы журналов большего или меньшего размера, выключите
  8. InnoDB: база данных и убедитесь, что при завершении работы не было ошибок.
  9. InnoDB: Затем удалите существующие файлы журнала. Отредактируйте файл .cnf
  10. InnoDB: и снова запустите базу данных.
  11. 120618 14:29:00 [ОШИБКА] Механизм хранения по умолчанию (InnoDB) недоступен
  12. 120618 14:29:00 [ERROR] Прерывание

Затем мы попытались перенастроить MySQL

Журналы

  1. InnoDB: конец дампа страницы
  2. 120618 14:34:02 InnoDB: контрольная сумма страницы 1575996416, контрольная сумма до версии 4.0.14 1371122432
  3. InnoDB: сохраненная контрольная сумма 0, сохраненная контрольная сумма до версии 4.0.14 0
  4. InnoDB: страница lsn 0 0, младшие 4 байта lsn в конце страницы 0
  5. InnoDB: номер страницы (если уже сохранен на странице) 0,
  6. InnoDB: идентификатор пространства (если создан с помощью> = MySQL-4.1.1 и уже сохранен) 0
  7. 120618 14:34:02 - mysqld получил исключение 0xc0000005;

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

  9. key_buffer_size = 0

  10. read_buffer_size = 65536
  11. max_used_connections = 0
  12. max_connections = 100
  13. thread_connected = 0

  14. Возможно, что mysqld может использовать до key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections = 32000 Кбайт памяти. Надеюсь, что все в порядке; если нет, уменьшите некоторые переменные в уравнении.

  15. thd = 00000000

  16. Попытка трассировки. Вы можете использовать следующую информацию, чтобы узнать, где умер mysqld. Если после этого вы не видите никаких сообщений, что-то пошло не так ...
  17. 006D2DB6 mysqld-nt.exe! Page_cur_search_with_match () [page0cur.c: 347]
  18. 0067A777 mysqld-nt.exe! Btr_cur_search_to_nth_level () [btr0cur.c: 500]
  19. 006B2E0E mysqld-nt.exe! Btr_pcur_open_on_user_rec () [btr0pcur.c: 549]
  20. 006A5615 mysqld-nt.exe! Dict_load_indexes () [dict0load.c: 604]
  21. 006A6424 mysqld-nt.exe! Dict_load_sys_table () [dict0load.c: 1023]
  22. 006BBB20 mysqld-nt.exe! Dict_boot () [dict0boot.c: 378]
  23. 00668A79 mysqld-nt.exe! Innobase_start_or_create_for_mysql () [srv0start.c: 1462]
  24. 00444462 mysqld-nt.exe! Innobase_init () [ha_innodb.cc:1427]
  25. 0044B30D mysqld-nt.exe! Ha_init () [handler.cc:483]
  26. 004B923E mysqld-nt.exe! Init_server_components () [mysqld.cc:3431]
  27. 004BD070 mysqld-nt.exe! Win_main () [mysqld.cc:3806]
  28. c004BD43B mysqld-nt.exe! mysql_service () [mysqld.cc:3967]
  29. 006E28EF mysqld-nt.exe! _Threadstart () [thread.c: 196]
  30. 75583677 kernel32.dll! BaseThreadInitThunk ()
  31. 77359D72 ntdll.dll! RtlInitializeExceptionChain ()
  32. 77359D45 ntdll.dll! RtlInitializeExceptionChain ()
  33. Страница руководства по адресу http://dev.mysql.com/doc/mysql/en/crashing.html содержит информацию, которая должна помочь вам выяснить причину сбоя. 120618 14:29:00 [Примечание] C: \ Program Files (x86) \ MySQL \ MySQL Server 5.0 \ bin \ mysqld-nt: завершение работы

В Windows Server 2003

Сделали хранилище офлайн. Через 3-4 минуты и несколько попыток вставки (некоторые попытки вставки завершились успешно) служба MySQL остановилась, и мы не смогли связаться с сервером.

Журналы

  1. InnoDB: сканирование журнала прошло мимо контрольной точки lsn 0 9834427 120618 14:09:59 InnoDB: База данных не была завершена нормально!
  2. InnoDB: запуск восстановления после сбоя.
  3. InnoDB: чтение информации о табличном пространстве из файлов .ibd ...
  4. InnoDB: восстановление возможных наполовину записанных страниц данных из двойной записи
  5. InnoDB: буфер ...
  6. InnoDB: Выполнение восстановления: сканировано до порядкового номера журнала 0 9834574
  7. 120618 14:09:59 InnoDB: запуск пакета применения записей журнала к базе данных ...
  8. InnoDB: Прогресс в процентах: 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69. 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
  9. InnoDB: Применить пакет завершен
  10. 120618 14:10:00 InnoDB: запущен; порядковый номер журнала 0 9834574
  11. 120618 14:10:00 [Примечание] C: \ Program Files (x86) \ MySQL \ MySQL Server 5.0 \ bin \ mysqld-nt: готов к подключению.
  12. Версия: '5.0.90-community-nt' socket: '' порт: 3306 MySQL Community Edition (GPL)
  13. 120618 14:12:36 InnoDB: Ошибка операционной системы номер 21 в файловой операции.
  14. InnoDB: некоторые номера ошибок операционной системы описаны на
  15. InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  16. InnoDB: имя файла E: \ Data \ ibdata1
  17. InnoDB: вызов операции с файлом: 'aio read'.
  18. InnoDB: невозможно продолжить работу.

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

Журналы

  1. 120618 14:16:53 InnoDB: ошибка операционной системы номер 3 в файловой операции.
  2. InnoDB: ошибка означает, что система не может найти указанный путь.
  3. InnoDB: если вы устанавливаете InnoDB, помните, что вы должны создать
  4. InnoDB: каталоги сами, InnoDB их не создает.
  5. InnoDB: имя файла E: \ Data \ ibdata1
  6. InnoDB: вызов операции с файлом: 'create'.
  7. InnoDB: невозможно продолжить работу.

Не удалось запустить службу MySQL на локальном компьютере. Ошибка 1067: процесс неожиданно завершился. (СООБЩЕНИЕ ОБ ОШИБКЕ)

Мы закрыли внешнее хранилище физически. Служба MySQL остановлена, и мы не можем связаться с сервером. После этого мы открыли блок хранения и смогли запустить сервис (не автоматически)

Журналы

  1. 120618 14:01:26 InnoDB: ошибка операционной системы номер 21 в файловой операции.
  2. InnoDB: некоторые номера ошибок операционной системы описаны на
  3. InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  4. InnoDB: имя файла E: \ Data \ ibdata1
  5. InnoDB: вызов операции с файлом: 'aio write'.
  6. InnoDB: невозможно продолжить работу.

Мы ожидаем, что сервис будет запускаться автоматически после того, как хранилище будет подключено / открыто. Но эти тесты показывают нестабильное поведение. Есть ли какие-то решения для этого.

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

iSCSI - это просто протокол, который позволяет серверу получать доступ к удаленно эмулированному SCSI-диску. Не зная больше о фактическом хранилище (сколько контроллеров, есть ли кеш записи, зеркалируется ли он), я не могу быть уверен в своем ответе. Тем не менее, проблема может заключаться в последовательности.

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