ลดอายุ log ก่อนย้าย Huawei

OmniCenter · ต้องลด log เท่าไร เครื่อง Huawei 650 GB ถึงจะพอ · สรุปให้ PM

อัปเดต 29 ก.ย. 2569 เฟส 1 ✓ · เฟส 2 ✓ Gate 6 — Log ยังไม่เริ่ม ลบเฉพาะ log คำขอ · log สต๊อกไม่แตะ ข้อมูลจริงจาก production (อ่านอย่างเดียว)

00 สรุปสำหรับ PM

617 GBข้อมูลที่ต้องย้ายไป Huawei ถ้าย้ายวันนี้
95%ของเครื่อง 650 GB ที่ตั้งเป้าไว้ — แน่นเกินไป
63%ของข้อมูลที่ต้องย้ายเป็น log
~144 GBที่ได้คืนถ้าลดอายุ log คำขอ (ทางเลือก 2)
ถ้าย้ายตอนนี้ เครื่อง Huawei 650 GB จะเต็ม 95% ตั้งแต่วันแรก
ลบออเดอร์เก่า (เฟส 2) เสร็จแล้ว ตอนนี้ของก้อนใหญ่ที่เหลือคือ log ซึ่งเป็นงาน Gate 6 ที่ยังไม่เริ่ม
ขอบเขต: ลบเฉพาะ log คำขอ — log สต๊อกสินค้าไม่แตะ คงไว้ 90 วันตามเดิม

ข้อเสนอ: ทางเลือก 2 — log คำขอที่ส่งไป marketplace ลดจาก 7 เหลือ 3 วัน · log คำขอที่ระบบอื่นเรียกเข้ามาลดจาก 14 เหลือ 7 วัน · log คำขอเล็กอื่น ๆ ลดจาก 7 เหลือ 3 วัน
ได้คืนประมาณ 144 GB → เหลือต้องย้าย ~473 GB (73% ของเครื่อง 650 GB) · ไม่ต้องแก้โค้ด ใช้เวลาประมาณ 1 สัปดาห์

ต่อจากรายงาน ความคืบหน้างานลบข้อมูล 24 ก.ย. ซึ่งปิดเฟส 1 และเฟส 2 ไปแล้ว

01 ตอนนี้พื้นที่ไปอยู่ไหน

ไฟล์ฐานข้อมูลวันนี้แบ่งเป็นอะไรบ้าง
ไฟล์ฐานข้อมูล 1,200 GB วันนี้ — ใช้พื้นที่ไปกับอะไรวัดจากระบบจริง 29 ก.ย. 2026 · รวมดัชนีค้นหาแล้วช่องว่างจากการลบลบข้อมูลไปแล้วแต่ไฟล์ยังไม่หด — ไม่ติดไปตอนย้าย583 GBlog คำขอ (รับ–ส่งกับ marketplace)เก็บ 7–14 วัน · ก้อนที่ใหญ่ที่สุดที่จะย้าย264 GBข้อมูลธุรกิจออเดอร์ · ผู้ซื้อ · ใบส่งของ · สินค้า ฯลฯ230 GBlog สต๊อกสินค้าประวัติจำนวนสินค้าเปลี่ยน · เก็บ 90 วัน121 GBlog อื่น ๆประวัติออเดอร์ / ใบส่งของ3 GBที่ต้องย้ายไป Huawei จริง = 264 + 230 + 121 + 3 = 617 GB (ช่องว่าง 583 GB ไม่ถูกส่งไป)log รวมกันคือ 388 GB หรือ 63% ของที่ต้องย้าย
ขนาดหมายเหตุ
ดิสก์ของเครื่อง Nipa ตอนนี้1,293 / 1,753 GBใช้ไป 74% · ว่าง 460 GB — ยังไม่เร่งด่วน
ไฟล์ฐานข้อมูล~1,200 GBรวมช่องว่างที่ลบแล้วแต่ยังไม่คืน
ช่องว่างจากการลบ~583 GBส่วนใหญ่มาจากลบออเดอร์เฟส 2 (271 GB) กับ log ที่หมดอายุ (193 GB)
ข้อมูลที่ต้องย้ายไป Huawei~617 GBข้อมูลจริง + ดัชนีค้นหา · ช่องว่างไม่ติดไป
ตัวเลขวันนี้สูงกว่ารายงาน 24 ก.ย. (~570 GB) ประมาณ 47 GB ส่วนใหญ่มาจาก log คำขอไป marketplace ที่โตขึ้นประมาณ 24 GB ใน 5 วัน — log เป็นส่วนเดียวที่ยังโตอยู่ ขณะที่ออเดอร์คงที่เพราะตัวลบรายชั่วโมงคุมอยู่

