ตั้งค่าความคงทนของข้อมูล Redis ด้วย RDB และ AOF

หลายคนใช้ Redis เป็นแคชโดยไม่สนใจว่าข้อมูลจะหายเมื่อรีสตาร์ต ซึ่งถูกต้องสำหรับงานแคช แต่เมื่อนำไปเก็บคิวงาน เซสชันผู้ใช้ หรือตัวนับที่ต้องแม่นยำ การที่ข้อมูลหายหมายถึงงานที่หายไปและผู้ใช้ที่ถูกเตะออกจากระบบทั้งหมดพร้อมกัน

คู่มือนี้อธิบายสองกลไกที่ Redis มีให้ พร้อมแนวทางเลือกใช้ตามลักษณะงาน และการตั้งค่าหน่วยความจำซึ่งสำคัญไม่แพ้กัน

สิ่งที่ต้องเตรียม

• Redis 6 ขึ้นไปบน Linux และสิทธิ์ sudo
• รู้ว่าข้อมูลที่เก็บยอมให้สูญหายได้แค่ไหน ซึ่งเป็นสิ่งที่ตัดสินทุกอย่างในคู่มือนี้

redis-cli INFO server | grep redis_version
redis-cli INFO persistence | head -20

ขั้นตอนที่ 1: เข้าใจสองกลไก

RDB คือการถ่ายภาพข้อมูลทั้งหมดเป็นระยะ

• ข้อดี ไฟล์เล็ก กู้คืนเร็วมาก ภาระต่อระบบต่ำ เหมาะกับการสำรองข้อมูล
• ข้อเสีย ข้อมูลระหว่างสองภาพจะหายเมื่อไฟดับ อาจเป็นหลายนาที

AOF คือการบันทึกทุกคำสั่งที่เปลี่ยนแปลงข้อมูล

• ข้อดี สูญหายน้อยมาก ตั้งได้ถึงระดับทุกวินาที
• ข้อเสีย ไฟล์ใหญ่กว่า กู้คืนช้ากว่า และมีภาระการเขียนมากกว่า

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

ขั้นตอนที่ 2: ตั้งค่า RDB

sudo nano /etc/redis/redis.conf

# บันทึกเมื่อ: ผ่านไป 900 วินาทีและมีการเปลี่ยนแปลงอย่างน้อย 1 ครั้ง
#              ผ่านไป 300 วินาทีและเปลี่ยนแปลง 10 ครั้ง
#              ผ่านไป 60 วินาทีและเปลี่ยนแปลง 10000 ครั้ง
save 900 1
save 300 10
save 60 10000

dbfilename dump.rdb
dir /var/lib/redis
rdbcompression yes
rdbchecksum yes

# หยุดรับการเขียนหากบันทึกลงดิสก์ไม่สำเร็จ ป้องกันข้อมูลหายเงียบ ๆ
stop-writes-on-bgsave-error yes

ปิด RDB ทั้งหมดได้ด้วยการลบบรรทัด save ทุกบรรทัดแล้วใส่ save "" ซึ่งเหมาะกับกรณีที่ใช้เป็นแคชล้วน ๆ

ขั้นตอนที่ 3: ตั้งค่า AOF

appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"

# ทางเลือกในการซิงก์ลงดิสก์
# always   = ปลอดภัยที่สุด ช้าที่สุด
# everysec = สมดุลที่สุด สูญหายไม่เกิน 1 วินาที  <- แนะนำ
# no       = เร็วที่สุด ปล่อยให้ระบบปฏิบัติการตัดสินใจ
appendfsync everysec

# บีบอัดไฟล์อัตโนมัติเมื่อโตขึ้นเท่าตัว
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# ไม่ซิงก์ระหว่างกำลังบีบอัด ลดอาการกระตุก
no-appendfsync-on-rewrite yes

sudo systemctl restart redis-server
redis-cli INFO persistence | grep -E 'aof_enabled|rdb_last_bgsave_status|aof_last_write_status'

ขั้นตอนที่ 4: จำกัดหน่วยความจำและเลือกนโยบายลบ

ข้อนี้สำคัญพอ ๆ กับความคงทน หากไม่จำกัด Redis จะใช้หน่วยความจำจนเครื่องหมดและถูกระบบฆ่าทิ้ง ซึ่งทำให้ข้อมูลในหน่วยความจำหายทันที

# ตั้งประมาณ 60-70% ของ RAM ทั้งเครื่อง เผื่อไว้ให้การบีบอัด AOF
maxmemory 4gb
maxmemory-policy allkeys-lru

นโยบายที่เลือกได้และควรใช้เมื่อไร

• noeviction ไม่ลบอะไรเลย คืนค่าผิดพลาดเมื่อเต็ม ใช้เมื่อข้อมูลทุกตัวสำคัญ เช่น คิวงาน
• allkeys-lru ลบตัวที่ไม่ได้ใช้นานที่สุด เหมาะกับแคชทั่วไป
• volatile-lru ลบเฉพาะคีย์ที่ตั้งเวลาหมดอายุไว้ เหมาะเมื่อเก็บทั้งข้อมูลถาวรและแคชปนกัน
• allkeys-lfu ลบตัวที่ใช้น้อยที่สุด เหมาะเมื่อมีข้อมูลยอดนิยมชัดเจน

