วิธีแก้ไขข้อผิดพลาด “Lock Mechanism Timeout” ในการล็อกไฟล์ ownCloud

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

เอกสารประกอบการใช้งาน ownCloud 11 ฉบับปัจจุบันยังคงแนะนำให้ใช้ Redis สำหรับการล็อกไฟล์แบบธุรกรรม เนื่องจากกลไกการล็อกที่ใช้ฐานข้อมูลจะสร้างภาระให้กับฐานข้อมูลอย่างมาก ในการติดตั้งแบบคลัสเตอร์ โหนดแอปพลิเคชันทุกโหนดจะต้องใช้ Redis อินสแตนซ์เดียวกันสำหรับการล็อก นี่คือวิธีแก้ไขที่ยั่งยืนที่ควรทำความเข้าใจก่อนที่จะเปลี่ยนแปลงค่าหมดเวลาหรือลบระเบียนการล็อก

คู่มือนี้จะอธิบายปัญหาจากมุมมองของผู้ดูแลระบบมือใหม่: ความหมายของการล็อก สิ่งที่ต้องสำรองข้อมูล วิธีตรวจสอบส่วนประกอบที่ล้มเหลว วิธีการกำหนดค่า Redis คลัสเตอร์เปลี่ยนแปลงสถานการณ์อย่างไร และทางลัดใดที่อาจทำให้สถานการณ์แย่ลง

ข้อผิดพลาดนั้นหมายความว่าอย่างไร

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

ตามเอกสารเกี่ยวกับการล็อกไฟล์แบบทำธุรกรรมของ ownCloud 11กลไกนี้ยังจัดการกับการอัปโหลดที่ถูกขัดจังหวะ ไฟล์ที่แชร์ พื้นที่จัดเก็บภายนอก และไฟล์ที่เข้ารหัสได้อีกด้วย

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

ก่อนที่คุณจะเริ่มต้น

• สำรองข้อมูลฐานข้อมูล ownCloud และconfig/config.php.
• โปรดระบุเวอร์ชัน ownCloud และประเภทการติดตั้งใช้งาน: แพ็กเกจแบบดั้งเดิม, Docker Compose หรือคลัสเตอร์แบบหลายโหนด
• ระบุระบบฐานข้อมูลของคุณและตรวจสอบว่าได้ติดตั้ง Redis แล้วหรือไม่
• บันทึกการทำงานที่ล้มเหลวอย่างละเอียด เช่น การซิงค์เดสก์ท็อป การอัปโหลดผ่าน WebDAV การเปลี่ยนชื่อโฟลเดอร์ หรือการอัปโหลดแบบแบ่งส่วน
• โปรดสังเกตว่าปัญหาดังกล่าวส่งผลกระทบต่อไฟล์เดียว ผู้ใช้คนเดียว หรือผู้ใช้หลายคนพร้อมกัน

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

ขั้นตอนที่ 1: ตรวจสอบว่ากลไกการล็อกใดทำงานผิดปกติ

เริ่มต้นด้วยการตรวจสอบบันทึกของ ownCloud, บันทึกของเว็บเซิร์ฟเวอร์, บันทึกของ PHP-FPM และสถานะบริการของ Redis คุณกำลังมองหาข้อผิดพลาดเกี่ยวกับการล็อกทรัพยากรซ้ำๆ ข้อผิดพลาดในการรอการล็อกฐานข้อมูล ความล้มเหลวในการเชื่อมต่อ Redis หรือรูปแบบที่เส้นทางเดียวกันยังคงถูกบล็อกเป็นเวลานานหลังจากที่การดำเนินการเดิมสิ้นสุดลง

การตรวจสอบที่มีประโยชน์บนระบบ Linux ได้แก่:

systemctl status redis-server
redis-cli PING
ps -ef | grep php
tail -n 200 /path/to/owncloud/data/owncloud.log

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

หากในบันทึกการทำงานมีข้อความจากฐานข้อมูลที่คล้ายกับ “lock wait timeout exceeded” ให้ตรวจสอบปัญหาการแย่งใช้ฐานข้อมูลด้วยเช่นกัน ระบบล็อกฐานข้อมูลแบบเก่าใช้งานได้ แต่เอกสารของ ownCloud เตือนไว้อย่างชัดเจนว่ามันทำให้ฐานข้อมูลทำงานหนักมาก