02 log แต่ละชุดโตวันละเท่าไร

log ทุกชุดมีวันหมดอายุอยู่แล้ว ระบบลบของเก่าให้อัตโนมัติ การลดจำนวนวันจึงลดขนาดได้ตรง ๆ ตามปริมาณต่อวัน

ปริมาณ log ต่อวัน
log แต่ละชุดโตวันละเท่าไร — ลด 1 วัน = ได้พื้นที่คืนเท่านี้นับจำนวนรายการย้อนหลังรายวัน — ปริมาณแต่ละวันใกล้เคียงกัน (ต่างกันไม่เกิน ±10%)log คำขอที่ส่งไป marketplaceเก็บ 7 วัน · ~7.5 ล้านรายการ/วัน~22 GB / วันlog คำขอที่ระบบอื่นเรียกเข้ามาเก็บ 14 วัน · ~2.5 ล้านรายการ/วัน~7.1 GB / วันlog สต๊อกสินค้าเก็บ 90 วัน · ~1.1 ล้านรายการ/วัน~1.2 GB / วันlog คำขอ + การส่งข้อมูลอื่น ๆเก็บ 7 วัน · ~3 ล้านรายการ/วัน~1.5 GB / วันlog คำขอที่ส่งไป marketplace ตัวเดียว ใช้พื้นที่วันละ 22 GB — ลดตัวนี้ได้ผลมากที่สุด
logใช้ทำอะไรเก็บตอนนี้ขนาดวันนี้
คำขอที่ส่งไป marketplaceดูว่าเราส่งอะไรไป Shopee/Lazada/TikTok แล้วได้อะไรกลับ · ใช้เป็นหลักฐานตอนร้านยื่นอุทธรณ์7 วัน154 GB
คำขอที่ระบบอื่นเรียกเข้ามาดูว่าหลังบ้าน/คลังขออะไรจาก Omni14 วัน100 GB
สต๊อกสินค้าไล่เคสสต๊อกไม่ตรงย้อนหลัง90 วัน111 GB
คำขอ + การส่งข้อมูลอื่น ๆlog ประกอบ7 วัน10 GB

03 ลดกี่วัน ได้คืนเท่าไร — เฉพาะ log คำขอ

ใช้ตารางนี้เลือกจำนวนวันของ log แต่ละชุดได้อิสระ แล้วเอาตัวเลขที่ได้คืนมาบวกกัน log สต๊อกสินค้าไม่อยู่ในตาราง เพราะไม่ลบ

log คำขอต่อวันตอนนี้ลดเหลือ → ได้คืน
ส่งไป marketplace~22 GB7 วัน6 วัน −22 · 5 วัน −44 · 4 วัน −66 · 3 วัน −88 GB · 2 วัน −110 ⚠️ · 1 วัน −132 ⚠️
ระบบอื่นเรียกเข้ามา~7.1 GB14 วัน10 วัน −28 · 7 วัน −50 GB · 5 วัน −64 · 3 วัน −78 · 1 วัน −93
คำขอ + การส่งข้อมูลอื่น ๆ~1.5 GB7 วัน5 วัน −3 · 3 วัน −6 GB · 1 วัน −9
⚠️ = ต่ำกว่า 3 วัน เสียหลักฐานยื่นอุทธรณ์กับ Shopee (ดู §04) · ตัวหนา = ค่าที่แนะนำ

1 — ค่อยเป็นค่อยไป

ลดครึ่งทาง ความเสี่ยงต่ำสุด −75 GBเหลือย้าย ~542 GB · 83% ของเครื่อง
  • ส่งไป marketplace 7 → 5 วัน
  • ระบบอื่นเรียกเข้ามา 14 → 10 วัน
  • อื่น ๆ 7 → 5 วัน

2 — แนะนำ

สมดุลระหว่างพื้นที่กับหลักฐาน −144 GBเหลือย้าย ~474 GB · 73% ของเครื่อง
  • ส่งไป marketplace 7 → 3 วัน
  • ระบบอื่นเรียกเข้ามา 14 → 7 วัน
  • อื่น ๆ 7 → 3 วัน

3 — ลดเต็มที่

ต่ำสุดที่ยังมีหลักฐาน Shopee ครบ −172 GBเหลือย้าย ~445 GB · 68% ของเครื่อง
  • ส่งไป marketplace 7 → 3 วัน
  • ระบบอื่นเรียกเข้ามา 14 → 3 วัน
  • อื่น ๆ 7 → 3 วัน
