Không biết trong đây có bạn nào "lỡ tay" xóa cơ sở dữ liệu đang chạy thật bao giờ chưa, chứ tôi thì chưa :D. Một phần vì tính cẩn thận, phần nữa là do tính trách nhiệm nên không dám làm ẩu. Lỡ có xóa thật thì chắc là mình cũng "bay màu" khỏi công ty mất, còn chưa nói đến khoản khắc phục hay đền bù thiệt hại sau đó. Vì lẽ đó, tôi luôn cẩn thận với từng thao tác trong cơ sở dữ liệu hoặc coi những lệnh có khả năng thay đổi dữ liệu như UPDATE, DELETE… là điều rất tối kị. Nghĩa là trước khi chạy luôn phải có phương án dự phòng như làm thế nào để khôi phục lại nếu chẳng may lỗi, hoặc phải kiểm tra đi kiểm tra lại liệu lệnh đã chính xác chưa. Thậm chí còn chạy thử nhiều lần trong môi trường phát triển.
Hiểu được tầm quan trọng của dữ liệu, đa số hệ thống đều có phương án sao lưu cơ sở dữ liệu cho mình. Việc sao lưu lúc này trở thành một điều không thể thiếu, vì nếu chẳng may xảy ra vấn đề gì đó gây mất mát dữ liệu thì còn có phương án mà khắc phục. Nói về cách triển khai sao lưu thì có rất là nhiều, tùy vào dự án và tần suất dữ liệu được ghi mà có cách sao cho hợp lý. Một số phương pháp như triển khai master slave, outbox, cluster…
2coffee.dev sử dụng redis làm cơ sở dữ liệu. Như bạn thấy đấy, nó vốn đã rất ít dữ liệu (bài viết) và lượng người vào đọc nhiều hơn lượng người vào viết (bình luận), nên sao lưu dữ liệu tương đối nhanh chóng và dễ dàng. Hàng ngày dành ít thời gian vào copy lại tệp backup thế là xong. Nhưng cái gì tự động được thì nên tự động, cho nên tôi có cách sao lưu dữ liệu hàng ngày lên Telegram.
Redis có hai cơ chế lưu giữ dữ liệu vào ổ cứng (storage) là RDB và AOF. Như bạn biết, redis lưu dữ liệu vào RAM để tăng tốc truy vấn, nhưng dữ liệu trong RAM vốn không "bền vững", nó có thể bị mất nếu như máy tính bị tắt hoặc nguồn điện bị ngắt. Do đó, redis phải có cơ chế để lưu dữ liệu vào ổ cứng. Hai phương pháp mà redis cung cấp đều có khả năng làm được điều đó chỉ khác nhau ở cơ chế hoạt động.
RDB (Redis Database) là một phương pháp lưu trữ dữ liệu vào một tệp vô cùng nhỏ gọn. Các tệp RDB hoàn hảo cho việc sao lưu. Bạn có thể thiết lập RDB tạo bản sao lưu trong mỗi 1 giờ, 24 giờ, 30 ngày… Điều này cho phép bạn dễ dàng khôi phục các phiên bản khác nhau của bộ dữ liệu trong trường hợp xảy ra sự cố. Hiểu một cách đơn giản, mỗi khi đến thời điểm thiết lập thì một tệp RDB sẽ được tạo ra thay thế tệp cũ. Sử dụng tệp này để nhanh chóng khôi phục lại dữ liệu. Ngoài ra, tốc độ phục hồi dữ liệu của RDB nhanh hơn cả AOF.
AOF (Append Only File) là một cách tiếp cận khác so với RDB. AOF hoạt động bằng cách ghi thêm lệnh làm thay đổi đổi dữ liệu nối tiếp vào một tệp .aof. Như thế, mỗi khi phục hồi dữ liệu bằng AOF thì Redis sẽ chạy lại toàn bộ lệnh đã ghi vào trong tệp. AOF tuyệt vời khi bạn muốn lưu lại dữ liệu gần như ngay lập tức. Nó bao gồm thiết lập tắt, ghi lại mỗi giây, ghi lại ở mọi truy vấn. Với tùy chọn mỗi giây, hiệu suất ghi vẫn rất tuyệt. Nếu chẳng may mất điện, bạn có thể chỉ mất dữ liệu trong một giây trước đó.
Redis có bài nói rất chi tiết cũng như cách thiết lập hai cơ chế này, bạn đọc quan tâm có thể tham khảo tại Redis persistence.
Hiện tại tôi sử dụng kết hợp cả hai cách. Thư mục để lưu trữ dữ liệu sao lưu là /data
, vì thế tất cả những gì cần làm là triển khai một cronjob "nén" thư mục /data
lại thành một tệp rồi gửi nó lên Telegram thông qua BOT. Telegram giới hạn dung lượng file nếu gửi bằng BOT là 50MB, nhưng đó là quá nhiều so với dung lượng file của tôi, vốn chỉ mất ~2MB cho file .zip. Tôi nghĩ với tốc độ này, thì cỡ 10 năm sau nữa dữ liệu mới vượt quá 50MB :D. Đùa thế thôi chứ giả sử sau này dung lượng có tăng lên thì sẽ có phương án khác thay thế, ví dụ như gửi lên Google Drive chẳng hạn.
Bạn có thể sử dụng bất kì ngôn ngữ nào mình thích để triển khai cronjob, miễn là nó khả thi. Tất cả những gì cần làm là nén thư mục /data
lại và gửi lên Telegram thông qua một cuộc gọi API duy nhất. Như tôi thì chọn Golang cho nhẹ nhàng và tiết kiệm.
Các hàm chính bao gồm zipFile
, generateFilename
, createTelegramDocument
, removeFile
.
Với zipFile
, dùng để nén thư mục /data
, hàm này nhận một tham số filename
là tên tệp sau khi nén.
func zipFile(filename string) (*os.File, error) {
var buf bytes.Buffer
err := utils.Compress(config.DIR_TO_BACKUP, &buf)
if err != nil {
return nil, err
}
fileToWrite, err := os.OpenFile(fmt.Sprintf("./%s", filename), os.O_CREATE|os.O_RDWR, os.FileMode(0777))
if err != nil {
return nil, err
}
if _, err := io.Copy(fileToWrite, &buf); err != nil {
return nil, err
}
return fileToWrite, nil
}
generateFilename
để tạo tên tệp, như tôi muốn tên tệp theo định dạng 2coffee
cộng với ngày tạo.
func generateFilename() string {
return fmt.Sprintf("estacks-%s.zip", time.Now().Format("2006-02-01"))
}
removeFile
là hàm xóa tệp nén sau khi đã gửi thành công lên Telegram để dọn dẹp bộ nhớ.
func removeFile(filePath string) error {
err := os.Remove(filePath)
return err
}
Kết hợp lại với nhau để tạo ra một TeleBackupRedis
struct, có phương thức run
để thực hiện việc sao lưu và gửi tin nhắn.
type TeleBackupRedis struct{}
func (t TeleBackupRedis) run() {
teleBot := utils.TeleBot{}
teleBot.NewBot(config.TELE_REQUEST_BOT)
generationFilename := generateFilename()
backupFilePath := fmt.Sprintf("%s%s", config.ROOT_PATH, generationFilename)
_, err := zipFile(generationFilename)
if err != nil {
fmt.Println("Error when zip file", err)
}
caption := fmt.Sprintf("Dữ liệu redis sao lưu ngày %s", time.Now().Format("2006-01-02"))
teleFile := &tb.Document{File: tb.File{FileLocal: filePath}, FileName: fileName, Caption: caption}
err = teleBot.SendChannelMessage(config.TELE_REQUEST_CHANNEL_ID, teleFile)
if err != nil {
fmt.Println("Error when send file", err)
}
err = removeFile(backupFilePath)
if err != nil {
fmt.Println("Error when remove zip file", err)
}
fmt.Println("Last running:", time.Now().Format(time.RFC3339))
}
Cuối cùng, tôi chạy hàm run
vào lúc 0 giờ 1 phút mỗi ngày.
Sao lưu dữ liệu là một việc hết sức cần thiết. Tùy vào loại cơ sở dữ liệu mà có cách triển khai khác nhau. Đối với Redis, hãy thiết lập cơ chế sao lưu cho phù hợp sau đó chỉ cần lưu trữ lại tệp tin mà redis tạo ra. Còn với tôi, có thêm một bước kết gửi tệp sao lưu lên Telegram để thuận tiện cho việc theo dõi và phục hồi sự cố sau này.
Xin chào, tôi tên là Hoài - một anh Dev kể chuyện bằng cách viết ✍️ và làm sản phẩm 🚀. Với nhiều năm kinh nghiệm lập trình, tôi đã đóng góp một phần công sức cho nhiều sản phẩm mang lại giá trị cho người dùng tại nơi đang làm việc, cũng như cho chính bản thân. Sở thích của tôi là đọc, viết, nghiên cứu... Tôi tạo ra trang Blog này với sứ mệnh mang đến những bài viết chất lượng cho độc giả của 2coffee.dev.Hãy theo dõi tôi qua các kênh LinkedIn, Facebook, Instagram, Telegram.
Bình luận (0)