主頁 > 資料庫 > 分布式檔案存盤資料庫之MongoDB備份與恢復

分布式檔案存盤資料庫之MongoDB備份與恢復

2020-11-16 10:24:16 資料庫

  前文我們聊了下mongodb的訪問控制以及用戶創建和角色分配,回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13974656.html;今天我們來了解下mongodb的備份與恢復

  為什么要備份?

  備份的目的是對資料做冗余的一種方式,它能夠讓我們在某種情況下保證最少資料的丟失;之前我們對mongodb做副本集也是對資料做冗余,但是這種在副本集上做資料冗余僅僅是針對系統故障或服務例外等一些非人為的故障發生時,保證資料服務的可用性;它不能夠避免人為的誤操作;為了使得資料的安全,將資料損失降低到最小,我們必須對資料庫周期性的做備份;

  常用備份方法

  提示:上圖主要描述了mongodb資料庫上常用備份策略,我們可以邏輯備份,邏輯備份是將資料庫中的資料匯出成陳述句,通常使用專用工具匯出和匯入來完成一次備份與恢復;其次我們也可以物理備份,簡單講物理備份就是把資料庫檔案打包,備份;恢復時直接將對應的資料庫檔案解壓恢復即可;另外一種快速物理備份的方式就是給資料拍快照,拍快照可以將資料保存為當前拍快照時的狀態;如果我們要進行恢復直接恢復快照即可;

  mongodb邏輯備份和物理備份比較

  提示:從上圖描述可以看出總體上來看物理備份效率和恢復效率要高于邏輯;物理備份效率高于邏輯備份,其主要原因是邏輯備份是通過資料庫介面將資料讀取出來,然后保存為對應格式的檔案,而物理備份只需要將資料檔案直接打包備份,不需要一條一條的讀取資料,然后寫入到其他檔案,這中間就省去了讀寫程序,所以物理備份效率高;恢復也是類似的程序,物理恢復也是省去了讀寫的程序;

  mongodb邏輯備份工具

  在mongodb中使用邏輯備份的工具有兩組,第一組是mongodump/mongorestore,使用mongodump/mongorestore這組工具來邏輯的備份資料,它備份出來的資料是BSON格式,BSON是一種二進制格式,通常無法使用文本編輯器直接打開查看其內容,對人類的可讀性較差,但它的優點是保存的檔案體積要小;使用這組命令匯出的資料,在恢復是依賴mongodb版本,不同版本匯出的BSON格式略有不同,所以恢復時,可能存在版本不同而導致恢復資料失敗的情況;另外一組是mongoexport/mongoimport,這組工具匯出的資料是json格式的資料,通常我們可以使用文本編輯器打開直接查看,對人類的可讀性較好,但體積相對BSON格式的資料要大,恢復時不依賴版本;所以跨版本備份要先查看下對應版本的兼容性,如果兼容使用mongodump/mongorestore,不兼容的話建議使用mongoexport/mongoimport;這里需要注意一點,JSON格式雖然可讀性很好,也很通用,但是它只是保留了資料部分,而沒有保留索引,賬戶等基礎資訊,在使用是應該注意;

  使用mongodump備份資料

  插入資料

> use testdb
switched to db testdb
> for(i=1;i<=1000;i++) db.test.insert({id:i,name:"test"+i,age:(i%120),classes:(i%25)})
WriteResult({ "nInserted" : 1 })
> show tables
test
> db.test.findOne()
{
        "_id" : ObjectId("5fb130da012870b3c8e3c4ad"),
        "id" : 1,
        "name" : "test1",
        "age" : 1,
        "classes" : 1
}
> db.test.count()
1000
> 

  備份所有資料庫

[root@node11 ~]# mongodump -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -o ./node12_mongodb_full_backup
2020-11-15T21:47:45.439+0800    writing admin.system.users to node12_mongodb_full_backup/admin/system.users.bson
2020-11-15T21:47:45.442+0800    done dumping admin.system.users (4 documents)
2020-11-15T21:47:45.443+0800    writing admin.system.version to node12_mongodb_full_backup/admin/system.version.bson
2020-11-15T21:47:45.447+0800    done dumping admin.system.version (2 documents)
2020-11-15T21:47:45.448+0800    writing testdb.test to node12_mongodb_full_backup/testdb/test.bson
2020-11-15T21:47:45.454+0800    done dumping testdb.test (1000 documents)
[root@node11 ~]# ls
node12_mongodb_full_backup
[root@node11 ~]# ll node12_mongodb_full_backup/
total 0
drwxr-xr-x 2 root root 128 Nov 15 21:47 admin
drwxr-xr-x 2 root root  49 Nov 15 21:47 testdb
[root@node11 ~]# tree node12_mongodb_full_backup/
node12_mongodb_full_backup/
├── admin
│   ├── system.users.bson
│   ├── system.users.metadata.json
│   ├── system.version.bson
│   └── system.version.metadata.json
└── testdb
    ├── test.bson
    └── test.metadata.json

2 directories, 6 files
[root@node11 ~]# 

  提示:-u用于指定用戶,-p指定對應用戶的密碼,-h指定資料庫地址,--authenticationDatabase 指定驗證用戶和密碼對應的資料庫 -o指定要存放備份檔案的目錄名稱;

  只備份單個testdb資料庫

[root@node11 ~]# mongodump -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb -o ./node12_testdb
2020-11-15T21:53:36.523+0800    writing testdb.test to node12_testdb/testdb/test.bson
2020-11-15T21:53:36.526+0800    done dumping testdb.test (1000 documents)
[root@node11 ~]# tree ./node12_testdb
./node12_testdb
└── testdb
    ├── test.bson
    └── test.metadata.json

