แก้ไขข้อผิดพลาดในการย้ายฐานข้อมูล Kopano หลังจากการอัปเกรดเวอร์ชัน MySQL

ข้อผิดพลาดในการย้ายฐานข้อมูล Kopano ที่เกิดขึ้นทันทีหลังจากการอัปเกรดเวอร์ชัน MySQL หรือ MariaDB มักหมายความว่าแอปพลิเคชันและฐานข้อมูลไม่สอดคล้องกันในเรื่องบางอย่างที่เคยเป็นไปอย่างราบรื่น เช่น สถานะของสคีมา ค่าเริ่มต้นของเซิร์ฟเวอร์ พฤติกรรม SQL การตรวจสอบสิทธิ์ หรือเส้นทางการอัปเกรดเอง เป้าหมายที่สำคัญไม่ใช่แค่การkopano-serverเริ่มต้นใช้งานได้เพียงครั้งเดียว แต่เป้าหมายคือการไปถึงสถานะที่สคีมามีความสอดคล้องกัน Kopano เริ่มทำงานได้โดยไม่มีข้อผิดพลาดในการอัปเกรดฐานข้อมูล ผู้ใช้สามารถเปิดร้านค้าได้ และการรับส่งอีเมลยังคงใช้งานได้หลังจากการรีสตาร์ท

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

เริ่มต้นด้วยผลลัพธ์ที่คุณต้องการ

ก่อนที่จะเปลี่ยนแปลงการตั้งค่า ให้กำหนดความหมายของคำว่า “คงที่” ก่อน การกู้คืนระบบที่ดีมักจะมีสัญญาณเหล่านี้ครบถ้วน:

• kopano-serverจะเริ่มทำงานและทำงานต่อไปได้หลังจากรีสตาร์ทบริการ
• บันทึกของ Kopano จะไม่รายงานการอัปเกรดโครงสร้างฐานข้อมูลหรือความล้มเหลวในการเรียกใช้คำสั่ง SQL อีกต่อไป
• ฐานข้อมูลสามารถอ่านและเขียนได้โดยบัญชี Kopano ที่กำหนดค่าไว้
• ร้านค้าและผู้ใช้ที่มีอยู่เดิมจะปรากฏให้เห็น แทนที่จะเป็นโครงสร้างข้อมูลว่างเปล่าที่สร้างขึ้นใหม่
• การส่งและรับจดหมายกลับสู่สภาวะปกติแล้ว
• การรีสตาร์ทครั้งที่สองให้ผลลัพธ์ที่ดีเช่นเดียวกัน

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

1. หยุดการทำงานของโปรแกรม Kopano และทำการสำรองข้อมูลฐานข้อมูลที่สามารถกู้คืนได้

เอกสารการอัปเกรดของ Kopano แนะนำให้สำรองข้อมูลฐานข้อมูลและไฟล์การกำหนดค่า และหยุดบริการที่ใช้ฐานข้อมูลก่อนเริ่มการอัปเกรด เอกสารระบุอย่างชัดเจนถึงการหยุดบริการต่างๆkopano-spoolerรวมkopano-serverถึงส่วนประกอบเสริมที่กำลังทำงานอยู่ ดูเอกสารการอัปเกรด Kopano Coreเพิ่มเติม

sudo systemctl stop kopano-spooler
sudo systemctl stop kopano-server

mysqldump -u root -p --single-transaction kopano > /root/kopano-before-fix.sql
ls -lh /root/kopano-before-fix.sql

สำหรับการติดตั้งขนาดใหญ่ ควรเก็บรักษาข้อมูลไว้ด้วย/etc/kopano/จดบันทึกตำแหน่งที่จัดเก็บไฟล์แนบ และปฏิบัติตามนโยบายการสำรองข้อมูลฐานข้อมูลที่มีอยู่ หากไฟล์แนบถูกจัดเก็บไว้นอก MySQL การดัมพ์ SQL เพียงอย่างเดียวจะไม่ถือเป็นการสำรองข้อมูล Kopano อย่างสมบูรณ์

หยุดบริการ Kopano ที่เขียนข้อมูลลงฐานข้อมูล และตรวจสอบให้แน่ใจว่ามีข้อมูลสำรองล่าสุดอยู่ก่อนที่จะเปลี่ยนแปลงโครงสร้างฐานข้อมูลหรือการตั้งค่าเซิร์ฟเวอร์

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