ขั้นตอนที่ 2: ย้ายการล็อกไฟล์ธุรกรรมไปยัง Redis

สำหรับการติดตั้ง ownCloud แบบดั้งเดิม ให้กำหนดค่า Redis เป็นmemcache.lockingแบ็กเอนด์ในไฟล์config/config.php.app.json เอกสารเกี่ยวกับการแคชหน่วยความจำของ ownCloud ในปัจจุบันมีตัวอย่างการใช้งาน Redis TCP ที่คล้ายกับตัวอย่างนี้:

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0,
    'password' => '',
],

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

ในการตั้งค่า Docker อย่างเป็นทางการของ ownCloud นั้น Redis ถูกเปิดใช้งานด้วยตัวแปรสภาพแวดล้อม เอกสารประกอบ ownCloud 11 ฉบับปัจจุบันแสดงข้อมูลดังนี้:

OWNCLOUD_REDIS_ENABLED=true
OWNCLOUD_REDIS_HOST=redis
OWNCLOUD_REDIS_PORT=6379

เมื่อเปิดใช้งาน Redis ในรูปแบบการปรับใช้ดังกล่าว ownCloud จะตั้งค่าแคชแบบกระจายและแคชแบบล็อกเป็น Redis โดยอัตโนมัติ ควรใช้การกำหนดค่าเฉพาะสำหรับการปรับใช้ที่ระบุไว้ในเอกสารสำหรับการติดตั้งของคุณ แทนที่จะผสมผสานตัวแปรสภาพแวดล้อมของ Docker กับการจัดการด้วยตนเองconfig.phpเว้นแต่คุณจะเข้าใจว่าเลเยอร์ใดมีผลเหนือกว่า

ขั้นตอนที่ 3: ในระบบคลัสเตอร์ ให้ทุกโหนดใช้ Redis เดียวกัน

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

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

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

ขั้นตอนที่ 4: ตรวจสอบการตั้งค่าและลองดำเนินการตามขั้นตอนเดิมอีกครั้ง

หลังจากตั้งค่า Redis เสร็จแล้ว ให้ตรวจสอบการตั้งค่า ownCloud ที่ใช้งานอยู่ด้วยคำสั่ง `difficulty` occทั้งนี้ ขึ้นอยู่กับการติดตั้งของคุณ คำสั่งนี้อาจถูกเรียกใช้โดยผู้ใช้เว็บเซิร์ฟเวอร์หรือผ่าน Docker Compose

sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get filelocking.enabled

คำสั่งแรกควรรายงานผล\OC\Memcache\Redisและการล็อกไฟล์แบบธุรกรรมควรเปิดใช้งานอยู่ อย่า "แก้ปัญหา" ด้วยการปิดใช้งานการล็อกไฟล์ เพราะนั่นเป็นการลบมาตรการป้องกันความสมบูรณ์ของข้อมูลแทนที่จะแก้ไขปัญหาที่ส่วนหลังบ้าน

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

ถ้าไฟล์ยังคงแสดงว่าถูกล็อกอยู่ล่ะ?

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

การล็อกธุรกรรมถูกออกแบบมาให้ปลดล็อกหลังจากธุรกรรมถูกขัดจังหวะ เอกสารอ้างอิงการกำหนดค่า ownCloud รุ่นเก่าๆ ยังได้บันทึกกลไกเวลาหมดอายุของการล็อก (Time-to-Live หรือ TTL) ไว้ด้วย เพื่อให้สามารถล้างการล็อกเก่าๆ ได้โดยอัตโนมัติ เนื่องจากรายละเอียดการกำหนดค่าที่แน่นอนอาจแตกต่างกันไปในแต่ละเวอร์ชันของ ownCloud โปรดตรวจสอบตัวเลือกในเอกสารที่ตรงกับเวอร์ชันที่คุณติดตั้งก่อนทำการเปลี่ยนแปลง อย่าตั้งค่า TTL ให้สั้นมากเกินไปเพียงเพื่อปกปิดปัญหาการจัดเก็บข้อมูลหรือฐานข้อมูลที่ช้า

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