1 directory, 2 files
[root@node11 ~]# 

  提示:-d用戶指定要備份的資料庫名稱;

  只備份testdb下的test集合

[root@node11 ~]# mongodump -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb -c test -o ./node12_testdb_test-collection
2020-11-15T21:55:48.217+0800    writing testdb.test to node12_testdb_test-collection/testdb/test.bson
2020-11-15T21:55:48.219+0800    done dumping testdb.test (1000 documents)
[root@node11 ~]# tree ./node12_testdb_test-collection
./node12_testdb_test-collection
└── testdb
    ├── test.bson
    └── test.metadata.json

1 directory, 2 files
[root@node11 ~]# 

  提示:-c用于指定要備份的集合(collection)名稱;

  壓縮備份testdb庫

[root@node11 ~]# mongodump -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb --gzip -o ./node12_mongodb_testdb-gzip 
2020-11-15T22:00:52.268+0800    writing testdb.test to node12_mongodb_testdb-gzip/testdb/test.bson.gz
2020-11-15T22:00:52.273+0800    done dumping testdb.test (1000 documents)
[root@node11 ~]# tree ./node12_mongodb_testdb-gzip
./node12_mongodb_testdb-gzip
└── testdb
    ├── test.bson.gz
    └── test.metadata.json.gz

1 directory, 2 files
[root@node11 ~]# 

  提示:可以看到使用壓縮,只需要加上--gzip選項即可,備份出來的資料就是.gz后綴結尾的壓縮檔案;

  壓縮備份testdb庫下的test集合

[root@node11 ~]# mongodump -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb -c test --gzip -o ./node12_mongodb_testdb-test-gzip 
2020-11-15T22:01:31.492+0800    writing testdb.test to node12_mongodb_testdb-test-gzip/testdb/test.bson.gz
2020-11-15T22:01:31.500+0800    done dumping testdb.test (1000 documents)
[root@node11 ~]# tree ./node12_mongodb_testdb-test-gzip
./node12_mongodb_testdb-test-gzip
└── testdb
    ├── test.bson.gz
    └── test.metadata.json.gz

1 directory, 2 files
[root@node11 ~]# 

  使用mongorestore恢復資料

  在node12上洗掉testdb

> db
testdb
> db.dropDatabase()
{ "dropped" : "testdb", "ok" : 1 }
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
> 

  全量恢復所有資料庫

[root@node11 ~]# mongorestore -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin --drop ./node12_mongodb_full_backup
2020-11-15T22:07:35.465+0800    preparing collections to restore from
2020-11-15T22:07:35.467+0800    reading metadata for testdb.test from node12_mongodb_full_backup/testdb/test.metadata.json
2020-11-15T22:07:35.475+0800    restoring testdb.test from node12_mongodb_full_backup/testdb/test.bson
2020-11-15T22:07:35.486+0800    no indexes to restore
2020-11-15T22:07:35.486+0800    finished restoring testdb.test (1000 documents, 0 failures)
2020-11-15T22:07:35.486+0800    restoring users from node12_mongodb_full_backup/admin/system.users.bson
2020-11-15T22:07:35.528+0800    1000 document(s) restored successfully. 0 document(s) failed to restore.
[root@node11 ~]#

  提示:--drop用于指定,恢復是如果對應資料庫或者colleciton存在,則先洗掉然后在恢復,這樣做的目的是保證恢復的資料和備份的資料一致;

  驗證:登錄192.168.0.52:27017查看對應testdb資料庫是否恢復?

[root@node11 ~]# mongo -utom -p123456 192.168.0.52:27017/admin 
MongoDB shell version v4.4.1
connecting to: mongodb://192.168.0.52:27017/admin?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("af96cb64-a2a4-4d59-b60a-86ccbbe77e3e") }
MongoDB server version: 4.4.1
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
        https://docs.mongodb.com/
Questions? Try the MongoDB Developer Community Forums
        https://community.mongodb.com
---
The server generated these startup warnings when booting: 
        2020-11-15T20:42:23.774+08:00: ***** SERVER RESTARTED *****
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. We suggest setting it to 'never'
---
---
        Enable MongoDB's free cloud-based monitoring service, which will then receive and display
        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you
        and anyone you share the URL with. MongoDB may use this information to make product
        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()
        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
testdb  0.000GB
> use testdb
switched to db testdb
> show collections
test
> db.test.count()
1000
> db.test.findOne()
{
        "_id" : ObjectId("5fb130da012870b3c8e3c4ad"),
        "id" : 1,
        "name" : "test1",
        "age" : 1,
        "classes" : 1
}
> 

  恢復單個庫

  洗掉testdb庫

> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
testdb  0.000GB
> use testdb
switched to db testdb
> db.dropDatabase()
{ "dropped" : "testdb", "ok" : 1 }
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
> 

  使用mongorestore恢復testdb庫

[root@node11 ~]# mongorestore -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb --drop ./node12_testdb/testdb/
2020-11-15T22:29:03.718+0800    The --db and --collection flags are deprecated for this use-case; please use --nsInclude instead, i.e. with --nsInclude=${DATABASE}.${COLLECTION}
2020-11-15T22:29:03.718+0800    building a list of collections to restore from node12_testdb/testdb dir
2020-11-15T22:29:03.719+0800    reading metadata for testdb.test from node12_testdb/testdb/test.metadata.json
2020-11-15T22:29:03.736+0800    restoring testdb.test from node12_testdb/testdb/test.bson
2020-11-15T22:29:03.755+0800    no indexes to restore
2020-11-15T22:29:03.755+0800    finished restoring testdb.test (1000 documents, 0 failures)
2020-11-15T22:29:03.755+0800    1000 document(s) restored successfully. 0 document(s) failed to restore.
[root@node11 ~]# mongo -utom -p123456 192.168.0.52:27017/admin 
MongoDB shell version v4.4.1
connecting to: mongodb://192.168.0.52:27017/admin?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("f5e73939-bb87-4d45-bf80-9ff1e7f6f15d") }
MongoDB server version: 4.4.1
---
The server generated these startup warnings when booting: 
        2020-11-15T20:42:23.774+08:00: ***** SERVER RESTARTED *****
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. We suggest setting it to 'never'
---
---
        Enable MongoDB's free cloud-based monitoring service, which will then receive and display
        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you
        and anyone you share the URL with. MongoDB may use this information to make product
        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()
        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