2. บันทึกเวอร์ชันฐานข้อมูลที่แน่นอนและค่าเริ่มต้นที่เปลี่ยนแปลงไป

การอัปเกรด MySQL ครั้งใหญ่สามารถเปลี่ยนแปลงค่าเริ่มต้นของเซิร์ฟเวอร์ได้โดยไม่ต้องแก้ไขตารางที่มีอยู่ ตัวอย่างเช่น MySQL 8.0 ได้เปลี่ยนชุดอักขระเริ่มต้นของเซิร์ฟเวอร์เป็นutf8mb4และการเรียงลำดับเริ่มต้นเป็นutf8mb4_0900_ai_ciนอกจากนี้ยังเปลี่ยนแปลงค่าเริ่มต้นอื่นๆ และลบหรือยกเลิกพฤติกรรมเก่าๆ Oracle ได้บันทึกความแตกต่างเหล่านี้ไว้ในเอกสาร " การเปลี่ยนแปลงใน MySQL 8.0 "

ตรวจสอบสถานะเซิร์ฟเวอร์จริงแทนที่จะคาดเดาว่าการอัปเกรดแพ็กเกจทำอะไรไปบ้าง:

mysql -u root -p

SELECT VERSION();
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

บันทึกเวอร์ชันฐานข้อมูลและค่าเริ่มต้นที่ Kopano ตรวจพบในปัจจุบัน ค่าเหล่านี้จะช่วยอธิบายความล้มเหลวที่เกิดขึ้นหลังจากอัปเกรดฐานข้อมูลเท่านั้น

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

3. อ่านข้อผิดพลาด SQL แรกอย่างละเอียด ไม่ใช่แค่ความล้มเหลวในการให้บริการครั้งสุดท้ายเท่านั้น

โดยปกติแล้ว Systemd จะแสดงเพียงว่าkopano-serverได้ออกจากระบบแล้ว บรรทัดที่มีประโยชน์มักจะอยู่ก่อนหน้านั้นในบันทึกเหตุการณ์หรือบันทึก Kopano เริ่มจาก:

journalctl -u kopano-server -n 100 --no-pager

จากนั้นให้จำแนกประเภทของความล้มเหลว ตารางต่อไปนี้เป็นแผนผังการคัดแยกปัญหาเชิงปฏิบัติมากกว่าการกล่าวอ้างว่าสาเหตุเดียวใช้ได้กับทุกการติดตั้ง

บันทึกการเปลี่ยนแปลงของ Kopano ยืนยันว่าการออกเวอร์ชันใหม่บางเวอร์ชันมีการเปลี่ยนแปลงโครงสร้างฐานข้อมูลที่ต้องkopano-dbadmดำเนินการเฉพาะ นอกจากนี้ยังบันทึกข้อบกพร่องในการอัปเกรดฐานข้อมูลในอดีต รวมถึงความล้มเหลวที่เกี่ยวข้องกับคำจำกัดความตาราง MySQL เก่าและการอัปเกรด utf8mb4 ใช้บันทึกการเปลี่ยนแปลงของ Kopano Coreเพื่อจับคู่การดำเนินการบำรุงรักษากับเวอร์ชัน Kopano ของคุณอย่างแม่นยำ

4. เปรียบเทียบสคีมา Kopano ที่มีอยู่กับค่าเริ่มต้นของเซิร์ฟเวอร์ใหม่

ตรวจสอบโครงสร้างข้อมูล (schema) ตามที่เป็นอยู่จริง ค่าเริ่มต้นของเซิร์ฟเวอร์เพียงอย่างเดียวไม่ได้บอกคุณว่าตาราง Kopano ถูกสร้างขึ้นเมื่อใด

SHOW CREATE DATABASE kopano;
SHOW TABLE STATUS FROM kopano;

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

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

Kopano เองได้เพิ่มการรองรับ utf8mb4 ในเวอร์ชัน Core รุ่นหลังๆ และได้บันทึกขั้นตอนการบำรุงรักษาฐานข้อมูลเฉพาะkopano-dbadm usmpสำหรับการอัปเกรดฐานข้อมูลที่มีอยู่ให้รองรับ Unicode 4 ไบต์ อย่าเรียกใช้คำสั่งนั้นเพียงเพราะ MySQL ตั้งค่าเริ่มต้นเป็น utf8mb4 แล้ว ให้เรียกใช้เฉพาะเมื่อเอกสารประกอบการใช้งาน Kopano เวอร์ชันที่ติดตั้งหรือเอาต์พุตจากเซิร์ฟเวอร์ของคุณระบุเท่านั้น

