Режим журналу за замовчуванням для Ext4 - це data=ordered, що відповідно до документації це означає

"Усі дані витісняються безпосередньо в основну файлову систему до того, як метадані будуть внесені до журналу."

Однак є і data=journalваріант, що означає, що це

"Усі дані заносяться в журнал до того, як вони будуть записані в основну файлову систему. Якщо ввімкнути цей режим, вимкніть затримку розподілу та підтримку O_DIRECT."

Я розумію це в тому, що data=journalрежим буде реєструвати всі дані, а також метадані, що, начебто, означає, що це найбезпечніший варіант з точки зору цілісності та надійності даних, хоча, можливо, не стільки для продуктивності.

Чи варто мені йти з цим варіантом, якщо надійність викликає найбільше значення, але продуктивність набагато менша? Чи є якісь застереження щодо використання цього варіанту?

Для фону система, про яку йде мова, працює на UPS, кешування записів на дисках вимкнено.

Так, 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, що працює як VM під 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 TiB) знаходиться у стисненому пульті 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