testdb  0.000GB
> use testdb
switched to db testdb
> show tables
test
> db.test.count()
1000
> db.test.findOne()
{
        "_id" : ObjectId("5fb130da012870b3c8e3c4ad"),
        "id" : 1,
        "name" : "test1",
        "age" : 1,
        "classes" : 1
}
> 

  恢復單個集合

  洗掉testdb下的test集合

> db
testdb
> show collections
test
> db.test.drop()
true
> show collections
> 

  使用mongorestore恢復testdb下的test集合

[root@node11 ~]# mongorestore -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb -c test --drop ./node12_testdb_test-collection/testdb/test.bson 
2020-11-15T22:36:15.615+0800    checking for collection data in node12_testdb_test-collection/testdb/test.bson
2020-11-15T22:36:15.616+0800    reading metadata for testdb.test from node12_testdb_test-collection/testdb/test.metadata.json
2020-11-15T22:36:15.625+0800    restoring testdb.test from node12_testdb_test-collection/testdb/test.bson
2020-11-15T22:36:15.669+0800    no indexes to restore
2020-11-15T22:36:15.669+0800    finished restoring testdb.test (1000 documents, 0 failures)
2020-11-15T22:36:15.669+0800    1000 document(s) restored successfully. 0 document(s) failed to restore.
[root@node11 ~]# mongo -utom -p123456 192.168.0.52:27017/admin                                              MongoDB shell version v4.4.1
connecting to: mongodb://192.168.0.52:27017/admin?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("27d15d9e-3fdf-4efc-b871-1ec6716e51e3") }
MongoDB server version: 4.4.1
---
The server generated these startup warnings when booting: 
        2020-11-15T20:42:23.774+08:00: ***** SERVER RESTARTED *****
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. We suggest setting it to 'never'
---
---
        Enable MongoDB's free cloud-based monitoring service, which will then receive and display
        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you
        and anyone you share the URL with. MongoDB may use this information to make product
        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()
        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
testdb  0.000GB
> use testdb
switched to db testdb
> show collections
test
> db.test.count()
1000
> db.test.findOne()
{
        "_id" : ObjectId("5fb130da012870b3c8e3c4ad"),
        "id" : 1,
        "name" : "test1",
        "age" : 1,
        "classes" : 1
}
> 

  使用壓縮檔案恢復資料庫

  洗掉testdb資料庫

> db
testdb
> db.dropDatabase()
{ "dropped" : "testdb", "ok" : 1 }
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
> 

  使用mongorestore工具加載壓縮檔案恢復資料庫

[root@node11 ~]# mongorestore -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb --gzip --drop ./node12_mongodb_testdb-gzip/testdb/
2020-11-15T22:39:55.313+0800    The --db and --collection flags are deprecated for this use-case; please use --nsInclude instead, i.e. with --nsInclude=${DATABASE}.${COLLECTION}
2020-11-15T22:39:55.313+0800    building a list of collections to restore from node12_mongodb_testdb-gzip/testdb dir
2020-11-15T22:39:55.314+0800    reading metadata for testdb.test from node12_mongodb_testdb-gzip/testdb/test.metadata.json.gz
2020-11-15T22:39:55.321+0800    restoring testdb.test from node12_mongodb_testdb-gzip/testdb/test.bson.gz
2020-11-15T22:39:55.332+0800    no indexes to restore
2020-11-15T22:39:55.332+0800    finished restoring testdb.test (1000 documents, 0 failures)
2020-11-15T22:39:55.332+0800    1000 document(s) restored successfully. 0 document(s) failed to restore.
[root@node11 ~]# mongo -utom -p123456 192.168.0.52:27017/admin                                              MongoDB shell version v4.4.1
connecting to: mongodb://192.168.0.52:27017/admin?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("73d98c33-f8f7-40e3-89bd-fda8c702e407") }
MongoDB server version: 4.4.1
---
The server generated these startup warnings when booting: 
        2020-11-15T20:42:23.774+08:00: ***** SERVER RESTARTED *****
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. We suggest setting it to 'never'
---
---
        Enable MongoDB's free cloud-based monitoring service, which will then receive and display
        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you
        and anyone you share the URL with. MongoDB may use this information to make product
        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()
        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
testdb  0.000GB
> use testdb
switched to db testdb
> show collections
test
> db.test.count()
1000
> db.test.findOne()
{
        "_id" : ObjectId("5fb130da012870b3c8e3c4ad"),
        "id" : 1,
        "name" : "test1",
        "age" : 1,
        "classes" : 1
}
> 

  提示:使用mongorestore恢復單個庫使用-d選線指定要恢復的資料庫,恢復單個集合使用-c指定集合名稱即可,以及使用壓縮檔案恢復加上對應的--gzip選項即可,總之,備份時用的選項在恢復時也應當使用對應的選項,這個mongodump備份使用的選項沒有特別的不同;

  使用mongoexport備份資料

  新建peoples資料庫,并向peoples_info集合中插入資料

