Skip to main content

Di chuyển tệp nhị phân

Bản phát hành phiên bản chính 6.0 sắp tới của Server Pro và Community Edition sẽ giảm một nửa dung lượng lưu trữ dành cho tệp nhị phân. Một quá trình di chuyển trực tuyến được bao gồm trong phiên bản 5.5.7, cho phép giảm thiểu thời gian ngừng hoạt động trong quá trình nâng cấp. Kể từ Server Pro 4.x, các tệp nhị phân được lưu hai lần: trong kho lưu trữ tệp đang hoạt động ở “filestore” và trong hệ thống lịch sử dự án đầy đủ. Từ nay trở đi, mỗi tệp sẽ chỉ có một bản sao được lưu trong hệ thống lịch sử dự án đầy đủ. Việc di chuyển sang hệ thống lưu trữ hợp nhất gồm hai phần: một cờ mới để kiểm soát giai đoạn di chuyển và một script xử lý tất cả các dự án đang hoạt động và các dự án đã bị xóa mềm. Các giai đoạn:
  • OVERLEAF_FILESTORE_MIGRATION_LEVEL=0 (mặc định), các tệp được đọc và ghi vào filestore. Các tệp được ghi vào history một cách bất đồng bộ.
  • OVERLEAF_FILESTORE_MIGRATION_LEVEL=1, các tệp được đọc từ history với phương án dự phòng là filestore, và được ghi vào cả filestore lẫn history. Có thể hạ cấp về OVERLEAF_FILESTORE_MIGRATION_LEVEL=0.
  • OVERLEAF_FILESTORE_MIGRATION_LEVEL=2, các tệp chỉ được đọc và ghi vào history. Không thể hạ cấp về OVERLEAF_FILESTORE_MIGRATION_LEVEL=1, trừ khi việc di chuyển được thực hiện ở chế độ “ngoại tuyến”.
Khi lưu trữ dữ liệu trong S3 và sử dụng các tài khoản dịch vụ riêng biệt cho filestore (OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID) và history (OVERLEAF_HISTORY_S3_ACCESS_KEY_ID): Vui lòng cấp cho người dùng filestore quyền đọc bucket history dành cho blob OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET. Từ nay trở đi, dịch vụ filestore sẽ phục vụ các yêu cầu đọc từ dịch vụ biên dịch.
Chúng tôi đặc biệt khuyến nghị thực hiện việc di chuyển tệp nhị phân trong môi trường không phải production/sandbox trước.
Giấy phép Server Pro tiêu chuẩn cho phép bạn chạy ứng dụng trong một môi trường production cũng như một môi trường không phải production/sandbox; chúng tôi đặc biệt khuyến nghị bạn chuẩn bị một môi trường không phải production để kiểm thử.
Nếu bạn nâng cấp lên Server Pro/CE phiên bản 6.0 và sau đó quyết định muốn hạ cấp về phiên bản cũ hơn, bạn nên khôi phục từ một bản sao lưu toàn hệ thống.

Quy trình di chuyển

1

Tạo bản sao lưu

Tạo một bản sao lưu đầy đủ cho phiên bản của bạn với snapshot nhất quán của các thư mục mongo, redis và sharelatex.
2

Cập nhật

Toolkit: Sử dụng script $ bin/upgrade để nâng cấp toolkit lên phiên bản mới nhất. Khi được hỏi, không xác nhận lời nhắc Upgrade image? — thay vào đó, hãy chỉnh sửa thủ công tệp config/version và đặt giá trị thành 5.5.7.docker-compose.yml cũ: Cập nhật phiên bản của dịch vụ sharelatex thành 5.5.7.
3

Ước tính số lượng dự án bị ảnh hưởng

Ví dụ đầu ra:
4

Flush các hàng đợi lịch sử dự án

Lặp lại việc flush cho đến khi tất cả các dự án đã được flush ("project_ids":0).
Trong trường hợp “failedProjects” khác không, vui lòng liên hệ bộ phận hỗ trợ và không tiếp tục việc di chuyển tệp nhị phân.
5

Chuyển giai đoạn di chuyển lên 1

