การอัปเกรดจาก 1.x เป็น 2.0

SnapOtter 1.x จัดเก็บทุกอย่างในไฟล์ SQLite ไฟล์เดียวและทำงานเป็นคอนเทนเนอร์เดียว SnapOtter 2.0 ใช้ PostgreSQL และ Redis คู่มือนี้อธิบายขั้นตอนการย้ายการติดตั้ง 1.x ไปยัง 2.0 โดยไม่สูญเสียข้อมูล

โดยสรุป: ใช้โวลุ่ม /data เดิมของคุณซ้ำ แล้ว 2.0 จะนำเข้าฐานข้อมูล 1.x ของคุณโดยอัตโนมัติในการบูตครั้งแรก ผู้ใช้ ไฟล์ที่บันทึกไว้ การตั้งค่า API key และไปป์ไลน์ของคุณจะถูกย้ายมาด้วย ฐานข้อมูลเดิมจะไม่ถูกแก้ไข ดังนั้นคุณสามารถย้อนกลับได้เสมอ

หมายเหตุถึงผู้ใช้ 1.x ของเรา

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

ก่อนเริ่ม: สำรองข้อมูลโวลุ่ม /data ทั้งหมด

ทำสิ่งนี้ก่อนเสมอ ทุกครั้ง สำรองข้อมูลโวลุ่ม /data ทั้งหมด ไม่ใช่แค่ไฟล์ snapotter.db

นี่คือเหตุผลว่าทำไมมันจึงสำคัญ 1.x รัน SQLite ในโหมด WAL ดังนั้นคอนเทนเนอร์ 1.x ที่หยุดทำงานมักจะทิ้งข้อมูลที่คอมมิตไว้ส่วนใหญ่ไว้ใน snapotter.db-wal ข้าง ๆ snapotter.db ที่แทบว่างเปล่า การคัดลอกเฉพาะ snapotter.db จะได้ฐานข้อมูลที่ว่างเปล่าและสูญเสียทุกอย่างไปแบบเงียบ ๆ โวลุ่มบรรจุ snapotter.db, snapotter.db-wal, snapotter.db-shm และไดเรกทอรี files/ ของคุณไว้ด้วยกัน และต้องเดินทางไปพร้อมกันเป็นชุด

# Adjust the volume name to match yours (see "Check your volume name" below).
docker run --rm -v SnapOtter-data:/data -v "$PWD":/backup \
  alpine tar czf /backup/snapotter-1x-data.tgz -C /data .

อัปเกรดเป็น 1.17.2 ก่อน

อัปเกรดการติดตั้ง 1.x ของคุณให้เป็นรีลีส 1.x ล่าสุด (1.17.2) ก่อนย้ายไปยัง 2.0 นั่นช่วยให้ 1.x รันการย้ายสคีมาสุดท้ายของตัวเอง ดังนั้น 2.0 จึงนำเข้าจากสคีมาที่รู้จักและครบถ้วน การอัปเกรดจาก 1.x รุ่นเก่ากว่าไปยัง 2.0 โดยตรงไม่ได้รับการรองรับ

ตรวจสอบชื่อโวลุ่มของคุณ

ตัวนำเข้าจะเห็นข้อมูลของคุณก็ต่อเมื่อสแตก 2.0 เมานต์โวลุ่มเดียวกับที่การติดตั้ง 1.x ของคุณใช้ ชื่อโวลุ่มของ Docker เป็นแบบตัวพิมพ์ใหญ่เล็กมีผล และสนิปเพ็ต README รุ่นเก่าใช้ snapotter-data ตัวพิมพ์เล็ก ในขณะที่ไฟล์ Compose ใช้ SnapOtter-data ยืนยันว่าคุณมีตัวไหน:

docker volume ls | grep -i snapotter

ใช้ชื่อนั้นให้ตรงเป๊ะในการกำหนดค่า 2.0 ของคุณ

เส้นทาง A: คอนเทนเนอร์เดียว (เร็วที่สุด)

หากคุณรัน SnapOtter ด้วย docker run เดียว ก็ทำแบบนั้นต่อไป 2.0 จะบูต PostgreSQL และ Redis แบบฝังตัวภายในคอนเทนเนอร์เมื่อคุณไม่ได้ตั้งค่า DATABASE_URL หรือ REDIS_URL และตรวจจับพร้อมนำเข้า /data/snapotter.db โดยอัตโนมัติในการบูตครั้งแรก

docker run -d --name snapotter -p 1349:1349 \
  -v SnapOtter-data:/data \
  snapotter/snapotter:latest

สังเกตในบันทึกหาบรรทัดแบบ:

Imported 1.x SQLite database: {"tables":{"users":2,"teams":1,...},"blobs":{"present":1,"missing":0}}

แค่นั้นเอง เข้าสู่ระบบด้วยข้อมูลรับรองที่คุณมีอยู่

เส้นทาง B: Compose (แนะนำสำหรับการใช้งานจริง)

สแตก Compose ของ 2.0 รันสามบริการ (แอป, Postgres, Redis) ใช้โวลุ่ม /data ของ 1.x ซ้ำสำหรับบริการแอป แอปจะตรวจจับ /data/snapotter.db และนำเข้าสู่ Postgres โดยอัตโนมัติในการบูตครั้งแรก