> use peoples
switched to db peoples
> for(i=1;i<=10000;i++) db.peoples_info.insert({id:i,name:"peoples"+i,age:(i%120),classes:(i%25)})
WriteResult({ "nInserted" : 1 })
> show dbs
admin    0.000GB
config   0.000GB
local    0.000GB
peoples  0.000GB
testdb   0.000GB
> db.peoples_info.count()
10000
> db.peoples_info.findOne()
{
        "_id" : ObjectId("5fb13f35012870b3c8e3c895"),
        "id" : 1,
        "name" : "peoples1",
        "age" : 1,
        "classes" : 1
}
> 

  使用mongoexport工具peoples庫下的peoples_info集合

[root@node11 ~]# mongoexport -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d peoples -c peoples_info --type json -o ./peoples-peopels_info.json
2020-11-15T22:54:18.287+0800    connected to: mongodb://192.168.0.52:27017/
2020-11-15T22:54:18.370+0800    exported 10000 records
[root@node11 ~]# ll
total 1004
-rw-r--r-- 1 root root 1024609 Nov 15 22:54 peoples-peopels_info.json
[root@node11 ~]# head -n 1 peoples-peopels_info.json 
{"_id":{"$oid":"5fb13f35012870b3c8e3c895"},"id":1.0,"name":"peoples1","age":1.0,"classes":1.0}
[root@node11 ~]# 

  提示:使用--type可以指定匯出資料檔案的格式,默認是json格式,當然也可以指定csv格式;這里還需要注意mongoexport這個工具匯出資料必須要指定資料庫和對應集合,它不能直接對整個資料庫下的所有集合做匯出;只能單個單個的導;

  匯出csv格式的資料檔案

[root@node11 ~]# mongoexport -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d peoples -c peoples_info --type csv -o ./peoples-peopels_info.csv
2020-11-15T22:58:30.495+0800    connected to: mongodb://192.168.0.52:27017/
2020-11-15T22:58:30.498+0800    Failed: CSV mode requires a field list
[root@node11 ~]# mongoexport -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d peoples -c peoples_info --type csv -f id,name,age -o ./peoples-peopels_info.csv  
2020-11-15T22:59:26.090+0800    connected to: mongodb://192.168.0.52:27017/
2020-11-15T22:59:26.143+0800    exported 10000 records
[root@node11 ~]# head -n 1 ./peoples-peopels_info.csv
id,name,age
[root@node11 ~]# head  ./peoples-peopels_info.csv    
id,name,age
1,peoples1,1
2,peoples2,2
3,peoples3,3
4,peoples4,4
5,peoples5,5
6,peoples6,6
7,peoples7,7
8,peoples8,8
9,peoples9,9
[root@node11 ~]# 

  提示:匯出指定格式為csv時,必須用-f選項指定匯出的欄位名稱,分別用逗號隔開;

  將資料匯入到node11的mongodb上

  匯入json格式資料

[root@node11 ~]# systemctl start mongod.service 
[root@node11 ~]# ss -tnl
State      Recv-Q Send-Q         Local Address:Port                        Peer Address:Port              
LISTEN     0      128                        *:22                                     *:*                  
LISTEN     0      100                127.0.0.1:25                                     *:*                  
LISTEN     0      128                127.0.0.1:27017                                  *:*                  
LISTEN     0      128                       :::22                                    :::*                  
LISTEN     0      100                      ::1:25                                    :::*                  
[root@node11 ~]# ll
total 1200
-rw-r--r-- 1 root root  198621 Nov 15 22:59 peoples-peopels_info.csv
-rw-r--r-- 1 root root 1024609 Nov 15 22:54 peoples-peopels_info.json
[root@node11 ~]# mongoimport  -d testdb -c peoples_info --drop peoples-peopels_info.json 
2020-11-15T23:05:03.004+0800    connected to: mongodb://localhost/
2020-11-15T23:05:03.005+0800    dropping: testdb.peoples_info
2020-11-15T23:05:03.186+0800    10000 document(s) imported successfully. 0 document(s) failed to import.
[root@node11 ~]#

  提示:匯入資料時可以任意指定資料庫以及集合名稱;

  驗證:查看node11上的testdb庫下是否有peoples_info集合?集合中是否有資料呢?

[root@node11 ~]# mongo
MongoDB shell version v4.4.1
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("4e3a00b0-8367-4b3a-9a77-e61d03bb1b3d") }
MongoDB server version: 4.4.1
---
The server generated these startup warnings when booting: 
        2020-11-15T23:03:39.669+08:00: ***** SERVER RESTARTED *****
        2020-11-15T23:03:40.681+08:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
        2020-11-15T23:03:40.681+08:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
        2020-11-15T23:03:40.681+08:00: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. We suggest setting it to 'never'
---
---
        Enable MongoDB's free cloud-based monitoring service, which will then receive and display
        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you
        and anyone you share the URL with. MongoDB may use this information to make product
        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()
        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
testdb  0.000GB
> use testdb
switched to db testdb
> show collections
peoples_info
> db.peoples_info.count()
10000
> db.peoples_info.findOne()
{
        "_id" : ObjectId("5fb13f35012870b3c8e3c895"),
        "id" : 1,
        "name" : "peoples1",
        "age" : 1,
        "classes" : 1
}
> 

  匯入csv格式資料到node12上的testdb庫下的test1集合中去

[root@node11 ~]# mongoimport -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin -d testdb -c test1 --type csv --headerline --file ./peoples-peopels_info.csv 
2020-11-15T23:11:42.595+0800    connected to: mongodb://192.168.0.52:27017/
2020-11-15T23:11:42.692+0800    10000 document(s) imported successfully. 0 document(s) failed to import.
[root@node11 ~]#

  提示:匯入csv格式的資料需要明確指定型別為csv,然后使用--headerline指定不匯入第一行列名,--file使用用于指定csv格式檔案的名稱;

  驗證:登錄node12的mongodb,查看testdb庫下是否有test1集合?對應集合是否有資料呢?