Toolkit: Đặt OVERLEAF_FILESTORE_MIGRATION_LEVEL=1 trong config/variables.env.docker-compose.yml cũ: Đặt OVERLEAF_FILESTORE_MIGRATION_LEVEL: '1' trong phần environment của dịch vụ sharelatex.
6

Áp dụng thay đổi cấu hình và khởi động phiên bản

Toolkit: bin/up -ddocker-compose.yml cũ: docker compose up -d
7

Xác minh quyền truy cập tệp nhị phân

Mở một dự án trong trình soạn thảo Overleaf trên trình duyệt và chọn một tệp nhị phân, chẳng hạn như một hình ảnh.
8

Chạy script di chuyển

Nếu bạn đang lưu bền tệp log bên ngoài container sharelatex, hãy đảm bảo chủ sở hữu thư mục log được đặt là người dùng www-data (uid=33) để tệp log đầu ra có thể được ghi.
Đầu ra sẽ trông như sau:
Nếu việc di chuyển thành công, bạn sẽ nhận được mã thoát 0, và các dòng cuối cùng cho thấy không có lỗi:
Tệp log sẽ trông như sau (sử dụng đường dẫn do script in ra):
9

Dừng phiên bản

Toolkit: bin/stop sharelatexdocker-compose.yml cũ: docker compose stop sharelatex
10

Làm cho các tệp cũ không thể truy cập được từ ứng dụng

Bây giờ bạn có thể di chuyển các tệp cũ sang bộ lưu trữ thứ cấp. Chúng tôi khuyên bạn nên giữ lại các tệp này một thời gian phòng khi có vấn đề phát sinh sau này.
11

Chuyển giai đoạn di chuyển lên 2

Toolkit: Đặt OVERLEAF_FILESTORE_MIGRATION_LEVEL=2 trong config/variables.env.docker-compose.yml cũ: Đặt OVERLEAF_FILESTORE_MIGRATION_LEVEL: '2' trong phần environment của dịch vụ sharelatex.
12

Áp dụng thay đổi cấu hình và khởi động phiên bản

Toolkit: bin/up -ddocker-compose.yml cũ: docker compose up -d
13

Xác minh quyền truy cập tệp nhị phân

Mở một dự án trong trình soạn thảo Overleaf trên trình duyệt và chọn một tệp nhị phân, chẳng hạn như một hình ảnh.

Di chuyển ngoại tuyến

Nếu bạn muốn ngăn người dùng đăng nhập trong khi script di chuyển tệp nhị phân đang chạy, vui lòng làm theo các bước sau:
  • Đăng nhập vào phiên bản Overleaf của bạn bằng tài khoản quản trị viên
  • Nhấp vào nút Admin và chọn Manage Site
  • Nhấp vào tab Open/Close Editor
  • Nhấp vào nút Close Editor
  • Nhấp vào nút Disconnect all users
Sau khi thực hiện xong, nếu có người dùng nào đang đăng nhập, họ sẽ bị chuyển hướng đến trang bảo trì, và bất kỳ người dùng mới nào truy cập trang đăng nhập sẽ thấy trang bảo trì và không thể đăng nhập. Bạn cần lặp lại các bước này khi khởi động lại phiên bản. Để mở lại trang, chỉ cần khởi động lại phiên bản.

Di chuyển trực tuyến

Có thể chạy các script di chuyển trong khi ứng dụng vẫn đang chạy. Có một vài điều cần cân nhắc:
  • Quá trình di chuyển tiêu tốn nhiều IO, bạn nên theo dõi mức sử dụng tài nguyên trong khi script đang chạy.
  • Với mức xử lý đồng thời cao, event loop trong dịch vụ filestore có thể bị chặn ở một mức độ nào đó, dẫn đến trải nghiệm người dùng bị suy giảm. Chúng tôi khuyên bạn nên bắt đầu với các giá trị mặc định --concurrency=10 và --concurrent-batches=1.
  • Bạn có thể dừng script bất cứ lúc nào. Khi chạy lại, script sẽ xác thực các dự án trước đó và bỏ qua các tệp đã được xử lý. Điều này hữu ích nếu bạn muốn chạy việc di chuyển vào những giờ ít bận rộn hơn (ví dụ: ban đêm).
