Chế độ nhật ký mặc định cho Ext4 là data=ordered, theo tài liệu, có nghĩa là

"Tất cả dữ liệu được buộc trực tiếp ra hệ thống tệp chính trước khi siêu dữ liệu của nó được cam kết với tạp chí."

Tuy nhiên, cũng có data=journaltùy chọn, có nghĩa là

"Tất cả dữ liệu được cam kết vào tạp chí trước khi được ghi vào hệ thống tệp chính. Kích hoạt chế độ này sẽ vô hiệu hóa phân bổ bị trì hoãn và hỗ trợ O_DIRECT."

Tôi hiểu điều này là data=journalchế độ sẽ ghi lại tất cả dữ liệu cũng như siêu dữ liệu, trên mặt của nó, có vẻ như đây là tùy chọn an toàn nhất về tính toàn vẹn và độ tin cậy của dữ liệu, mặc dù có thể không quá nhiều về hiệu suất.

Tôi có nên đi với tùy chọn này nếu độ tin cậy là mối quan tâm lớn nhất, nhưng hiệu suất ít hơn nhiều như vậy? Có bất kỳ cảnh báo để sử dụng tùy chọn này?

Đối với nền, hệ thống được đề cập là trên một UPS và ghi bộ nhớ đệm bị vô hiệu hóa trên các ổ đĩa.

Có, data=journallà cách an toàn nhất để ghi dữ liệu vào đĩa. Vì tất cả dữ liệu và siêu dữ liệu được ghi vào nhật ký trước khi ghi vào đĩa, bạn luôn có thể phát lại các công việc I / O bị gián đoạn trong trường hợp xảy ra sự cố. Nó cũng vô hiệu hóa tính năng phân bổ bị trì hoãn , có thể dẫn đến mất dữ liệu .

3 chế độ được trình bày theo thứ tự an toàn trong hướng dẫn :

1. dữ liệu = tạp chí
2. dữ liệu = đã ra lệnh
3. dữ liệu = viết lại

Ngoài ra còn có một tùy chọn khác có thể bạn quan tâm:

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

Sự cảnh báo duy nhất được biết là nó có thể trở nên chậm khủng khiếp. Bạn có thể giảm tác động hiệu suất bằng cách vô hiệu hóa cập nhật thời gian truy cập với noatimetùy chọn.

Chủ đề này là siêu cũ, nhưng vẫn có liên quan.

Chúng tôi muốn hợp nhất nhiều ghi nhỏ trên cơ sở dữ liệu MySQL, chạy dưới dạng VM dưới KVM bằng hình ảnh Ceph RBD.

Khách: CentOS 6 VM's / etc / fstab:

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

Thiết bị '/ dev / sda' (1 TiB) nằm trong nhóm NVMe được mã hóa nén, với một thiết bị nhật ký chuyên dụng tương đối nhỏ (128 MiB) trong nhóm NVMe được sao chép ba lần.

Dưới đây là các lệnh chúng tôi sử dụng trong môi trường cứu hộ:

Tháo tạp chí:

tune2fs -O ^has_journal /dev/sda1;

Kiểm tra hệ thống tập tin cho sự không nhất quán:

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

Lấy kích thước khối:

tune2fs -l /dev/sda1;

Định dạng thiết bị nhật ký chuyên dụng (CẢNH BÁO):

Kích thước nhật ký tối thiểu phải là kích thước khối 1024 * (chúng tôi sử dụng 128 MiB để an toàn)

Đặt kích thước khối để khớp với / dev / sda1

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

Đính kèm thiết bị nhật ký chuyên dụng vào hệ thống tệp:

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

Cài đặt 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