[root@node11 ~]# mongo -utom -p123456 192.168.0.52:27017/admin
MongoDB shell version v4.4.1
connecting to: mongodb://192.168.0.52:27017/admin?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("72a07318-ac04-46f9-a310-13b1241d2f77") }
MongoDB server version: 4.4.1
---
The server generated these startup warnings when booting: 
        2020-11-15T20:42:23.774+08:00: ***** SERVER RESTARTED *****
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
        2020-11-15T20:42:29.198+08:00: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. We suggest setting it to 'never'
---
---
        Enable MongoDB's free cloud-based monitoring service, which will then receive and display
        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you
        and anyone you share the URL with. MongoDB may use this information to make product
        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()
        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
> show dbs
admin    0.000GB
config   0.000GB
local    0.000GB
peoples  0.000GB
testdb   0.000GB
> use testdb
switched to db testdb
> show collections
test
test1
> db.test1.count()
10000
> db.test1.findOne()
{
        "_id" : ObjectId("5fb1452ef09b563b65405f7c"),
        "id" : 1,
        "name" : "peoples1",
        "age" : 1
}
> 

  提示:可以看到testdb庫下的test1結合就沒有classes欄位資訊了,這是因為我們匯出資料時沒有指定要匯出classes欄位,所以匯入的資料當然也是沒有classes欄位資訊;以上就是mongodump/mongorestore和mongoexport/mongoimport工具的使用和測驗;

  全量備份加oplog實作恢復mongodb資料庫到指定時間點的資料

  在mongodump備份資料時,我們可以使用--oplog選項來記錄開始dump資料到dump資料結束后的中間一段時間mongodb資料發生變化的日志;我們知道oplog就是用來記錄mongodb中的集合寫操作的日志,類似mysql中的binlog;我們可以使用oplog將備份期間發生變化的資料一起恢復,這樣恢復出來的資料才是我們真正備份時的所有資料;

  模擬備份時,一邊插入資料,一邊備份資料

test_replset:PRIMARY> use testdb
switched to db testdb
test_replset:PRIMARY> for(i=1;i<=1000000;i++) db.test3.insert({id:i,name:"test3-oplog"+i,commit:"test3"+i})

  

  在另外一邊同時對資料做備份

[root@node11 ~]# rm -rf *
[root@node11 ~]# ll
total 0
[root@node11 ~]#  mongodump -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin --oplog -o ./alldatabase
2020-11-15T23:51:40.606+0800    writing admin.system.users to alldatabase/admin/system.users.bson
2020-11-15T23:51:40.606+0800    done dumping admin.system.users (4 documents)
2020-11-15T23:51:40.607+0800    writing admin.system.version to alldatabase/admin/system.version.bson
2020-11-15T23:51:40.608+0800    done dumping admin.system.version (2 documents)
2020-11-15T23:51:40.609+0800    writing testdb.test1 to alldatabase/testdb/test1.bson
2020-11-15T23:51:40.611+0800    writing testdb.test3 to alldatabase/testdb/test3.bson
2020-11-15T23:51:40.612+0800    writing testdb.test to alldatabase/testdb/test.bson
2020-11-15T23:51:40.612+0800    writing peoples.peoples_info to alldatabase/peoples/peoples_info.bson
2020-11-15T23:51:40.696+0800    done dumping peoples.peoples_info (10000 documents)
2020-11-15T23:51:40.761+0800    done dumping testdb.test3 (54167 documents)
2020-11-15T23:51:40.803+0800    done dumping testdb.test (31571 documents)
2020-11-15T23:51:40.966+0800    done dumping testdb.test1 (79830 documents)
2020-11-15T23:51:40.972+0800    writing captured oplog to 
2020-11-15T23:51:40.980+0800            dumped 916 oplog entries
[root@node11 ~]# ll
total 0
drwxr-xr-x 5 root root 66 Nov 15 23:51 alldatabase
[root@node11 ~]# tree alldatabase/
alldatabase/
├── admin
│   ├── system.users.bson
│   ├── system.users.metadata.json
│   ├── system.version.bson
│   └── system.version.metadata.json
├── oplog.bson
├── peoples
│   ├── peoples_info.bson
│   └── peoples_info.metadata.json
└── testdb
    ├── test1.bson
    ├── test1.metadata.json
    ├── test3.bson
    ├── test3.metadata.json
    ├── test.bson
    └── test.metadata.json

3 directories, 13 files
[root@node11 ~]# 

  提示:可以看到現在備份就多了一個oplog.bson;

  查看oplog.bson中第一行記錄的資料和第二行記錄的資料

