- Litestream là công cụ sao lưu an toàn các ứng dụng full-stack dựa trên SQLite lên object storage, và lần này đã có thay đổi tính năng lớn nhất từ trước đến nay
- Áp dụng định dạng tệp LTX và kỹ thuật compaction hiệu quả hơn so với cấu trúc cũ, giúp khôi phục theo thời điểm nhanh và hiệu quả
- Triển khai đơn giản hơn tính năng singleton cho reader và read replica bằng phương thức mới tận dụng conditional write
- Sắp tới sẽ cung cấp lớp read-replica dựa trên VFS, giúp mở rộng dễ dàng trong nhiều môi trường khác nhau
- Kiến trúc được cải thiện đáng kể cho phép đồng bộ đồng thời nhiều cơ sở dữ liệu, nâng cao khả năng mở rộng
Giới thiệu về Litestream và tầm quan trọng
- Litestream là công cụ mã nguồn mở cung cấp khả năng sao lưu an toàn nhiều ứng dụng full-stack dựa trên SQLite lên object storage
- Giải quyết vấn đề dữ liệu bị phụ thuộc vào một máy chủ do đặc tính nhúng của SQLite, đồng thời giúp khôi phục dữ liệu dễ dàng ngay cả khi máy chủ gặp sự cố
Quá trình phát triển của Litestream
- Litestream xuất hiện vào năm 2020 nhằm giúp việc sử dụng SQLite trở nên dễ dàng hơn
- Litestream chạy như một tiến trình riêng biệt với ứng dụng SQLite và thay thế quy trình checkpoint WAL, stream các thay đổi dữ liệu theo thời gian thực lên object storage như S3
- Ngay cả khi máy chủ bị mất, vẫn có thể khôi phục cơ sở dữ liệu hiệu quả về trạng thái mới nhất từ object storage
- Sau đó dự án LiteFS được phát triển thêm, hỗ trợ read replica và failover cơ bản cho primary, giúp SQLite có thể được sử dụng theo kiến trúc triển khai hiện đại tương tự Postgres
- Cả LiteFS và Litestream đều có ưu điểm riêng, nhưng Litestream được dùng rộng rãi hơn vì dễ triển khai và sử dụng hơn
Khôi phục theo thời điểm hiệu quả (Point-in-time Restore)
- Thiết kế Litestream trước đây liên tục ghi lại mọi thay đổi và gửi lên S3, nhưng cách này kém hiệu quả khi dữ liệu thay đổi thường xuyên trong lúc khôi phục
- Trong LiteFS, một cách tiếp cận nhận biết giao dịch đã được áp dụng, sử dụng định dạng tệp LTX để ghi lại các dải trang đã thay đổi theo thứ tự
- Có thể dễ dàng hợp nhất (compaction) nhiều tệp LTX và chỉ giữ lại phiên bản mới nhất, từ đó cải thiện mạnh tốc độ và hiệu quả khôi phục dữ liệu
- Cấu trúc này tương tự cây LSM
- Litestream mới cũng áp dụng tệp LTX và cơ chế compaction, nhờ đó hỗ trợ khôi phục chính xác theo thời điểm mà không cần lưu trữ quá nhiều dữ liệu trùng lặp
CASAAS: Compare-and-Swap as a Service
- Litestream phải hoạt động ngay cả khi ứng dụng SQLite không nhận biết hệ thống sao lưu, và nếu tiến trình bị chết do sự cố thì có thể xảy ra tình trạng bỏ sót thay đổi dữ liệu
- Để giải quyết vấn đề này, khái niệm generation được đưa vào nhằm định danh duy nhất mỗi phiên sao lưu và luồng log tương ứng của nó
- Trong LiteFS, Consul được dùng để đảm bảo chỉ có một reader, nhưng vì cần phụ thuộc bên ngoài nên Litestream triển khai đơn giản một đường sao chép duy nhất (singleton) bằng tính năng conditional write của object storage như S3
- Nhờ đó hệ thống có thể vận hành ổn định mà không bị nhầm lẫn ngay cả trong môi trường node ephemeral
Tính năng read replica gọn nhẹ
- LiteFS sử dụng hệ thống tệp FUSE để nhận biết giao dịch, nhưng điều này làm tăng độ phức tạp và gánh nặng triển khai
- Để giảm bớt điều đó, mô-đun mở rộng LiteVFS dựa trên SQLite Virtual Filesystem (VFS) được thiết kế để có thể hoạt động trong nhiều môi trường mà không cần FUSE
- Trong tương lai, Litestream cũng sẽ áp dụng cùng một lớp dựa trên VFS để cung cấp tầng read replica có thể trực tiếp fetch và cache các trang từ object storage như S3
- Dù không nhanh như SQLite cục bộ, hiệu năng được kỳ vọng sẽ đáp ứng tốt nhiều trường hợp sử dụng nhờ các chiến lược caching và prefetching
Mã nguồn mở và tính ứng dụng
- Litestream là mã nguồn mở hoàn toàn, không phụ thuộc vào Fly.io và có thể dùng ở bất cứ đâu
- Đã bổ sung khả năng đồng bộ lượng lớn cơ sở dữ liệu trong một tiến trình duy nhất, cho phép sao lưu/nhân bản hiệu quả hàng trăm đến hàng nghìn cơ sở dữ liệu
Cùng SQLite tiếp tục phát triển
- SQLite là cơ sở dữ liệu bền vững, liên tục tạo ra các trường hợp sử dụng mới ngay cả trong bối cảnh ngành công nghiệp thay đổi
- Gần đây, ở các lĩnh vực như tác nhân sinh mã dựa trên LLM, việc rollback và phân nhánh dữ liệu theo thời gian thực ngày càng quan trọng, nên khả năng khôi phục theo thời điểm được nâng cấp của Litestream có thể trở thành nền tảng quan trọng
- Về sau, kiến trúc được cải tiến này cũng sẽ đóng góp cho các khả năng mở rộng như rollback, fork, hỗ trợ tác nhân tự động hóa
- Litestream mới vượt trội hơn thiết kế cũ và đồng thời tăng cường cả khả năng mở rộng lẫn tính dễ sử dụng
2 bình luận
Litestream - công cụ sao chép luồng cho SQLite
Tôi đặt cược tất tay vào SQLite phía máy chủ
Ý kiến trên Hacker News
Chia sẻ trải nghiệm lần theo vị trí kho mã; 2 năm trước từng thấy bất tiện khi dùng litestream và litefs, nhưng lần này có cảm giác hầu hết vấn đề đã được giải quyết. Giờ có thể thoải mái áp dụng litestream cho cơ sở dữ liệu và bớt lo hơn về vấn đề nhiều writer. Cũng kỳ vọng vào lợi ích của lớp FUSE cho read replica. Trong pull request liên quan còn giới thiệu cách tiếp quản lease: nếu lease đã tồn tại thì tiến trình mới sẽ thử lại mỗi 1 giây để hỗ trợ rolling restart nhanh. Đây được xem là một cách tiếp cận thực dụng.
Có cảm giác Litestream mới đã triển khai đủ mọi tính năng mà tôi từng mong muốn; rất mong đợi và hào hứng.
Đánh giá tích cực về một cách làm rất thông minh và giúp triển khai đơn giản hơn. Trong tình huống cần sao lưu hàng nghìn cơ sở dữ liệu SQLite, trước nay đã từng tự chế giải pháp tạm bằng fanotify và Backup API của SQLite. Nếu wildcard replication hỗ trợ nhiều tệp, rất muốn chuyển sang Litestream.
Nhấn mạnh rằng sau khi chuyển sang LTX, ngay cả khi có hàng trăm hoặc hàng nghìn cơ sở dữ liệu trong một thư mục thì vẫn có thể sao chép
/data/*.db. Trước đây đây là một trở ngại mang tính quyết định. Giờ đây có triển vọng tích cực là trong môi trường multi-tenant, có thể phục hồi theo thời điểm mong muốn cho từng cơ sở dữ liệu của từng người dùng, đồng thời cho phép tải xuống và di chuyển dữ liệu theo đơn vị cơ sở dữ liệu.Gửi lời cảm ơn tới ben và chia sẻ trải nghiệm sử dụng thực tế: đã dùng litestream trong production hơn 1 năm cho một trường hợp nội bộ write-heavy (khoảng 12GB sau nén), và chi phí hàng tháng cực thấp, chỉ vài trăm won theo giá Azure. Đang mong chờ áp dụng các thay đổi mới.
Mong muốn trải nghiệm dành cho nhà phát triển với SQLite trên Fly được trau chuốt hơn. Điểm còn tiếc là thiếu UI và CLI riêng, nên việc thiết lập cơ sở dữ liệu ban đầu lên Fly Machine tốn nhiều công hơn dự kiến.
fly consolecũng không tích hợp ổn với SQLite và chạy trên máy riêng nên không thể truy cập volume chứa dữ liệu. Cuối cùng vẫn phải vào trực tiếp đúng máy bằngfly ssh console —pty, khá bất tiện. Các web app dựa trên SQLite thường quy mô nhỏ, nên muốn có doanh thu thì phải vận hành với số lượng lớn.Chia sẻ trải nghiệm cá nhân khi đúng lúc đang tìm hiểu Litestream thì đọc được bài này. Đang dùng Sqlite trên VPS và cân nhắc áp dụng Litestream. Hỏi liệu trong lúc tiến trình Litestream đang chạy có thể khôi phục cơ sở dữ liệu về một thời điểm cụ thể hay không. Cũng thắc mắc về khoảng thời gian không thể phục hồi do auto-checkpointing sẽ tiêu thụ WAL khi tiến trình bị sập; ví dụ nếu tiến trình dừng từ 2:00 đến 3:00 do sự cố thì có thể khôi phục về 1:55 hoặc 3:05, nhưng thông tin phục hồi trong khoảng 2:00~3:00 có thể đã biến mất.
Giải thích rằng Litestream lưu các WAL segment theo từng mốc thời gian nhất định; mặc định nó gửi thay đổi WAL mỗi giây, nên có thể phục hồi tới từng giây của thời điểm mong muốn trong phạm vi thời gian lưu giữ đã cấu hình.
Hỏi về vấn đề xử lý DST (giờ tiết kiệm ánh sáng ban ngày), chẳng hạn ở châu Âu ngày 30 tháng 3 thời gian nhảy từ 2:00 sang 3:00 thì hệ thống sẽ hoạt động ra sao.
Chia sẻ rằng trước đây từng tạo một sqlite vfs tên là DonutDB dựa trên dynamodb. Nhân dịp S3 có thêm khả năng CAS (Content Addressable Storage), đã định làm mới DonutDB thành phiên bản hỗ trợ S3, nhưng lần này lightstream đã hỗ trợ điều đó nên không còn cần tự phát triển nữa. Bày tỏ sự vui mừng và kỳ vọng được dùng công cụ mới.
Nhớ lại rằng khi triển khai ứng dụng, cách cũ là khởi chạy một instance máy chủ mới, chuyển lưu lượng khi health check đạt yêu cầu rồi tắt máy chủ cũ, nhưng trong quá trình chuyển đổi đó đã từng xảy ra vấn đề mất thay đổi trong cơ sở dữ liệu. Hỏi liệu thay đổi lần này có giải quyết được vấn đề đó hay chưa.
Cho rằng nên nhìn máy chủ không phải như một web server instance dùng một lần mà dưới góc độ cơ sở dữ liệu production. Khi triển khai web app python/sqlite, họ dùng cách nâng cấp gói và khởi động lại dịch vụ systemd thay vì thay cả máy. Nếu muốn giảm downtime thì có thể cân nhắc quá trình chuyển đổi bằng
SO_REUSEPORTv.v.; lúc đó tiến trình mới và cũ có thể cùng dùng cơ sở dữ liệu, nhưng nếu có thay đổi schema DB thì vẫn khó tránh một khoảng downtime nhất định. Họ cho rằng điều này có lẽ cũng tương tự với các DB khác.Cho rằng đây vẫn không phải vấn đề dễ giải quyết, vì vẫn chỉ có một writer có thể giữ lease. Dù dịch vụ mới có chạy lên thì cũng chỉ lấy được lease khi writer cũ đã dừng. Có cung cấp công cụ để thay writer, nhưng việc chờ request hoặc một khoảng downtime ngắn là khó tránh.
Hỏi rằng nếu dùng litestream để sao chép vô số cơ sở dữ liệu theo từng người dùng (trường hợp sử dụng tiêu biểu được nhắc trong tài liệu), thì có cách nào thêm cơ sở dữ liệu mới động trong lúc chạy hay không. Chia sẻ rằng hiện tại file cấu hình là tĩnh và chưa tìm thấy API thời gian thực.