Litestream v0.5.0
(fly.io)- Litestream v0.5.0 là bản cập nhật giúp tăng đáng kể khả năng phục hồi của các ứng dụng dựa trên SQLite
- Giới thiệu định dạng tệp LTX mới, hỗ trợ khôi phục theo thời điểm (PITR) hiệu quả và nén dữ liệu
- Loại bỏ khái niệm thế hệ (generation) giữa nhiều phiên bản Litestream để đơn giản hóa việc quản lý và vận hành
- Việc phát triển và tích hợp trở nên thuận tiện hơn nhờ hỗ trợ JetStream và chuyển sang driver Go SQLite hiện đại
- Trong tương lai dự kiến sẽ bổ sung các tính năng mạnh hơn như bản sao chỉ đọc dựa trên VFS
Tổng quan và các cập nhật chính
- Litestream là công cụ sao lưu và khôi phục cho ứng dụng SQLite, là mã nguồn mở và có thể chạy ở mọi nơi
- Việc khôi phục sau sự cố máy chủ rất đơn giản, giúp bảo đảm an toàn khi xây dựng ứng dụng full-stack dựa trên SQLite
- Phiên bản mới nhất (v0.5.0) hỗ trợ cải thiện tốc độ và khôi phục theo thời điểm (Point-In-Time Recovery, PITR)
Hướng phát triển của LiteFS và Litestream
- Các dự án SQLite chính do Ben Johnson của Fly.io phát triển là Litestream và LiteFS
- LiteFS hướng tới sao chép trực tiếp ở cấp giao dịch nội bộ của cơ sở dữ liệu bằng cách tận dụng hệ thống tệp FUSE
- Tuy nhiên, nhu cầu của thị trường lại tập trung vào Litestream có cách vận hành đơn giản hơn, nên những bài học kỹ thuật từ LiteFS đã được áp dụng ngược trở lại vào Litestream
Giới thiệu định dạng tệp LTX
-
Để giải quyết giới hạn và sự kém hiệu quả của cách sao lưu theo đơn vị trang của SQLite trước đây, dự án đã giới thiệu LTX (định dạng dựa trên giao dịch)
-
LTX cung cấp quản lý phạm vi trang theo thứ tự giao dịch và nén gộp các trang trùng lặp (compaction)
- Ví dụ: có thể áp dụng nhiều tệp LTX theo thứ tự mới nhất, chỉ phản ánh phiên bản mới nhất của các trang bị trùng để nhanh chóng khôi phục trạng thái cuối cùng của cơ sở dữ liệu
- Thông qua cấu trúc phân tầng tệp, có thể hợp nhất các tệp LTX theo mốc 30 giây, 5 phút và 1 giờ để giảm mạnh số lượng tệp cần cho việc khôi phục
-
Tốc độ khôi phục dữ liệu chỉ bị giới hạn bởi thông lượng I/O
Loại bỏ khái niệm thế hệ (generation)
- Litestream có thể chạy và gặp sự cố như một tiến trình Unix thông thường, và khi dừng hoạt động có thể phát sinh sự không nhất quán trong đồng bộ dữ liệu
- Trước đây, để tránh xung đột giữa nhiều phiên bản, hệ thống đã đưa vào cơ chế quản lý gọi là thế hệ (generation),
- nhưng sau khi chuyển sang LTX, việc khôi phục dựa trên ID giao dịch đã trở nên khả thi, nên không còn cần quản lý thế hệ phức tạp nữa
Nâng cấp lên Litestream v0.5.0
- Do định dạng tệp đã thay đổi đáng kể, không thể khôi phục trực tiếp từ các phân đoạn WAL của v0.3.x
- Việc nâng cấp khá đơn giản: chạy phiên bản mới → tạo tệp LTX mới, và các tệp WAL cũ vẫn được giữ nguyên
- Tính tương thích của tệp cấu hình cũng được duy trì
- Thay đổi chính: hiện tại mỗi cơ sở dữ liệu chỉ cho phép một đích sao chép duy nhất, đây là quyết định nhằm giúp phát triển dễ hơn và tránh xung đột sao chép
- Câu lệnh vẫn giữ nguyên như trước, nhưng cách tham chiếu đã chuyển sang dựa trên ID giao dịch (TXID)
Các cải tiến khác
- Nhờ nén theo đơn vị trang và bổ sung chỉ mục trong thư viện định dạng tệp LTX, giờ đây có thể truy cập có chọn lọc vào từng trang trong tệp lớn và mở rộng thêm tính năng
- Trong tương lai, điều này cũng có thể cho phép triển khai các tính năng như truy vấn dữ liệu tại một thời điểm cụ thể
- Loại bỏ phụ thuộc CGO và chuyển driver Go SQLite sang modernc.org/sqlite, mang lại lợi thế cho tự động build và môi trường cross-compile
- Bao gồm loại bản sao hỗ trợ JetStream, cùng với việc cập nhật client cho S3/Google Storage/Azure Blob Storage và hỗ trợ phiên bản mới của S3 API
Kế hoạch tiếp theo
- Tính năng Litestream VFS cho môi trường đích đọc bản sao đang được phát triển
- Với tính năng này, hệ thống sẽ có thể đọc ngay chỉ những trang cần thiết từ S3 để tạo bản sao nhanh
- Nguyên mẫu đã tồn tại và sắp được công bố
1 bình luận
Ý kiến trên Hacker News
Trải nghiệm dành cho nhà phát triển khi triển khai ứng dụng SQLite lên Fly.io có phần hơi thất vọng; đã thử trong nhiều giờ để chạy một ứng dụng Rails production nhưng vấp phải đủ vấn đề như khởi tạo cơ sở dữ liệu, migration, trạng thái có thể ghi, v.v.; nguyên nhân gốc là eager loading của gem do chính người viết tạo ra, nhưng vì có nhiều lớp runner chồng lên trên nên rất khó chẩn đoán; mong Fly.io đầu tư hơn vào việc cải thiện DX, nhưng cũng cho rằng với Fly.io đây có lẽ không phải ưu tiên vì các khách hàng lớn không dùng kiểu workload này; tò mò không biết những người đã triển khai ứng dụng SQLite trong production đang dùng host nào
Năm ngoái tôi đã thiết lập mới một ứng dụng Rails 8 trên Fly; kho dữ liệu chính dùng PG, nhưng các solid stack db phụ thì dùng SQLite; có một vài vấn đề nhỏ ở phía Rails liên quan tới migration của solid queue, nhưng đó không phải lỗi từ Fly; tôi cũng đang cân nhắc chuyển cả PG chính sang SQLite, và hiện tại đã dùng SQLite khá tốt ở một số phần
Tôi đang dùng SQLite cho một ứng dụng console trong môi trường production; DB nằm trên một ổ đĩa chia sẻ file
Rất vui khi Fly khởi động lại việc phát triển Litestream sau 2 năm bị gián đoạn; tôi dùng Litestream mọi lúc và cực kỳ hài lòng; chi phí sử dụng thực tế còn rẻ hơn nhiều so với khẩu hiệu quảng cáo “chỉ vài xu mỗi ngày”; khi dùng sao chép Litestream lên S3 cho ứng dụng production thực tế, chi phí hàng tháng chỉ vào khoảng 2–3 cent (0.02–0.03 USD) chia sẻ kinh nghiệm liên quan
Thật thú vị khi Litestream sắp hỗ trợ mọi đích đến tương thích s3; từ trước tới nay tôi dùng giải pháp SFTP vì không muốn dùng dịch vụ lưu trữ đối tượng đám mây bị hardcode; xin gửi lời cảm ơn tới các nhà phát triển liên kết PR và liên kết hướng dẫn
Tôi muốn sớm thử Litestream; tò mò không biết có benchmark hay bản demo nào về thời gian khôi phục thực tế không; trước đây tôi từng tự triển khai backup lên S3, và hồi đó Litestream mất tới 20 phút để khôi phục 1.000 hàng; cảm giác khá thiếu tối ưu; muốn biết hiện nay tốc độ khôi phục đã được cải thiện tới mức nào
Tôi muốn biết Litestream có ưu điểm gì so với sqlite.org/rsync
Điểm khác biệt của Litestream là không cần một “server” ở đầu bên kia, chỉ cần object storage là đủ; điều này có thể rẻ hơn về mặt chi phí
Litestream hỗ trợ khôi phục theo thời điểm (Point In Time Recovery); không chỉ có replica ở thời điểm hiện tại mà còn có thể khôi phục về snapshot ở bất kỳ thời điểm nào
Một câu chuyện thú vị liên quan tới LiteFS và Litestream: “Phản ứng của thị trường chính là câu trả lời! Người dùng thích Litestream hơn”; thành thật mà nói, Litestream dễ vận hành và dễ hiểu hơn, nên tôi lại tập trung vào nó
Chia sẻ liên kết về Litestream Revamped và bài thảo luận trên Hacker News
Blog
Bài thảo luận HN
Chúng tôi đang triển khai ứng dụng nội bộ lên một fleet từ xa bên ngoài, nhưng Internet không ổn định nên rất khó xây dựng hệ thống thu thập dữ liệu đúng cách; tôi muốn biết Litestream xử lý backup thế nào trong môi trường thiếu ổn định như vậy, và liệu có thể hợp nhất nhiều bản backup vào một DB trung tâm để truy vấn hay không
Một cảnh báo nhỏ: có lần khi chuyển một ứng dụng doanh nghiệp legacy lên Azure, tôi phải xử lý một kiến trúc trong đó một máy chủ MSSQL cục bộ chạy cùng với ứng dụng, khá giống mô hình của Litestream; ứng dụng được phát triển với giả định truy cập cục bộ (độ trễ dưới 1ms), nên xuất hiện N+1 query nghiêm trọng ở khắp nơi; điều này khiến việc chuyển sang kiến trúc khác gần như bất khả thi; nếu bạn lo rằng dùng kiểu hosting này rồi sẽ đụng trần khả năng mở rộng thì tôi không khuyến nghị, dù một máy đơn hiện nay cũng có thể gánh được quy mô rất lớn nên trên thực tế có thể đây không phải vấn đề lớn
Với việc hiện nay một instance đơn có thể hỗ trợ hơn 20TB RAM và hàng trăm core, tôi nghĩ lựa chọn này hoàn toàn có sức cạnh tranh; nếu kết hợp với kiến trúc cell theo từng người dùng/tenant thì còn có thể hiệu quả hơn nữa
Trước đây tôi cũng từng làm trên một sản phẩm mà app server và database nằm cùng một rack, nên cũng là kiến trúc độ trễ thấp tương tự; khi sản phẩm đó thành công và N+1 query tăng lên tới hàng nghìn, 1ms nhanh chóng biến thành hơn 500ms; cứ khoảng hai tháng lại phải vào NewRelic tìm chỗ chậm và sửa; vì đó là ứng dụng Rails nên vấn đề N+1 rất dễ phát sinh, nhưng cũng tương đối dễ khắc phục
Thói quen viết query sai rồi sớm muộn gì cũng sẽ gây vấn đề; khó có thể xem đó là nhược điểm của riêng cách tiếp cận này
Thực ra xét cho cùng, dùng kiểu dịch vụ này chỉ làm lộ ra mức độ có vấn đề trong code của bạn mà thôi, nên tôi không nghĩ đây là một đánh đổi lớn; lỗi là ở code chứ không phải ở dịch vụ
Hỏi N+1 là gì
Tôi thực sự rất thích Litestream; nó dễ dùng và chưa từng bị crash; tôi khuyên nên chạy nó như một dịch vụ unit của systemd; tôi không chỉ dùng nó như công cụ backup mà còn dùng để mirroring cơ sở dữ liệu; cũng đang mong chờ tính năng read-replica sắp ra mắt