[root@node11 ~]# ls
alldatabase
[root@node11 ~]# cd alldatabase/
[root@node11 alldatabase]# ls
admin  oplog.bson  peoples  testdb
[root@node11 alldatabase]# bsondump oplog.bson > /tmp/oplog.bson.tmp
2020-11-15T23:55:04.801+0800    916 objects found
[root@node11 alldatabase]# head -n 1 /tmp/oplog.bson.tmp
{"op":"i","ns":"testdb.test3","ui":{"$binary":{"base64":"7PmE47CASOiQZt5sMGDZKw==","subType":"04"}},"o":{"_id":{"$oid":"5fb14e8c01fff06b2b50a2ac"},"id":{"$numberDouble":"54101.0"},"name":"test3-oplog54101","commit":"test354101"},"ts":{"$timestamp":{"t":1605455500,"i":1880}},"t":{"$numberLong":"1"},"wall":{"$date":{"$numberLong":"1605455500608"}},"v":{"$numberLong":"2"}}
[root@node11 alldatabase]# tail -n 1 /tmp/oplog.bson.tmp
{"op":"i","ns":"testdb.test3","ui":{"$binary":{"base64":"7PmE47CASOiQZt5sMGDZKw==","subType":"04"}},"o":{"_id":{"$oid":"5fb14e8c01fff06b2b50a63f"},"id":{"$numberDouble":"55016.0"},"name":"test3-oplog55016","commit":"test355016"},"ts":{"$timestamp":{"t":1605455500,"i":2795}},"t":{"$numberLong":"1"},"wall":{"$date":{"$numberLong":"1605455500961"}},"v":{"$numberLong":"2"}}
[root@node11 alldatabase]# 

  提示:可以看到oplog中記錄了id為54101-55016資料,這也就說明了我們開始dump資料時,到dump結束后,資料一致在發生變化,所以我們dump下來的資料是一個中間狀態的資料;這里需要說明一點使用mongodump --oplog選項時,不能指定庫,因為oplog是對所有庫,而不針對某個庫記錄,所以--oplog只有在備份所有資料庫生效;

  洗掉testdb資料庫,然后基于我們剛才dump的資料做資料恢復

test_replset:PRIMARY> show dbs
admin    0.000GB
config   0.000GB
local    0.014GB
peoples  0.000GB
testdb   0.019GB
test_replset:PRIMARY> use testdb
switched to db testdb
test_replset:PRIMARY> db.dropDatabase()
{
        "dropped" : "testdb",
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1605456134, 4),
                "signature" : {
                        "hash" : BinData(0,"cRAdXcUj5c48Q77rCJ1DeeF10u8="),
                        "keyId" : NumberLong("6895378399531892740")
                }
        },
        "operationTime" : Timestamp(1605456134, 4)
}
test_replset:PRIMARY> show dbs
admin    0.000GB
config   0.000GB
local    0.014GB
peoples  0.000GB
test_replset:PRIMARY> 

  使用mongorestore恢復資料

[root@node11 ~]# ls
alldatabase
[root@node11 ~]# mongorestore -utom -p123456 -h 192.168.0.52:27017 --authenticationDatabase admin --oplogReplay --drop ./alldatabase/
2020-11-16T00:06:32.049+0800    preparing collections to restore from
2020-11-16T00:06:32.053+0800    reading metadata for testdb.test1 from alldatabase/testdb/test1.metadata.json
2020-11-16T00:06:32.060+0800    reading metadata for testdb.test3 from alldatabase/testdb/test3.metadata.json
2020-11-16T00:06:32.064+0800    reading metadata for testdb.test from alldatabase/testdb/test.metadata.json
2020-11-16T00:06:32.064+0800    restoring testdb.test1 from alldatabase/testdb/test1.bson
2020-11-16T00:06:32.074+0800    restoring testdb.test3 from alldatabase/testdb/test3.bson
2020-11-16T00:06:32.093+0800    restoring testdb.test from alldatabase/testdb/test.bson
2020-11-16T00:06:32.098+0800    reading metadata for peoples.peoples_info from alldatabase/peoples/peoples_info.metadata.json
2020-11-16T00:06:32.110+0800    restoring peoples.peoples_info from alldatabase/peoples/peoples_info.bson
2020-11-16T00:06:32.333+0800    no indexes to restore
2020-11-16T00:06:32.333+0800    finished restoring peoples.peoples_info (10000 documents, 0 failures)
2020-11-16T00:06:32.766+0800    no indexes to restore
2020-11-16T00:06:32.766+0800    finished restoring testdb.test (31571 documents, 0 failures)
2020-11-16T00:06:33.023+0800    no indexes to restore
2020-11-16T00:06:33.023+0800    finished restoring testdb.test3 (54167 documents, 0 failures)
2020-11-16T00:06:33.370+0800    no indexes to restore
2020-11-16T00:06:33.370+0800    finished restoring testdb.test1 (79830 documents, 0 failures)
2020-11-16T00:06:33.370+0800    restoring users from alldatabase/admin/system.users.bson
2020-11-16T00:06:33.416+0800    replaying oplog
2020-11-16T00:06:33.850+0800    applied 916 oplog entries
2020-11-16T00:06:33.850+0800    175568 document(s) restored successfully. 0 document(s) failed to restore.
[root@node11 ~]# 

  提示:恢復是需要使用--oplogReplay選項來指定重放oplog.bson中的內容;從上面恢復日志可以看到從oplog中恢復了916條資料;也就是說從dump資料開始的那一刻開始到dump結束期間有916條資料發生變化;

  驗證:連接資料庫,看看對應的testdb庫下的test3集合恢復了多少條資料?

test_replset:PRIMARY> use testdb
switched to db testdb
test_replset:PRIMARY> show tables
test
test1
test3
test_replset:PRIMARY> db.test3.count()
55016
test_replset:PRIMARY> 

  提示:可以看到test3集合恢復了55016條資料;剛好可以和oplog.bson中的最后一條資料的id對應起來;

  備份oplog.rs實作指定恢復到某個時間節點

  為了演示容易看出效果,我這里從新將資料庫清空,關閉了認證功能

  插入資料

test_replset:PRIMARY> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
test_replset:PRIMARY> use testdb
switched to db testdb
test_replset:PRIMARY> for(i=1;i<=100000;i++) db.test.insert({id:(i+10000),name:"test-oplog"+i,commit:"test"+i})

  同時備份資料,這次不加--oplog選項