5. หากมีการอัปเกรด MariaDB โปรดดำเนินการอัปเกรดฝั่ง MariaDB ให้เสร็จสิ้นก่อน

หากฐานข้อมูลของคุณคือ MariaDB แทนที่จะเป็น Oracle MySQL ให้ดำเนินการอัปเกรดเซิร์ฟเวอร์ฐานข้อมูลให้เสร็จสิ้นก่อนที่จะโทษ Kopano เอกสารmariadb-upgradeของ MariaDB ระบุว่าเป็นเครื่องมือที่อัปเดตตารางระบบและตรวจสอบตารางหลังจากมีการเปลี่ยนแปลงเวอร์ชันหลัก เอกสารแนะนำให้สำรองข้อมูลฐานข้อมูลทั้งหมดก่อน ดู ข้อมูลอ้างอิงอย่างเป็นทางการของ mariadb -upgrade

นี่เป็นเพียงส่วนหนึ่งของคำสั่ง ไม่ใช่คำสั่งสากล ห้ามใช้mariadb-upgradeกับ Oracle MySQL ในทางกลับกัน อย่าใช้สมมติฐานของ MySQL 8.0 กับเซิร์ฟเวอร์ MariaDB เพียงเพราะทั้งสองยอมรับmysqlโปรโตคอลไคลเอ็นต์เหมือน กัน

6. ตรวจสอบว่าบัญชีฐานข้อมูล Kopano ยังคงมีสิทธิ์ที่จำเป็นอยู่หรือไม่

คู่มือผู้ดูแลระบบของ Kopano ระบุว่าเซิร์ฟเวอร์ต้องการสิทธิ์ต่างๆ รวมถึงALTER, CREATE, CREATE ROUTINE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, และUPDATEบนฐานข้อมูล Kopano พารามิเตอร์การเชื่อมต่อฐานข้อมูลจะถูกกำหนดค่าผ่านการตั้งค่าที่เกี่ยวข้องกับ MySQL ใน/etc/kopano/server.cfgดู การกำหนด ค่าส่วนประกอบ KC

หลังจากทำการย้ายเวอร์ชัน MySQL แล้ว ผู้ดูแลระบบอาจสร้างผู้ใช้ใหม่ เปลี่ยนปลั๊กอินการตรวจสอบสิทธิ์ ย้ายโฮสต์ฐานข้อมูล หรือกู้คืนสิทธิ์การเข้าถึงไม่สมบูรณ์ ทดสอบโดยใช้ชื่อโฮสต์และบัญชีเดียวกันกับที่ Kopano ใช้ หากการตรวจสอบสิทธิ์ล้มเหลวก่อนที่คำสั่ง SQL สำหรับการย้ายเวอร์ชันจะทำงาน ให้แก้ไขปัญหาบัญชีหรือสิทธิ์การเข้าถึงก่อน

7. ซ่อมแซมเฉพาะส่วนที่พบข้อผิดพลาดเท่านั้น

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

• การอัปเดตสคีมา Kopano บางส่วน:โปรดปฏิบัติตามคำแนะนำในการอัปเกรด Kopano เฉพาะรุ่นหรือkopano-dbadmคำแนะนำที่ระบุโดยเวอร์ชันที่ติดตั้งไว้ ห้ามลบเครื่องหมายเวอร์ชันหรือเพิ่มคอลัมน์ด้วยตนเองเพียงเพื่อให้คำสั่งถัดไปทำงานได้
• ความไม่ตรงกันของชุดอักขระหรือการเรียงลำดับ:ระบุตารางและคอลัมน์ที่ได้รับผลกระทบก่อน วางแผนการแปลงข้อมูลกับสำเนาที่กู้คืนแล้วก่อนที่จะแตะต้องข้อมูลที่ใช้งานจริง เนื่องจากชุดอักขระที่เปลี่ยนแปลงอาจส่งผลต่อขนาดดัชนีและพฤติกรรมการเปรียบเทียบ
• ตารางระบบของ MariaDB ไม่ตรงกัน:โปรดดำเนินการตามขั้นตอนการอัปเกรด MariaDB ที่ระบุไว้ในเอกสารให้เสร็จสมบูรณ์ จากนั้นลองใช้งาน Kopano อีกครั้ง
• สิทธิ์การเข้าถึงหรือการตรวจสอบสิทธิ์:แก้ไขบัญชีฐานข้อมูล Kopano และยืนยันการเข้าสู่ระบบจากโฮสต์ Kopano
• การใช้งานเวอร์ชันที่ไม่รองรับ:หยุดการทดลองกำหนดค่า กู้คืนสภาพแวดล้อมฐานข้อมูลก่อนการอัปเกรด หรือเปลี่ยนไปใช้ชุดค่าผสม Kopano/ฐานข้อมูลที่ผู้จำหน่ายหรือแหล่งที่มาของแพ็กเกจของคุณรองรับ

