โหมดบันทึกประจำวันเริ่มต้นสำหรับ Ext4 คือdata=orderedซึ่งหมายถึงสิ่งนั้นตามเอกสารประกอบ

"ข้อมูลทั้งหมดจะถูกบังคับโดยตรงไปยังระบบไฟล์หลักก่อนที่เมตาดาต้าจะถูกส่งไปยังวารสาร"

อย่างไรก็ตามยังมีdata=journalตัวเลือกซึ่งหมายความว่า

"ข้อมูลทั้งหมดจะถูกบันทึกลงในสมุดรายวันก่อนที่จะถูกเขียนลงในระบบไฟล์หลักการเปิดใช้งานโหมดนี้จะปิดใช้งานการจัดสรรที่ล่าช้าและการสนับสนุน O_DIRECT"

ความเข้าใจของฉันเกี่ยวกับเรื่องนี้ก็คือdata=journalโหมดจะบันทึกข้อมูลทั้งหมดรวมทั้งข้อมูลเมตาที่ปรากฏว่าหมายความว่านี่เป็นตัวเลือกที่ปลอดภัยที่สุดในแง่ของความสมบูรณ์ของข้อมูลและความน่าเชื่อถือแม้ว่าอาจจะไม่ได้ประสิทธิภาพมากนัก

ฉันควรเลือกตัวเลือกนี้หรือไม่หากความน่าเชื่อถือเป็นสิ่งที่สำคัญที่สุด แต่ประสิทธิภาพก็ลดลงด้วย มีข้อควรระวังในการใช้ตัวเลือกนี้หรือไม่?

สำหรับพื้นหลังระบบที่มีปัญหานั้นอยู่ใน UPS และการเขียนแคชจะถูกปิดใช้งานในไดรฟ์

ใช่data=journalเป็นวิธีที่ปลอดภัยที่สุดในการเขียนข้อมูลลงดิสก์ เนื่องจากข้อมูลและข้อมูลเมตาทั้งหมดถูกเขียนลงในเจอร์นัลก่อนที่จะถูกเขียนลงดิสก์คุณสามารถเล่นซ้ำงาน I / O ที่ถูกขัดจังหวะในกรณีที่เกิดข้อขัดข้อง นอกจากนี้ยังปิดการใช้งานการจัดสรรล่าช้าคุณสมบัติซึ่งอาจนำไปสู่การสูญเสียข้อมูล

3 โหมดจะแสดงตามลำดับความปลอดภัยในคู่มือ :

1. ข้อมูล = วารสาร
2. ข้อมูล = สั่งซื้อ
3. ข้อมูล = writeback

นอกจากนี้ยังมีตัวเลือกอื่นที่คุณอาจสนใจ:

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's / 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 MiB) อุปกรณ์บันทึกเฉพาะในกลุ่ม NVMe ที่จำลองซ้ำ

พร้อมกับคำสั่งที่เราใช้ในสภาพแวดล้อมการช่วยเหลือ:

แยกวารสาร:

tune2fs -O ^has_journal /dev/sda1;

ตรวจสอบระบบไฟล์สำหรับความไม่สอดคล้องกัน:

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

รับขนาดบล็อก:

tune2fs -l /dev/sda1;

จัดรูปแบบอุปกรณ์บันทึกเฉพาะ (คำเตือน):

ขนาดวารสารขั้นต่ำควรเป็นขนาดบล็อก 1024 * (เราใช้ 128 MiB เพื่อความปลอดภัย)

ตั้งค่าขนาดบล็อกให้ตรงกับ / 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