У нас есть группа потребительских терминалов, на которых установлены Linux, локальный веб-сервер и PostgreSQL. Мы получаем полевые отчеты о машинах с проблемами, и после расследования кажется, что произошло отключение электроэнергии, а теперь что-то не так с диском.
Я предполагал, что проблема будет только в том, что база данных будет повреждена или файлы с последними изменениями будут зашифрованы, но есть и другие странные отчеты.
index.php теперь каталог)Есть проблемы с повреждением базы данных, но этого я мог ожидать. Больше всего меня удивляют более простые проблемы с файловой системой - например, разрешения или изменение файла в каталоге. Проблемы также возникают в файлах, которые не менялись в последнее время (например, в программном коде и конфигурации).
Это «нормально» для повреждения SSD? Первоначально мы думали, что это происходит с некоторыми дешевыми твердотельными накопителями, но у нас это происходит с именным брендом (потребительский уровень).
FWIW, мы не делаем autofsck при нечистой загрузке (не знаю почему - я новичок). В некоторых местах у нас установлены ИБП, но иногда это делается неправильно и т. Д. Это должно быть исправлено, но даже в этом случае люди могут нечисто отключить питание терминала и т. Д. - так что это небезопасно. Файловая система - ext4.
Вопрос: можем ли мы что-нибудь сделать, чтобы смягчить проблему на системном уровне?
Я нашел несколько статей, относящихся к отключению аппаратного кеша или установке диска в режиме синхронизации, но я не уверен, поможет ли это в этом случае (повреждение метаданных и недавние изменения). Я также прочитал ссылку на монтирование файловой системы в режиме только для чтения. Мы не можем этого сделать, потому что нам нужно писать, но мы могли бы сделать раздел только для чтения для кода и конфигурации, если бы это помогло.
Это пример привода sudo hdparm -i /dev/sda1:
Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7
При внезапном отключении питания твердотельные накопители MLC / TLC / QLC два режимы отказа:
Первое условие отказа очевидно: без защиты питания любые данные, которые находятся не в стабильном хранилище (например, в самой NAND), а только в энергозависимом кэше (DRAM), будут потеряны. То же самое происходит с классическими механическими дисками (и только это может нанести ущерб файловой системе, которая не выполняет должным образом fsyncs).
Второе условие отказа - это проблема MLC + SSD: при перепрограммировании старшего бита страницы для хранения новых данных неожиданная потеря мощности может разрушить / изменить младший бит (т. Е. Предыдущий совершенный данные) также.
Единственное верное и наиболее очевидное решение - это интегрировать кэш DRAM с защитой от потери питания (обычно с использованием батарей / суперкапсов), как это всегда делается с помощью высокопроизводительных RAID-контроллеров; это, однако, увеличивает стоимость / цену привода. Потребительские диски обычно не имеют кэшей с защитой от потери питания; они скорее используют ряд более экономичных решений, таких как:
Вернемся к вашему вопросу: ваши диски Kingstone сверхдешевые, с неуказанным контроллером и в основном без общедоступных спецификаций. Меня не удивляет, что из-за внезапного отключения питания предыдущие данные были повреждены. К сожалению, даже отключение кэша DRAM диска (с огромной потерей производительности, которую он командует) приведет к не Решите вашу проблему, поскольку предыдущие данные (например, данные в состоянии покоя) могут и будут повреждены из-за необнаруженных потерь мощности. Если они основаны на старом контроллере Sandforce, при «правильных» обстоятельствах можно ожидать даже полного блока привода.
Я настоятельно рекомендую пересмотреть ваш ИБП и в среднесрочной перспективе заменить эти устаревшие диски.
Последнее замечание о PostgreSQL и других базах данных Linux: они будут не отключить кеш диска и должен не быть рассчитанным на это. Скорее они используют периодические / необходимые fsyncs / FUA для фиксации ключевых данных в стабильном хранилище. Так следует поступать, если только очень есть веская причина (например: диск, который лжет о ATA FLUSHES / FUA).
РЕДАКТИРОВАТЬ: если возможно, подумайте о переходе на файловую систему с контрольной суммой как ZFS или BTRFS. По крайней мере, рассмотрите XFS, у которой есть контрольная сумма журнала, а в последнее время даже контрольная сумма метаданных. Если вы вынуждены использовать EXT4, подумайте о включении auto-fsck при запуске (fsck.ext4 очень хорош при исправлении повреждений).
Да. Не покупайте сверхдешевые SSD - все, что не относится к потребительскому рынку начального уровня, имеет конденсаторы и полную защиту от потери мощности. Amd действительно не намного дороже.
Первое, что нужно сделать, это определить время восстановления и цели точки восстановления. Как долго вам нужно восстанавливать один из этих терминалов и какой момент времени является приемлемым? Возможно, в течение пары часов вам нужно будет восстановить резервную копию, сделанную на прошлой неделе.
С файлами могут происходить всевозможные странные вещи, если в процессе записи теряются записи. Приоритет файловой системы заключается в поддержании согласованности собственных метаданных, они могут не предоставлять таких же гарантий для ваших данных. Другими словами, fsck не гарантируется восстановление ваших данных. Его задача - предоставить вам файловую систему, которая будет смонтирована.
Итак, сила. Установите, настройте и проверьте, что ИБП корректно завершит работу системы. Это позволяет записывать кеши файловой системы и сами диски.
И долговечность записи на диски. Читать Глава о надежности PostgreSQL. Использовать diskchecker.pl связанный там скрипт, чтобы провести краш-тест и определить, не лежат ли твердотельные накопители, если записи попали в энергонезависимое хранилище. Если есть потери, подумайте о замене твердотельными накопителями, которые, как известно, имеют защиту от потери питания.
Изменить: вы добавили сведения о том, что кеш записи был включен. Вы можете попытаться отключить это: hdparm -W0 /dev/sda или соответствующую команду для аппаратного массива. Ссылка: Руководство по администрированию хранилища RHEL.
Барьеры записи файловой системы обеспечивают соблюдение порядка фиксации журнала. Это не гарантия того, что данные будут неповрежденными, но это безопаснее для файловой системы с изменчивым кешем. Хотя это значение по умолчанию, добавление опции монтирования «барьер» явно свидетельствует о том, что вы цените согласованность, а не производительность.
Наконец, последняя линия защиты. Проведите тест восстановления, чтобы убедиться, что вы можете привести свое приложение и базу данных в нужный момент времени. Это полезно при любых потерях данных, а не только при сбое питания.