Sao lưu cơ sở dữ liệu Redis lên Telegram một cách tự động bằng thiết lập cronjob

Sao lưu cơ sở dữ liệu Redis lên Telegram một cách tự động bằng thiết lập cronjob

Tin ngắn hàng ngày dành cho bạn
  • Mấy hôm trước OpenAI giới thiệu Deep Research - một công cụ duyệt web để nghiên cứu và cho ra một bản tổng hợp chỉ trong vài chục phút - so với nhiều giờ làm việc đối với con người, theo như họ công bố.

    Tính năng này hiện chỉ có sẵn cho người dùng Pro. Mặc dù chưa được dùng thử, nhưng qua nhiều bài viết đều nhấn mạnh vào sự ấn tượng trước khả năng của công cụ mới này. Nếu vẫn chưa biết Deep Research làm được gì thì bạn cứ hình dung như thế này: Nói với nó "Tôi cần thông tin nghiên cứu về lượng tiêu thụ cà phê của thế giới trong năm ngoái". Thế thôi! Ngồi chờ một lúc để nó tìm kiếm và tổng hợp lại kết quả và gửi lại cho bạn một bài báo cáo chi tiết. Chà, ghê thật chứ!

    Ngay lập tức huggingface đã lên một bài viết cố gắng tái tạo lại công cụ này theo cách của họ. Chi tiết tại Open-source DeepResearch – Freeing our search agents. Và không có gì ngạc nhiên khi cả 2 đều mang hơi hướng của AI Agents.

    » Xem thêm
  • Sống đủ lâu trong thế giới Internet, bạn có thể thấy rằng mọi người ở đây khá háo hức chạy theo xu hướng và chúng lan truyền với tốc độ chóng mặt.

    Chỉ vài tháng trước, chúng ta vẫn còn kinh ngạc về trí thông minh của các mô hình ngôn ngữ lớn (LLM) có thể trả lời giống như con người, và ngay sau đó, chúng đã được cập nhật với khả năng suy nghĩ và lý luận đáng kinh ngạc. Chúng được ứng dụng rộng rãi không chỉ trong lĩnh vực lập trình. Gần đây, thuật ngữ AI Agents đã tạo nên một sự khuấy động.

    Vậy, AI Agents là gì? Trong bài viết ngắn này, tất nhiên là không thể đưa ra một định nghĩa ngắn gọn nhưng toàn diện. Bạn đọc có thể tham khảo bài viết rất chi tiết này tại đây Agents | Chip Huyền. Để dễ hình dung hơn, AI Agents có thể được coi là một người hoặc một thực thể nào đó. Bản thân các Agents được trang bị tất cả các công cụ cần thiết. Từ đó, các Agents có thể kết hợp chúng để hoàn thành một nhiệm vụ mà chúng ta giao.

    Vẫn còn hơi mơ hồ phải không? Một ví dụ thực tế là khi bạn ra lệnh cho các Agents truy cập Facebook vào lúc 8 giờ tối mỗi ngày, kiểm tra bất kỳ tin tức nổi bật nào từ bạn bè, sau đó gửi tóm tắt đến Telegram. Vậy là xong!

    » Xem thêm
  • Hôm qua đến nay, lượt truy cập tới từ Facebook tăng đột biến. Thường như thế là do ai đó chia sẻ bài viết của blog vào một nhóm nào đó.

    Cơ mà lần này là liên kết trực tiếp đến trang chủ luôn. Tò mò ghê, không biết ai chia sẻ, chia sẻ ở đâu nữa. Muốn biết để tìm hiểu "insight" ghê 🥹

    » Xem thêm

Vấn đề

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.

Cơ chế lưu trữ dữ liệu vào ổ cứng của redis

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.

Cách triển khai

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.

Tổng kết

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.

Cao cấp
Hello

Tôi & khao khát "chơi chữ"

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...
Bấm hoặc cuộn mạnh để sang bài mới