[root@node11 ~]# ll
total 0
[root@node11 ~]# mongodump -h node12:27017  -o ./alldatabase
2020-11-16T09:38:00.921+0800	writing admin.system.version to alldatabase/admin/system.version.bson
2020-11-16T09:38:00.923+0800	done dumping admin.system.version (1 document)
2020-11-16T09:38:00.924+0800	writing testdb.test to alldatabase/testdb/test.bson
2020-11-16T09:38:00.960+0800	done dumping testdb.test (16377 documents)
[root@node11 ~]# ll 
total 0
drwxr-xr-x 4 root root 33 Nov 16 09:38 alldatabase
[root@node11 ~]# tree ./alldatabase
./alldatabase
├── admin
│   ├── system.version.bson
│   └── system.version.metadata.json
└── testdb
    ├── test.bson
    └── test.metadata.json

2 directories, 4 files
[root@node11 ~]# 

  提示:我們在一邊插入資料,一邊備份資料,從上面的被日志可以看到,我們備份testdb庫下的test集合16377條資料,很顯然這不是testdb.test集合的所有資料;我們備份的只是部分資料;正常情況等資料插入完成以后,testdb.test集合應該有100000條資料;

  驗證:查看testdb.test集合是否有100000條資料?

test_replset:PRIMARY> db
testdb
test_replset:PRIMARY> show collections
test
test_replset:PRIMARY> db.test.count()
100000
test_replset:PRIMARY> 

  模擬誤操作洗掉testdb.test集合所有資料

test_replset:PRIMARY> db
testdb
test_replset:PRIMARY> show collections
test
test_replset:PRIMARY> db.test.remove({})
WriteResult({ "nRemoved" : 100000 })
test_replset:PRIMARY> 

  提示:現在我們不小心把testdb.test集合給洗掉了,現在如果用之前的備份肯定只能恢復部分資料,怎么辦呢?我們這個時候可以匯出oplog.rs集合,這個集合就是oplog存放資料的集合,它位于local庫下;

  備份local庫中的oplog.rs集合

[root@node11 ~]# ll
total 0
drwxr-xr-x 4 root root 33 Nov 16 09:38 alldatabase
[root@node11 ~]# mongodump -h node12:27017 -d local -c oplog.rs -o ./oplog-rs
2020-11-16T09:43:38.594+0800	writing local.oplog.rs to oplog-rs/local/oplog.rs.bson
2020-11-16T09:43:38.932+0800	done dumping local.oplog.rs (200039 documents)
[root@node11 ~]# ll
total 0
drwxr-xr-x 4 root root 33 Nov 16 09:38 alldatabase
drwxr-xr-x 3 root root 19 Nov 16 09:43 oplog-rs
[root@node11 ~]# tree ./oplog-rs
./oplog-rs
└── local
    ├── oplog.rs.bson
    └── oplog.rs.metadata.json

1 directory, 2 files
[root@node11 ~]# 

  提示:oplog存放在local庫下的oplog.rs集合中,以上操作就是備份所有的oplog;現在我們準備好一個oplog,但是現在還不能直接恢復,如果直接恢復,我們的誤操作也會跟著一起重放沒有任何意義,現在我們需要找到誤操作的時間點,然后在恢復;

  在oplog中查找誤洗掉的時間

[root@node11 ~]# bsondump oplog-rs/local/oplog.rs.bson |egrep "\"op\":\"d\""|head -n 3
{"op":"d","ns":"testdb.test","ui":{"$binary":{"base64":"C3FH7g1eSWWwHd2AZEJhiw==","subType":"04"}},"o":{"_id":{"$oid":"5fb1d7eb25343e833cbaa146"}},"ts":{"$timestamp":{"t":1605490915,"i":1}},"t":{"$numberLong":"1"},"wall":{"$date":{"$numberLong":"1605490915399"}},"v":{"$numberLong":"2"}}
{"op":"d","ns":"testdb.test","ui":{"$binary":{"base64":"C3FH7g1eSWWwHd2AZEJhiw==","subType":"04"}},"o":{"_id":{"$oid":"5fb1d7eb25343e833cbaa147"}},"ts":{"$timestamp":{"t":1605490915,"i":2}},"t":{"$numberLong":"1"},"wall":{"$date":{"$numberLong":"1605490915400"}},"v":{"$numberLong":"2"}}
{"op":"d","ns":"testdb.test","ui":{"$binary":{"base64":"C3FH7g1eSWWwHd2AZEJhiw==","subType":"04"}},"o":{"_id":{"$oid":"5fb1d7eb25343e833cbaa148"}},"ts":{"$timestamp":{"t":1605490915,"i":3}},"t":{"$numberLong":"1"},"wall":{"$date":{"$numberLong":"1605490915400"}},"v":{"$numberLong":"2"}}
2020-11-16T09:46:20.363+0800	100074 objects found
2020-11-16T09:46:20.363+0800	write /dev/stdout: broken pipe
[root@node11 ~]# 

  提示:我們要恢復到第一次洗掉前的資料,我們就選擇第一條日志中的$timestamp欄位中的{"t":1605490915,"i":1};這個就是我們第一次洗掉的時間資訊;

  復制oplog.rs.bson到備份的資料目錄為oplog.bson,模擬出使用--oplog選項備份的備份環境

[root@node11 ~]# cp ./oplog-rs/local/oplog.rs.bson ./alldatabase/oplog.bson
[root@node11 ~]# 

  在使用mongorestore進行恢復資料,指定恢復到第一次洗掉資料前的時間點所有資料