ขนาดที่ต้องย้ายไป Huawei ในแต่ละทางเลือก
ขนาดที่ต้องย้ายไป Huawei เทียบกับเครื่อง 650 GB — ลดเฉพาะ log คำขอlog สต๊อกสินค้าคงไว้ 90 วันทุกทางเลือก · ยิ่งแถบสั้น ยิ่งเหลือที่ว่างบนเครื่องใหม่มากไม่ทำอะไรเต็ม 95% ตั้งแต่วันแรก617 GB · 95%ทางเลือก 1 — ค่อยเป็นค่อยไปmarketplace 5 วัน · เรียกเข้า 10 วัน · อื่น ๆ 5 วัน~542 GB · 83%ทางเลือก 2 — แนะนำmarketplace 3 วัน · เรียกเข้า 7 วัน · อื่น ๆ 3 วัน~474 GB · 73%ทางเลือก 3 — ลดเต็มที่marketplace 3 วัน · เรียกเข้า 3 วัน · อื่น ๆ 3 วัน~445 GB · 68%เพดาน: ลบ log คำขอทิ้งทั้งหมดใช้เทียบเท่านั้น — ทำจริงไม่ได้~353 GB · 54%ต่อให้ลบ log คำขอทิ้งหมด ก็ยังเหลือย้าย ~353 GB เพราะข้อมูลธุรกิจ 230 GB + log สต๊อก 121 GB ไม่ถูกแตะ
log คำขอตอนนี้ทางเลือก 1ทางเลือก 2 (แนะนำ)ทางเลือก 3
ส่งไป marketplace7 วัน5 วัน (−44 GB)3 วัน (−88 GB)3 วัน (−88 GB)
ระบบอื่นเรียกเข้ามา14 วัน10 วัน (−28 GB)7 วัน (−50 GB)3 วัน (−78 GB)
คำขอ + การส่งข้อมูลอื่น ๆ7 วัน5 วัน (−3 GB)3 วัน (−6 GB)3 วัน (−6 GB)
สต๊อกสินค้า90 วันไม่แตะไม่แตะไม่แตะ
รวมที่ได้คืน~75 GB~144 GB~172 GB
เหลือย้ายไป Huawei617 GB~542 GB~474 GB~445 GB
ใช้เครื่อง 650 GB ไป95%83%73%68%

04 สิ่งที่ต้องแลก

1
log คำขอไป marketplace ห้ามต่ำกว่า 3 วัน
เป็นที่เดียวที่เก็บเลขอ้างอิงของ Shopee ไว้ใช้เป็นหลักฐานตอนร้านยื่นอุทธรณ์ (เคยเสียหาย 85,118 บาทในเคส CS-22935 เพราะหลักฐานหมดอายุ) · ฝั่ง Shopee เองก็ตรวจย้อนหลังได้แค่ ~3 วัน ถ้าเก็บ 3 วันเราจะยังมีหลักฐานครบในช่วงที่เปิดเรื่องกับ Shopee ได้
ทุกทางเลือกไม่ต่ำกว่า 3 วัน
2
log คำขอที่ระบบอื่นเรียกเข้ามา: ย้อนดูได้สั้นลง
ทางเลือก 2 เหลือ 7 วัน · ทางเลือก 3 เหลือ 3 วัน — กระทบทีม CS/DEV ที่ต้องไล่เคสเก่า ต้องเช็กกับ CS ว่าปกติย้อนดูไกลสุดกี่วันก่อนเลือก 3
3
log สต๊อกสินค้าไม่แตะ
ยังไล่เคสสต๊อกไม่ตรงย้อนหลังได้ 90 วันเท่าเดิม — แลกกับการที่ log สต๊อก 121 GB ต้องย้ายไปทั้งก้อน
4
ไม่กระทบลูกค้า ไม่กระทบออเดอร์
log คำขอใช้ตรวจสอบย้อนหลังเท่านั้น ไม่มีหน้าจอลูกค้าหรือขั้นตอนขายใดใช้ข้อมูลนี้

05 แผนดำเนินการ

