Следует ли использовать параметр монтирования nodatacow в btrfs на сервере базы данных? Отключает ли битовые контрольные суммы искажения?

Question

Я смотрю на реализацию btrfs в конфигурации raid 10 для сервера базы данных, и я не совсем понимаю вариант nodatacow.

Согласно https://btrfs.wiki.kernel.org/index.php/Gotchas:

Файлы с большим количеством случайных записей могут сильно фрагментироваться (более 10000 экстентов), вызывая перегрузку на жестких дисках и чрезмерные мультисекундные скачки загрузки процессора в системах с твердотельным накопителем или большим объемом оперативной памяти. На серверах и рабочих станциях это влияет на базы данных и образы виртуальных машин. Здесь может быть полезна опция монтирования nodatacow со связанными ошибками.

Затем в документации говорится, что опция nodatacow :

Не копируйте данные при записи для вновь созданных файлов, существующие файлы не затрагиваются. Это также отключает контрольную сумму! Итак, nodatacow подразумевает nodatasum. datacow используется, чтобы гарантировать, что пользователь имеет доступ либо к старой версии файла, либо к более новой версии файла. datacow гарантирует, что у нас никогда не будет частично обновленных файлов, записанных на диск. nodatacow обеспечивает небольшое повышение производительности за счет прямой перезаписи данных (например, ext [234]) за счет возможного получения частично обновленных файлов при сбоях системы. Увеличение производительности обычно составляет <5%, если рабочая нагрузка не является случайной записью в большие файлы базы данных, где разница может стать очень большой. ПРИМЕЧАНИЕ: отключает сжатие!

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

Answer 1

Означает ли это, что этот параметр следует выбирать для дисков на серверах баз данных?
Наверное. Количество изменений, вносимых базой данных в файловую систему, будет усилено процессами копирования при записи и контрольной суммы. [1] [2] Даже обычные операции с файловой системой могут заметно замедлить активную базу данных, поэтому многие высокопроизводительные СУБД поддерживают необработанные диски для хранения. [3] [4] [5]

Отключает ли использование этой опции контрольные суммы коррупции?
К сожалению, да, это так. [6]

[1] https://en.wikipedia.org/wiki/Copy-on-write#Copy-on-write_in_computer_storage
[2] https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
[3] https://lists.fedoraproject.org/pipermail/devel/2011-July/154251.html
[4] https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp
[5] https://www.google.com/search?q=btrfs+virtual+machine
[6] https://btrfs.wiki.kernel.org/index.php/FAQ#Can_data_checksumming_be_turned_off.3F

Answer 2

вам определенно следует использовать опцию nodatacow для каталогов баз данных. Если у вас есть база данных с большим количеством записей, она сначала замедлится, а затем уничтожит вашу файловую систему btrfs за несколько месяцев! у меня было это несколько раз; Файловая система btrfs становится доступной только для чтения и дает сбой из-за огромного количества фрагментов (и одна и другая ошибка, которая может быть исправлена сейчас, а может и нет).

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

вам не нужно отключать cow на всей файловой системе (в соответствии с опцией монтирования), достаточно отключить ее только в каталогах базы данных. Для этого остановите базу данных, создайте новый каталог, отключите COW для этого с помощью "chattr +C" и скопируйте (не двигайте!) все файлы базы данных прошли. проверьте разрешения файловой системы, затем переместите новый каталог db на место и запустите базу данных. установка chattr +C для каталога отключает COW для всех недавно созданных дочерних каталогов и файлов.