MongoDB Backup & Restore

-
MongoDB Backup & Restore

# Các phương pháp backup cho mongoDB
   -  mongdump:
      + Sử dụng trong trương hợp kích thước data không quá lớn
      + Thời gian backup và restore lâu
      + Dẽ dàng thao tác
   -  rsync and copy
      + Phù hợp với kích thước nhỏ
      + Thời gian backup lâu, nhưng restore nhanh
      + Dễ dàng cho việc thao tác
   -  Percona hot backup:
      ?
   -  Point in time use oplog .
      + Cho phép recovery tại một thời diểm mong muốn
      + Phải enable oplog => replication
      + Thời gian backup and restore nhanh
# Tim hieu command "mongodump"
-
# Quy trình thực hiệc backup : point in time use oplog
   - B1. Chuẩn bị để việc login dễ dang hơn
               $ auth="--host localhost:27017 --username akira --password secret authenticationDatabase admin"
   - B2. Thực hiện dump the oplog
            $ mongodump ${auth} -d local -c oplog.rs --query '{"ns": {"$nin": ["config.system.sessions", "config.cache.collections"]}}' --out /data/oplog_dump_full
   - B3. Thực hiên lấy timestamp
           $bsondump /data/oplog_dump_full/local/oplog.rs.bson 2>/dev/null | grep drop|  head -n  1
        {"ts":{"$timestamp":{"t":1564558677,"i":1}},"t":{"$numberLong":"4"},"h":                         
           {"$numberLong":"8756691072931811632"},"v":2,"op":"c","ns":"newdb.$cmd","ui":{"$binary":"ptLeCZA1S0m"$type":"04"},
            "wall":{"$date":"2019-07-31T07:37:57.643Z"},"o":{"drop":"city_inspections"}}
          
            => thời điểm collection drop là 1564558677
   - B4. Thực hiên restore lại tại thời điểm backup dump lần trước
               $ mongorestore --db newdb --drop /var/backups/newdb/newdb-2019-07-31-1007/newdb/
    - B5. Thực hiện restore lại tại một thời điểm mong muốn. ví dụ khi drop collection
               $bad_drop_epoch_sec=1564558677
               $mongorestore ${auth} --oplogReplay --oplogFile /data/oplog_dump_full/oplog.rs.bson --oplogLimit ${bad_drop_epoch_sec}:0 --stopOnError /tmp/fake_empty_dir

Nội dung oplog : https://kienbv.blogspot.com/2019/07/mongodb-understanding-oplog.html


Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

ActiveMQ 5.x

-
Hình ảnh
- How does ActiveMQ work ?   ActiveMQ sends message between client application -  producers   Consumers sẽ là recived and process massage. The ActiveMQ broker router each message throught one of two type of destinations:         - a queue : point-to-point         - topic : publish/subscribe - Memory and Storage    A.  Memory      ActiveMQ uses memory to store messages awaiting dispatch to consumers.      ActiveMQ also writes messages to disk , in either a message store (where persistent messages go), or a temp store (where non-persistent messages go when the broker runs out of memory to store them).     Có 2 cách thức gửi message : persistent và non-persistent             non-persistent : Each non-persistent message is stored in memory as it arrives. When the available memory is full, all messages in memory are moved to th...
Đọc thêm

Redo and undo Log in MySQL transaction

-
Hình ảnh
We all know that transactions have four characteristics: atomicity, consistency, isolation and persistence, and that the operation in a transaction is either fully executed or not done at all, which is the purpose of the transaction. Transaction isolation is achieved by locking mechanism, atomicity, consistency and persistence are guaranteed by transaction redo log and undo log. So this article will discuss several issues about redo and undo in transactions: What are redo logs and undo logs? How does redo ensure transaction durability? Is undo log an inverse process of redo log? redo log Types of Redo The redo log is used to ensure the persistence of transactions, that is, D in transaction ACID. In fact, it can be divided into the following two types: Physical Redo Log Logical Redo Log In InnoDB storage engine, In most cases, Redo is a physical log, which records the physical changes of data pages. 。 Logical Redo logs, however, do not record the actual modific...
Đọc thêm

[Kubernetes Series] - Bài 19 - Adding custom resource to Kubernetes

-
Hình ảnh
  Giới thiệu Chào các bạn tới với series về kubernetes. Đây là bài thứ 19 trong series của mình, ở bài trước chúng ta đã nói về  Advanced scheduling , ở bài này mình sẽ nói cách làm sao để ta có thể tự tạo một custom resource trong kubernetes. Bên cạnh những resource mặc định như Pod, ReplicaSet, Deployment, StatefulSet, ... Thì kubernetes cho phép chúng ta tạo thêm những custom resource để đáp ứng đúng nhu cầu của chúng ta trong dự án, từng custom resource sẽ phục vụ cho một mục đích cụ thể nào đó trong dự án của chúng ta. Ví dụ, để tạo postgres database trong kubernetes, thì đầu tiên ta sẽ định nghĩa một StatefulSet, sau đó tạo một Service cho StatefulSet này để client có thể kết nối được tới nó. Ta có thể giảm công đoạn phải tạo nhiều thứ liên quan như vậy bằng cách định nghĩa một custom resource tên là Postgres, mỗi lần ta cần postgres database thì ta chỉ cần tạo một Postgres custom resource là được, ví dụ như sau: ... kind : Postgres metadata : name : test - db stor...
Đọc thêm