Режим журнала по умолчанию для Ext4 - это data=ordered, что, согласно документации, означает, что

«Все данные передаются напрямую в основную файловую систему до того, как ее метаданные будут переданы в журнал».

Тем не менее, есть также data=journalвариант, который означает, что

«Все данные сохраняются в журнале до их записи в основную файловую систему. Включение этого режима отключит отложенное размещение и поддержку O_DIRECT».

Насколько я понимаю, этот data=journalрежим будет регистрировать все данные, а также метаданные, что, на первый взгляд, означает, что это самый безопасный вариант с точки зрения целостности и надежности данных, хотя, возможно, и не столько для производительности.

Должен ли я пойти с этим вариантом, если надежность имеет первостепенное значение, но производительность гораздо меньше? Есть ли какие-либо предостережения относительно использования этой опции?

Для справки, рассматриваемая система находится на ИБП, и кэширование записи отключено на дисках.

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

3 режима представлены в порядке безопасности в руководстве :

1. Данные = журнал
2. Данные = заказаны
3. Данные = обратна запись

Есть еще один вариант, который может вас заинтересовать:

commit=nrsec    (*) Ext4 can be told to sync all its data and metadata
                    every 'nrsec' seconds. The default value is 5 seconds.

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

Эта тема очень старая, но все еще актуальна.

Мы хотели объединить множество мелких записей в базе данных MySQL, работая как виртуальная машина под KVM с использованием образов Ceph RBD.

Гость: CentOS 6 VM / etc / fstab:

/dev/sda1               /                       ext4    defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,noatime,nodiratime,commit=60,data=journal,discard 1 1

Устройство / dev / sda (1 ТиБ) находится в пуле NVMe со сжатым стиранием, с относительно небольшим (128 МБ) выделенным журнальным устройством в пуле с тройной репликацией NVMe.

При этом команды, которые мы использовали в спасательной среде:

Отделить журнал:

tune2fs -O ^has_journal /dev/sda1;

Проверьте файловую систему на несоответствия:

fsck.ext4 -f -C 0 /dev/sda1;

Получить размер блока:

tune2fs -l /dev/sda1;

Форматирование выделенного журнала устройства (ВНИМАНИЕ):

Минимальный размер журнала должен быть 1024 * размер блока (для безопасности мы используем 128 МБ)

Установите размер блока, соответствующий размеру / dev / sda1

mke2fs -O journal_dev -L root_journal /dev/sdb1 -b 4096;

Подключите выделенное устройство журнала к файловой системе:

tune2fs -j -J device=LABEL=root_journal /dev/sda1;

Настройки MySQL:

[mysqld]
innodb_old_blocks_time = 1000           # Prevent buffer pool pollution. Default as of MySQL 5.6
innodb_buffer_pool_size = 24576M        # MySQL Cache
innodb_log_buffer_size = 128M           # 25% of log_file_size
innodb_log_file_size = 512M             # 25% of the buffer_pool (no, not really)
query_cache_size = 128M                 # Query Cache
table_cache = 512                       # Make it large enough for: show global status like 'open%';
#mysqltuner.pl:
innodb_flush_method = O_DSYNC           # Don't validate writes. MySQL 5.6+ should use O_DIRECT
innodb_flush_log_at_trx_commit = 2      # Flush MySQL transactions to operating system cache
join_buffer_size = 256K
thread_cache_size = 4
innodb_buffer_pool_instances = 16
skip-innodb_doublewrite