ตรวจการใช้หน่วยความจำจริง

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
redis-cli --bigkeys

คำสั่ง --bigkeys หาคีย์ที่ใหญ่ผิดปกติ ซึ่งมักเป็นสาเหตุที่หน่วยความจำเต็มเร็วกว่าที่คำนวณไว้

ขั้นตอนที่ 5: สำรองข้อมูลออกนอกเครื่อง

sudo nano /usr/local/bin/redis-backup.sh

#!/bin/bash
set -euo pipefail

DEST=/var/backups/redis
STAMP=$(date +%F-%H%M)
mkdir -p "$DEST"

# สั่งบันทึกภาพใหม่แบบไม่บล็อก
redis-cli BGSAVE

# รอจนบันทึกเสร็จ
while [ "$(redis-cli INFO persistence | grep -c 'rdb_bgsave_in_progress:1')" -eq 1 ]; do
  sleep 1
done

cp /var/lib/redis/dump.rdb "$DEST/dump-$STAMP.rdb"
gzip "$DEST/dump-$STAMP.rdb"
find "$DEST" -name 'dump-*.rdb.gz' -mtime +14 -delete

echo "redis backup ok: $DEST/dump-$STAMP.rdb.gz"

sudo chmod +x /usr/local/bin/redis-backup.sh
sudo /usr/local/bin/redis-backup.sh

ใช้ BGSAVE เสมอ ไม่ใช่ SAVE เพราะ SAVE บล็อกการทำงานทั้งหมดจนกว่าจะเขียนเสร็จ

ขั้นตอนที่ 6: กู้คืนข้อมูล

sudo systemctl stop redis-server

# กู้จาก RDB
sudo cp /var/backups/redis/dump-2026-09-25-0200.rdb /var/lib/redis/dump.rdb
sudo chown redis:redis /var/lib/redis/dump.rdb

sudo systemctl start redis-server
redis-cli DBSIZE

สำคัญ หากเปิด AOF อยู่ Redis จะอ่านจาก AOF ไม่ใช่ RDB ตอนเริ่มทำงาน หากต้องการกู้จาก RDB ต้องปิด AOF ชั่วคราวก่อน แล้วเปิดกลับด้วยคำสั่งที่ทำให้สร้าง AOF ใหม่จากข้อมูลในหน่วยความจำ

redis-cli CONFIG SET appendonly no
sudo systemctl restart redis-server   # โหลดจาก RDB
redis-cli CONFIG SET appendonly yes   # สร้าง AOF ใหม่จากข้อมูลปัจจุบัน
redis-cli CONFIG REWRITE

ขั้นตอนที่ 7: ตรวจสุขภาพและซ่อมไฟล์

# ตรวจไฟล์ RDB
redis-check-rdb /var/lib/redis/dump.rdb

# ตรวจและซ่อม AOF
redis-check-aof --fix /var/lib/redis/appendonlydir/appendonly.aof.1.incr.aof

# ดูสถิติสำคัญ
redis-cli INFO persistence | grep -E 'rdb_last_save_time|rdb_changes_since_last_save|aof_rewrite_in_progress'
redis-cli LASTSAVE

ปัญหาที่พบบ่อย

ขึ้นข้อผิดพลาด MISCONF Redis is configured to save RDB snapshots

Redis บันทึกลงดิสก์ไม่สำเร็จจึงหยุดรับการเขียน สาเหตุที่พบบ่อยที่สุดคือดิสก์เต็มหรือสิทธิ์ของโฟลเดอร์ผิด ตรวจด้วย df -h และ ls -ld /var/lib/redis แล้วดู Log ที่ /var/log/redis/redis-server.log

ข้อมูลหายหลังรีสตาร์ต

ตรวจว่าเปิด persistence จริงด้วย redis-cli CONFIG GET appendonly และ redis-cli CONFIG GET save หากตั้งค่าผ่านคำสั่งไว้ชั่วคราว ต้องสั่ง CONFIG REWRITE เพื่อบันทึกลงไฟล์

เครื่องกระตุกเป็นช่วงตอนบันทึกข้อมูล

การ BGSAVE ทำสำเนาหน่วยความจำของกระบวนการ ทำให้ใช้หน่วยความจำเพิ่มขึ้นชั่วคราว ตั้ง maxmemory ไม่เกิน 60% ของ RAM และตั้ง vm.overcommit_memory = 1 ในระบบ

ไฟล์ AOF ใหญ่มาก

สั่งบีบอัดด้วยมือด้วย redis-cli BGREWRITEAOF และตรวจว่า auto-aof-rewrite-percentage ตั้งไว้แล้ว

ต้องการวางระบบแคชและคิวงานที่เชื่อถือได้ ติดต่อ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/