1
ตัดสินใจทางเลือก (session Gate 6)
PM + DEV Chok + DevOps Suthon · CS ยืนยันว่าย้อนดู log ไกลสุดกี่วัน
PM
2
เตรียมก่อนลด
DevOps เช็กว่าบันทึกการเปลี่ยนแปลงของฐานข้อมูล (oplog) รองรับการลบก้อนใหญ่ได้ เพื่อให้เครื่องสำรองตามทัน
DevOps
3
ลดวันทีละ 1 วัน คืนละขั้น
เช่น marketplace 7 → 6 → 5 → 4 → 3 วัน แล้วค่อยลดชุดเรียกเข้า 14 → 7 วัน · ลด 1 วันจะลบ ~7.5 ล้านรายการ (~22 GB) ในรอบเดียว ถ้าตัดรวดเดียวจะลบ ~30 ล้านรายการพร้อมกัน เสี่ยงระบบช้า · ทำตอนกลางคืน ดูผลก่อนขั้นถัดไป
DevOps · ~1 สัปดาห์
4
แก้ค่าในโค้ดให้ตรงกับของจริง
โค้ดประกาศไว้ 30/90 วัน แต่ของจริงคือ 7/14 วัน — ถ้าไม่แก้ เครื่อง Huawei อาจถูกตั้งเป็น 30/90 วันตามโค้ด แล้ว log จะโตหลายเท่าทันทีหลังย้าย
DEV
5
วัดผลจริง แล้วสรุปขนาดเครื่อง Huawei
วัดขนาดหลังลดเสร็จ ใช้เป็นตัวเลขสุดท้ายสำหรับสั่งเครื่อง
DEV
คืนดิสก์ฝั่ง Nipa (ไม่บังคับ) — การลดอายุ log ทำให้ข้อมูลที่ต้องย้ายเล็กลง แต่ไฟล์บนเครื่อง Nipa จะยังไม่หด ต้องสั่งบีบไฟล์ (compact) แยกต่างหาก ตอนนี้ดิสก์ยังว่าง 460 GB จึงยังไม่จำเป็น และไม่มีผลต่อขนาดเครื่อง Huawei

06 ขอให้ PM ตัดสินใจ

#เรื่องข้อเสนอ
1เลือกทางเลือก 1 / 2 / 32 — ได้คืน 144 GB ไม่แตะ log สต๊อก และยังมีหลักฐาน Shopee ครบ
2ขนาดเครื่อง Huawei650 GB ใช้ได้ถ้าทำทางเลือก 2 (73%) · ถ้าอยากได้ headroom 2 เท่าตามค่าแนะนำ ต้องใช้ ~950 GB เพราะไม่ลบ log สต๊อก ลด log คำขออย่างเดียวไปไม่ถึง 50%
3นัด session Gate 6PM + DEV Chok + DevOps Suthon + ตัวแทน CS · 30 นาที
4แจ้ง CSlog คำขอย้อนหลังจะสั้นลง — เคสที่ต้องใช้หลักฐานจาก marketplace ต้องเปิดเรื่องภายใน 3 วัน

07 ข้อจำกัดของตัวเลข

เป็นค่าประมาณ ±5–10% — คำนวณจากขนาดเฉลี่ยต่อวัน × จำนวนวันที่ลด และวัดจากเครื่องสำรองเครื่องเดียว

ยังไม่รวมพื้นที่บันทึกการเปลี่ยนแปลง (oplog) บนเครื่อง Huawei — DevOps ต้องเผื่อเพิ่มเอง

ดัชนีค้นหาคิดตามขนาดวันนี้ — ปลายทางสร้างดัชนีใหม่ อาจเล็กกว่านี้เล็กน้อย

ยังไม่ได้ถาม CS ว่าปกติย้อนดู log ไกลสุดกี่วัน — ข้อนี้อาจทำให้ต้องเก็บ log คำขอเข้ามานานกว่า 7 วัน

— ภาคผนวก — สำหรับ DevOps

ชุดข้อมูลหมดอายุตอนนี้ข้อมูลจริง + ดัชนีต่อวันทางเลือก 2
app_platform_requests7d154.1 GB~22 GB3d
app_requests14d99.7 GB~7.1 GB7d
platform_requests7d5.6 GB~0.8 GB3d
app_pushes7d4.6 GB~0.66 GB3d
product_quantity_logs90d110.7 GB~1.23 GBไม่แตะ

เปลี่ยนวันหมดอายุด้วย collMod เท่านั้น — createIndexes() แก้ค่าของ index ที่มีอยู่แล้วไม่ได้ (error 85 ซึ่งมักถูกกลืนเงียบ)

db.getSiblingDB("omni_prod").runCommand({
  collMod: "app_platform_requests",
  index: { keyPattern: { created_date: 1 }, expireAfterSeconds: 6 * 86400 }
})

MongoDB 7.0.11 · replica set 10.10.193.126–128 · ดิสก์ 1,753 GB · ข้อมูลจริงคำนวณจาก storageSize − file bytes available for reuse + totalIndexSize