services:
  SnapOtter:
    image: snapotter/snapotter:latest
    volumes:
      - SnapOtter-data:/data          # your existing 1.x volume
      - SnapOtter-workspace:/tmp/workspace
    environment:
      - DATABASE_URL=postgres://snapotter:snapotter@postgres:5432/snapotter
      - REDIS_URL=redis://:snapotter@redis:6379
    # ...

หากคุณต้องการชี้ไปยังฐานข้อมูลเดิมอย่างชัดเจน ให้ตั้งค่า SQLITE_MIGRATE_PATH=/data/snapotter.db พาธที่ระบุชัดเจนจะมีผลเหนือการตรวจจับอัตโนมัติเสมอ

ดูตัวอย่างการนำเข้าก่อน (ไม่บังคับ)

หากต้องการดูว่าจะนำเข้าอะไรบ้างอย่างแม่นยำโดยไม่เขียนอะไรลงไป ให้รันแบบ dry run กับไฟล์ฐานข้อมูลของคุณ:

pnpm --filter @snapotter/api migrate:sqlite -- /path/to/snapotter.db --dry-run

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

อะไรถูกย้ายมา และอะไรไม่ถูกย้าย

ถูกย้ายมา:

• ผู้ใช้ และความสามารถในการเข้าสู่ระบบ แฮชรหัสผ่านไม่เปลี่ยนแปลง ดังนั้นชื่อผู้ใช้และรหัสผ่านเดิมยังใช้งานได้
• ทีม การตั้งค่า (รวมถึงข้อมูลระบุตัวตนของอินสแตนซ์) บทบาท API key (ยังใช้งานได้ต่อไป) และไปป์ไลน์ที่บันทึกไว้
• ระเบียนประวัติงาน
• ไลบรารีไฟล์ที่บันทึกไว้ของคุณ ทั้งระเบียนและตัวไฟล์จริง เพราะ /data/files ถูกรักษาไว้บนโวลุ่ม

ไม่ถูกย้ายมา:

• เซสชันการเข้าสู่ระบบ ทุกคนต้องเข้าสู่ระบบหนึ่งครั้งหลังการอัปเกรด ข้อมูลรับรองไม่เปลี่ยนแปลง ดังนั้นเป็นแค่การเข้าสู่ระบบใหม่ครั้งเดียว ไม่มีอะไรมากกว่านั้น
• ไฟล์อินพุตและเอาต์พุตของงานประมวลผลเดิม สิ่งเหล่านั้นอยู่ในพื้นที่ทำงานชั่วคราวและหายไปโดยการออกแบบ ระเบียนประวัติงานยังคงอยู่
• แฟล็กการยินยอมด้านการวิเคราะห์เฉพาะผู้ใช้จาก 1.x ซึ่งไม่มีสิ่งเทียบเท่าใน 2.0 (การวิเคราะห์ของ 2.0 เป็นการตั้งค่าระดับอินสแตนซ์)

การปิดการนำเข้า

หากคุณตั้งใจต้องการฐานข้อมูลใหม่เอี่ยมแม้ว่าจะมี snapotter.db อยู่บนโวลุ่ม ให้ตั้งค่า SQLITE_MIGRATE_PATH=off

หากคุณมีข้อมูลในอินสแตนซ์ 2.0 อยู่แล้ว

ตัวนำเข้าจะทำงานเฉพาะกับฐานข้อมูลที่ว่างเปล่าเท่านั้น หากคุณเริ่ม 2.0 ใหม่เอี่ยม (สร้างข้อมูล) แล้วภายหลังเมานต์ snapotter.db เดิม 2.0 จะตรวจจับมันแต่จะไม่นำเข้า เพราะการรวมสองชุดข้อมูลอาจชนกันที่ ID คุณจะเห็นคำเตือนในบันทึก หากต้องการนำเข้าข้อมูล 1.x คุณต้องมีอินสแตนซ์ที่ว่างเปล่า:

• หากอินสแตนซ์ 2.0 มีเพียงผู้ดูแลระบบเริ่มต้น (คุณยังไม่ได้ใช้งานจริง) ให้หยุดสแตก ลบโวลุ่ม Postgres (SnapOtter-pgdata) แล้วบูตอีกครั้งโดยมี /data เดิมอยู่ มันจะนำเข้าได้อย่างสะอาด สิ่งนี้ล้างเฉพาะข้อมูล Postgres แบบทิ้งได้เท่านั้น ไม่ใช่ฐานข้อมูล 1.x ของคุณ
• หากอินสแตนซ์ 2.0 มีข้อมูลจริงที่คุณต้องการเก็บไว้ สองชุดข้อมูลไม่สามารถรวมกันโดยอัตโนมัติได้ ให้เอ็กซ์พอร์ตสิ่งที่คุณต้องการและนำเข้าข้อมูล 1.x ไปยังการปรับใช้ใหม่เอี่ยมแยกต่างหาก

การย้อนกลับ

การอัปเกรดจะไม่แก้ไขหรือลบ snapotter.db 1.x ของคุณ หากคุณต้องการกลับไปใช้ 1.x ให้ปรับใช้อิมเมจ 1.x อีกครั้งกับโวลุ่มเดียวกัน สิ่งที่คุณสร้างใน 2.0 หลังการอัปเกรดอยู่ใน Postgres และจะไม่อยู่ในฐานข้อมูล 1.x ดังนั้นให้ย้อนกลับโดยเร็วหากคุณจะทำ