กรณีสุดท้ายมีความสำคัญ คู่มือผู้ดูแลระบบ Kopano Core ที่เผยแพร่สู่สาธารณะนั้นมาจากผลิตภัณฑ์รุ่นเก่า ในขณะที่ MySQL และ MariaDB รุ่นปัจจุบันมีการเปลี่ยนแปลงอย่างต่อเนื่อง หากคุณไม่พบข้อความสนับสนุนสำหรับการใช้งานร่วมกันของคุณโดยเฉพาะ การขาดเอกสารไม่ควรตีความว่าไม่เข้ากันได้

8. เริ่มใช้งาน Kopano และตรวจสอบความถูกต้องมากกว่าแค่สถานะของกระบวนการ

sudo systemctl start kopano-server
sudo systemctl start kopano-spooler

systemctl --no-pager --full status kopano-server
journalctl -u kopano-server -n 50 --no-pager

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

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

คุณควรเปลี่ยนวิธีการเมื่อใด?

หยุดทำการเปลี่ยนแปลงโครงสร้างข้อมูลซ้ำเมื่อพบเงื่อนไขใดๆ ต่อไปนี้:

• ข้อผิดพลาด SQL เปลี่ยนแปลงไปหลังจากการแก้ไขด้วยตนเองทุกครั้ง ซึ่งบ่งชี้ว่าโครงสร้างฐานข้อมูลถูกย้ายเพียงบางส่วน
• ฐานข้อมูลที่กู้คืนก่อนการอัปเกรดใช้งานได้กับฐานข้อมูลเวอร์ชันเก่า แต่ใช้งานไม่ได้อย่างต่อเนื่องกับฐานข้อมูลเวอร์ชันใหม่
• คุณไม่สามารถยืนยันได้ว่า Kopano ที่คุณสร้างขึ้นนั้นรองรับ MySQL หรือ MariaDB เวอร์ชันหลักที่ติดตั้งไว้หรือไม่
• การตรวจสอบตารางรายงานความเสียหายมากกว่าความไม่เข้ากันของโครงสร้างข้อมูลตามปกติ
• การแปลงชุดอักขระจะต้องแก้ไขตารางขนาดใหญ่จำนวนมากโดยไม่มีการทดสอบการย้อนกลับ

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

รายการตรวจสอบการยืนยันขั้นสุดท้าย

• ข้อมูลสำรองฐานข้อมูลและข้อมูลสำรองการตั้งค่า Kopano จะถูกเก็บรักษาไว้
• มีการบันทึกเวอร์ชัน MySQL หรือ MariaDB ที่แน่นอนไว้
• ข้อผิดพลาด SQL ครั้งแรกที่เกิดขึ้นจริงได้รับการระบุและอธิบายแล้ว
• ไม่มีการนำวิธีการแก้ปัญหาแบบกว้างๆ เกี่ยวกับโหมด SQL หรือชุดอักขระมาใช้โดยปราศจากหลักฐาน
• การบำรุงรักษาสคีมา Kopano ที่จำเป็นต้องตรงกับเวอร์ชัน Kopano ที่ติดตั้งไว้
• kopano-serverสามารถทนต่อการรีสตาร์ทครั้งที่สองได้
• กล่องจดหมาย โฟลเดอร์ และข้อความที่มีอยู่เดิมยังคงอยู่ครบถ้วน
• การทดสอบการจัดส่งขาเข้า ขาออก และการจัดส่งในพื้นที่ประสบความสำเร็จ
• ส่วนประกอบเสริมที่ใช้ในสภาพแวดล้อมของคุณได้รับการทดสอบแล้ว

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