Khuyến nghị của chúng tôi là đóng trang và chạy việc di chuyển ngoại tuyến trong một khoảng thời gian bảo trì khi số lượng dự án của bạn ít hơn 1000 (xem đầu ra của script di chuyển khi chạy với --report). Nếu số lượng dự án lớn, bạn có thể chạy script và theo dõi tiến độ, sau đó quyết định tiếp tục chạy trực tuyến hay ngoại tuyến tùy theo trường hợp cụ thể của mình.

Dọn dẹp dữ liệu tệp nhị phân cũ

Khi bạn đã hoàn tất việc di chuyển và xác minh rằng các dự án vẫn có thể truy cập tất cả các tệp của chúng, bạn có thể xóa bộ lưu trữ tệp cũ trong /var/lib/overleaf/data/user_files. Chúng tôi đặc biệt khuyến nghị giữ lại các tệp này một thời gian - bạn có thể làm cho chúng không thể truy cập được từ ứng dụng bằng cách đổi tên thư mục trước.

Khắc phục sự cố

Chúng tôi sẽ bổ sung các lời khuyên khắc phục sự cố tại đây. Xin lưu ý rằng mặc dù thông thường chúng tôi chỉ hỗ trợ khách hàng Server Pro, nhưng do tính chất của lần di chuyển này, chúng tôi cũng sẽ cố gắng hết sức để hỗ trợ khách hàng CE gặp phải các vấn đề cụ thể liên quan đến việc di chuyển tệp nhị phân. Nếu script di chuyển tệp nhị phân thất bại (tức là thoát với lỗi hoặc in ra số dự án thất bại khác không), vui lòng gửi các thông tin sau đến nhóm hỗ trợ của chúng tôi qua email support+filestoremigration@overleaf.com, bao gồm chi tiết: Tiêu đề: Binary file migration problem Nội dung:
  • Loại phiên bản: CE hoặc Server Pro (xóa phần không phù hợp)
  • Kiểu cài đặt: Overleaf toolkit hoặc docker-compose.yml hoặc khác (xóa phần không phù hợp)
  • Phiên bản: 5.5.x (toolkit: $ cat config/version)
  • Đầu ra của script di chuyển (nằm trong container tại /var/log/overleaf)
  • Báo cáo: (chạy script di chuyển với --report)
  • Số dự án đã xử lý: (theo lần chạy script gần nhất)
  • Thời gian di chuyển:
  • Đầu ra của bin/doctor (khi sử dụng toolkit)
  • Phiên bản toolkit: $ git rev-parse HEAD (khi sử dụng Toolkit)
Hãy cân nhắc đính kèm các tệp log của dịch vụ filestore vào email. Bạn có thể tìm thấy chúng tại /var/log/overleaf/filestore.log bên trong container sharelatex và xuất chúng ra như sau:
Vui lòng loại bỏ mọi thông tin nhạy cảm khỏi các tệp log trước khi đính kèm.

Tệp bị thiếu

Các phiên bản Server Pro/CE cũ hơn tạo các mục trong cây tệp trước khi việc tải lên của người dùng hoàn tất, điều này có thể khiến các tệp hiển thị là bị thiếu khi việc tải lên thất bại. Bạn có thể thấy một vài trường hợp như vậy được báo cáo là lỗi khi xử lý tất cả các cây tệp. Trong trường hợp số lượng tệp bị thiếu ít, hãy cân nhắc xem xét thủ công các trường hợp này và xóa chúng khỏi trình soạn thảo trên trình duyệt. Trong trường hợp số lượng tệp bị thiếu nhiều, hãy cân nhắc liên hệ bộ phận hỗ trợ, xem mẫu email ở trên.

Tìm các cây tệp bị hỏng

Việc di chuyển có thể thất bại đối với các dự án có cây tệp bị sai định dạng (ví dụ: tên tệp bị trống). Bạn có thể tìm danh sách các vấn đề này bằng script find_malformed_filetrees, script này kiểm tra tất cả các dự án trong cơ sở dữ liệu:
Để sửa các đường dẫn không hợp lệ, hãy dùng script fix_malformed_filetree, chạy lệnh một lần cho mỗi đường dẫn bị lỗi:
Lần sửa đổi cuối 5 tháng 10, 2026