อย่าสับสนระหว่างการล็อกธุรกรรมกับการล็อกไฟล์ด้วยตนเอง

เอกสารประกอบการใช้งาน ownCloud 11 ฉบับปัจจุบันระบุว่า การล็อกไฟล์ด้วยตนเองถูกปิดใช้งานโดยค่าเริ่มต้นในเว็บอินเทอร์เฟซ เมื่อเปิดใช้งาน การล็อกไฟล์ในเว็บอินเทอร์เฟซจะตั้งค่าเริ่มต้นเป็น 30 นาที และค่าสูงสุดเริ่มต้นคือ 24 ชั่วโมง ค่าเหล่านี้มีรายละเอียดอยู่ใน คู่มือการล็อกไฟล์ ด้วยตนเอง

หากปัญหาของคุณเกี่ยวข้องกับการล็อกด้วยตนเองที่ผู้ใช้สร้างขึ้น คำสั่งต่างๆ เช่นนี้จึงมีความเกี่ยวข้อง:

docker compose exec owncloud occ config:app:set files lock_timeout_default --value 1800
docker compose exec owncloud occ config:app:set files lock_timeout_max --value 86400

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

ข้อผิดพลาดทั่วไปที่ทำให้ปัญหาการหมดเวลาการล็อกแย่ลง

การลบแถวที่ถูกล็อกออกจากฐานข้อมูลในขณะที่ ownCloud กำลังทำงานอยู่

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

ปิดใช้งานการล็อกไฟล์ธุรกรรม

การล็อกธุรกรรมมีไว้เพื่อป้องกันการแก้ไขไฟล์พร้อมกัน เปิดใช้งานการล็อกนี้ไว้ และทำการซ่อมแซมระบบแบ็กเอนด์

การใช้ APCu สำหรับการล็อกแบบใช้ร่วมกันในคลัสเตอร์

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

เรียกใช้งาน Redis หนึ่งอินสแตนซ์ต่อโหนดแอปพลิเคชัน

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

เพิ่มระยะเวลารอการล็อกฐานข้อมูลโดยไม่แก้ไขปัญหาการแย่งชิงทรัพยากร

การตั้งค่าหมดเวลาของฐานข้อมูลให้นานขึ้นอาจทำให้ผู้ใช้ต้องรอนานขึ้นเท่านั้น การย้ายการรับส่งข้อมูลการล็อกธุรกรรมไปยัง Redis จะช่วยลดภาระงานการล็อกของฐานข้อมูลและแก้ไขปัญหาคอขวดทางสถาปัตยกรรมได้

การกำหนดระยะเวลาหมดอายุของล็อกให้สั้นเกินจริง

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

รายการตรวจสอบการแก้ไขปัญหาอย่างรวดเร็ว

• ตรวจสอบให้แน่ใจว่าข้อผิดพลาดนั้นเกี่ยวข้องกับการล็อกธุรกรรม ไม่ใช่การล็อกด้วยตนเองที่ผู้ใช้สร้างขึ้น
• ตรวจสอบบันทึกของ ownCloud, PHP, ฐานข้อมูล และ Redis ในช่วงเวลาเดียวกัน
• ตรวจสอบให้แน่ใจว่าสามารถเข้าถึง Redis ได้จากรันไทม์ของ ownCloud ไม่ใช่แค่จากเชลล์ของคุณเท่านั้น
• ตั้งค่าmemcache.lockingเป็น\OC\Memcache\Redis.
• filelocking.enabledเปิดใช้งานไว้เสมอ
• ในระบบคลัสเตอร์ ให้กำหนดให้ทุกโหนดเชื่อมต่อกับอินสแตนซ์ Redis เดียวกัน
• ลองทำการซิงค์ อัปโหลด หรือย้ายไฟล์อีกครั้งตามขั้นตอนเดิม พร้อมทั้งตรวจสอบบันทึกการทำงานไปด้วย
• ควรใช้การสแกนเพื่อซ่อมแซมหรือการเปลี่ยนแปลงการหมดอายุของล็อกเฉพาะเมื่อมีหลักฐานบ่งชี้ว่าข้อมูลเมตาเสียหายหรือล็อกหมดอายุแล้วเท่านั้น

สรุปแล้ว

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

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