[root@node11 ~]# mongorestore -h node12:27017 --oplogReplay  --oplogLimit "1605490915:1" --drop ./alldatabase/
2020-11-16T09:51:19.658+0800	preparing collections to restore from
2020-11-16T09:51:19.668+0800	reading metadata for testdb.test from alldatabase/testdb/test.metadata.json
2020-11-16T09:51:19.693+0800	restoring testdb.test from alldatabase/testdb/test.bson
2020-11-16T09:51:19.983+0800	no indexes to restore
2020-11-16T09:51:19.983+0800	finished restoring testdb.test (16377 documents, 0 failures)
2020-11-16T09:51:19.983+0800	replaying oplog
2020-11-16T09:51:22.657+0800	oplog  537KB
2020-11-16T09:51:25.657+0800	oplog  1.12MB
2020-11-16T09:51:28.657+0800	oplog  1.72MB
2020-11-16T09:51:31.657+0800	oplog  2.32MB
2020-11-16T09:51:34.657+0800	oplog  2.92MB
2020-11-16T09:51:37.657+0800	oplog  3.51MB
2020-11-16T09:51:40.657+0800	oplog  4.11MB
2020-11-16T09:51:43.657+0800	oplog  4.71MB
2020-11-16T09:51:46.657+0800	oplog  5.30MB
2020-11-16T09:51:49.657+0800	oplog  5.90MB
2020-11-16T09:51:52.657+0800	oplog  6.46MB
2020-11-16T09:51:55.657+0800	oplog  7.04MB
2020-11-16T09:51:58.657+0800	oplog  7.61MB
2020-11-16T09:52:01.657+0800	oplog  8.20MB
2020-11-16T09:52:04.657+0800	oplog  8.77MB
2020-11-16T09:52:07.657+0800	oplog  9.36MB
2020-11-16T09:52:10.657+0800	oplog  9.96MB
2020-11-16T09:52:13.657+0800	oplog  10.6MB
2020-11-16T09:52:16.656+0800	oplog  11.2MB
2020-11-16T09:52:19.657+0800	oplog  11.8MB
2020-11-16T09:52:22.657+0800	oplog  12.4MB
2020-11-16T09:52:25.657+0800	oplog  13.0MB
2020-11-16T09:52:28.657+0800	oplog  13.6MB
2020-11-16T09:52:31.657+0800	oplog  14.2MB
2020-11-16T09:52:34.657+0800	oplog  14.8MB
2020-11-16T09:52:37.657+0800	oplog  15.4MB
2020-11-16T09:52:40.657+0800	oplog  16.0MB
2020-11-16T09:52:43.657+0800	oplog  16.6MB
2020-11-16T09:52:46.657+0800	oplog  17.2MB
2020-11-16T09:52:49.657+0800	oplog  17.8MB
2020-11-16T09:52:52.433+0800	skipping applying the config.system.sessions namespace in applyOps
2020-11-16T09:52:52.433+0800	applied 100008 oplog entries
2020-11-16T09:52:52.433+0800	oplog  18.4MB
2020-11-16T09:52:52.433+0800	16377 document(s) restored successfully. 0 document(s) failed to restore.
[root@node11 ~]# 

  提示:從上面的恢復日志可以看到oplog恢復了100008條,備份的16377條資料也成功恢復;

  驗證:查看testdb.test集合是否恢復?資料恢復了多少條呢?

test_replset:PRIMARY> show dbs
admin   0.000GB
config  0.000GB
local   0.010GB
testdb  0.004GB
test_replset:PRIMARY> use testdb
switched to db testdb
test_replset:PRIMARY> show tables
test
test_replset:PRIMARY> db.test.count()
100000
test_replset:PRIMARY> 

  提示:可以看到testdb.test集合恢復了100000條資料;

  以上就是mongodb的備份與恢復相關話題的實踐;

轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/219411.html

標籤:其他

上一篇:分布式檔案存盤資料庫之MongoDB備份與恢復

下一篇:POSTGRESQL 用戶怎么亂糟糟,出自其他DB的評論, 與SCHEMA 移魂大法

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀:**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題,由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視,實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶,一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀:**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高,采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐,遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀:**滴滴資料通道引擎承載著全公司的資料同步,為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加,資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程,遇到的問題以及今后的規劃。 #1. 背景 資料,對于任何一家互聯網公司來說都是非常重要的資產,公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀:**深耕人工智能領域,致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎,這次獲獎的專案是什么呢?一起來看看詳細報道吧! 近日,由國際計算語言學協會ACL(The Association for Computational Linguistics)舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp? MPP (Massively Parallel Processing),即大規模并行處理,在資料庫非共享集群中,每個節點都有獨立的磁盤存盤系統和記憶體系統,業務資料根據資料庫模型和應用特點劃分到各個節點上,每臺資料節點通過專用網路或者商業通用網路互相連接,彼此協同計算,作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀:**指標體系是什么?如何使用OSM模型和AARRR模型搭建指標體系?如何統一流程、規范化、工具化管理指標體系?本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標,系統化的組織起來,通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索,LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料,可以使用下面的 SQL 陳述句: SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀:**Ceph是國際知名的開源分布式存盤系統,在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統, ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章,這一次主要寫一個嵌套的聚合,例如先對sex集合,再對desc聚合,最后再對age求和,共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by,avg,sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack(ELK)部署

    傻瓜式部署,只需替換IP與用戶 導讀: 現ELK四大組件分別為:Elasticsearch(核心)、logstash(處理)、filebeat(采集)、kibana(可視化) 下載均在https://www.elastic.co/cn/downloads/下tar包,各組件版本最好一致,配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志(binlog),我們都知道二進制日志(binlog)非常重要,尤其當你需要point to point災難恢復的時侯,所以我們要對其進行備份。關于二進制日志(binlog)的備份,可以基于flush logs方式先切換binlog,然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能,以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景,僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代,MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足,但是對于很多開發者和DBA來說,如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL(ClickHouse自帶)、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“(堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError(堆外記憶體溢位) ”問題如下: 一、報錯資訊: 使用 Redis 的業務介面 ,產生 OutOfDirectMemoryError(堆外記憶體溢位),如圖: 格式化后的報錯資訊: { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:23:11 more