Replication sharding backup trong MongoDB

Replication sharding backup trong MongoDB Những khái niệm về Replication Sharding Backup trong MongoDB Hướng dẫn chi tiết cài đặt một Replica Set trên WindowsCơ sở dữ liệu noSQL Sự bùng nổ thông tin như hiện nay thì noSQL là một giải pháp lưu trữ hoàn hảo cho dữ liệu lớn

BÁO CÁO MÔN HỌC CƠ SỞ DỮ LIỆU NÂNG CAO ĐỀ TÀI TÌM HIỂU TÌM HIỂU REPLICATION, SHARDING, BACKUP TRONG MONGODB Giảng viên hướng dẫn: TRẦN THIÊN THÀNH Sinh viên: PHẠM HOÀ PHONG SƯ PHẠM TIN HỌC K39 Quy Nhơn, tháng năm 2020 Mục lục I SAO LẶP (REPLICATION) - Replication gì? - Read preference (đọc ưu tiên) - Write concern (quan hệ ghi) - Các loại secondary member - Priority replica set member - Hidden replica set member - Delay replica set member - - Tóm lại: - THIẾT LẬP REPLICA SET TRÊN WINDOWS - II BACKUP - 15 Lệnh - 16 ẢNH MINH HOẠ - 16 III SHARDING - 18 Sharded Cluster - 19 Shard Keys - 19 Ưu điểm việc sharding - 20 Khả lưu trữ - 20 Tính sẵn sàng cao - 20 - Các ý trước sharding - 20 Sharded Non-Sharded Collections - 21 Chiến lược Sharding - 22 Ranged Sharding - 22 Hashed Sharding - 22 - -1- I SAO LẶP (REPLICATION) Replication gì? Là tiến trình đồng hố liệu từ nhiều server, tập data nhân nhiều server thay tập trung single server Cung cấp dư thừa tăng liệu có tính khả dụng với nhiều liệu nhiều database server khác Tác dụng:  Bảo vệ sở liệu từ việc thất từ server  Phục hồi liệu có lỗi phần cứng từ việc ngắt kết nối dịch vụ  Có thể phục hồi, báo cáo, lưu với liệu bổ sung Tại sử dụng Replication:       An toàn liệu Tăng tính sẵn sàng cao cho liệu (24/7) Phục hồi liệu lỗi nhanh chóng Khơng tốn thời gian trì Mở rộng khả đọc (truy xuất nhanh) Trong suốt cho ứng dụng Cách Replication làm việc MongoDB: MongoDB sử dụng Replica Set để thực Replication Một Replica Set có Primary Primary member nhận write request Primary ghi thay đổi vào Oplog (Operations log: dùng để lưu trữ thay đổi liệu dạng file log Trên Windows, kích thước Oplog mặc định 5% nhớ, tối thiếu 50MB, tối đa 50GB) Các secondary áp dụng từ primary nên có chung dataset (bộ liệu) với primary Read request scale (mở rộng) primary tất secondary Một replica set có tối đa 50 member Nếu lớn 50 member bạn phải dùng giải pháp khác MongoDB có đề nghị giải pháp master-slave replication cho môi trường lớn 50 member tơi chưa tìm hiểu giải pháp Giữa thành viên replica set trì kết nối heartbeat (sóng kết nối, đồng bộ) nên thành viên gặp cố treo, hỏng máy, virus cơng,… thành viên cịn lại nhận tự động tiến hành failover (chế dộ dự phòng hệ thống mạng) Trong mongoDB thành viên tự giám sát tự failover Cơ chế thực failover replica set dựa voting (hàm bầu cử) Một secondary bầu lên làm primary replica set Để voting thành cơng số member replica set phải số lẻ không xảy trường hợp hai ứng viên nhận số phiếu bầu chẳng làm primary dẫn đến tình có hai member tự nhận primary Tuy vậy, để giảm chi phí đầu tư, bạn cần hai thành viên replica set Thành viên thứ ba arbiter Arbiter thành viên đặc biệt Nó khơng áp dụng oplog từ primary nên khơng lưu liệu Nhiệm vụ arbiter giám sát hệ replica set qua đường liên kết heartbeat bầu chọn secondary lên primary failover Arbiter hoạt động khơng có nặng nề, bạn khơng cần server riêng cho arbiter arbiter không nên deploy server dùng làm primary hay secondary replica set Arbiter arbiter khơng primary bị cố trở thành secondary tham gia lại vào replica set hay secondary trở thành primary failover xảy -3- Replication từ primary secondary bất đồng (asynchronous) writeset có primary khơng thể có secondary Hệ liệu secondary không phản ánh trạng thái liệu primary Thực nhược điểm có hệ thống mà dựa replication Read preference (đọc ưu tiên) Mặc định, driver mongoDB thực read request đến master (primary) Read request từ primary gọi strict consistency (tính quán chặt chẽ) với ý nghĩa application lấy data state (trạng thái liệu) Nếu application không yêu cầu trả phiên liệu bạn điều chỉnh read preference mongoDB để mở rộng quy mô đọc Đọc từ secondary gọi eventual consistency (nhất quán cuối) với ý nghĩa cuối data state secondary đồng với primary Read preference có chế độ tất cả:  primary mặc định, read request đến primary  primaryPreferred: read request đến primary primary down đến secondary  secondary: read request đến secondary  secondaryPreferred: read request đến secondary tất secondary down đến primary  nearest: read request đến member có network latency (độ trễ mạng) thấp khơng phân biết thành viên primary hay secondary Write concern (quan hệ ghi) Write concern yêu cầu mongoDB xác nhận write request có thành công hay không Với replica set, mặc định write concern yêu cầu mongoDB xác nhận write request primary member Ở chế độ này, application biết write request có thành cơng hay khơng primary Nó khơng thể biết liệu write request replicate thành công đến secondary member hay chưa MongoDB cho phép bạn thay đổi hành vi mặc định write concern Application lựa chọn thay đổi write concern write request Hành vi write concern thay đổi áp dụng cho write request này: db.products.insert( { item: “envelopes”, qty : 100, type: “Clasp” }, { writeConcern: { w: 2, wtimeout: 5000 } } ) Write request insert item vào collection products trả sau write request thực primary secondary (w: 2) khơng có kết trả kết thúc vịng 5s (wtimeout: 5000) Giá trị wtimeout để tránh cho write request bị block lại q lâu khơng có đủ số thành viên mà write concern cần Bạn thay đổi hành vi mặc định write concern phạm vi toàn write request thay request trên: cfg = rs.conf() cfg.settings = {} cfg.settings.getLastErrorDefaults = { w: “majority”, wtimeout: 5000 } rs.reconfig(cfg) Cấu hình yêu cầu mongoDB trả kết sau write request hoàn thành majority member trả sau 5s Majority members phần member -5- chiếm đa số replica set Ví dụ: replica set có node majority member bao gồm primary secondary ( Tổng số ) Majority write concern đề cập ln có primary write request ln làm việc vào primary member trước tiên Từ vị trí application, bạn khơng áp dụng write concern đủ dẫn đến write set bị sau failover: Giả sử application dùng write concern mặc định nên kết trả primary xử lý xong write set lý đó, write set chưa replicate sang secondary Application điều Không may, thời điểm đó, primary down, failover thực tự động, secondary lên làm primary secondary khơng có write set Đó cách liệu bị dùng write concern không đầy đủ Các loại secondary member Priority replica set member Là secondary member khơng trở thành primary Nó khơng thể thực việc bỏ phiếu tham gia vào q trình bỏ phiếu Vai trò priority member giống standby member (thành viên dự phòng) dùng để thay secondary member mà bị unavailable Một trường hợp khác mà priority member dùng member có thơng số hardware mạnh yếu khác Những member khỏe mạnh ưu tiên lên làm primary failover Những member yếu chút giữ vị trí secondary member Hidden replica set member Là priority member nên khơng thể trở thành primary tham gia vào trình bầu cử Điểm khác biệt hồn tồn ẩn với client Client không gửi read request đến hidden member ngồi replication, hidden member khơng cịn traffic khác Bạn sử dụng hidden member vài trò backup reporting server Tuy vậy, sử dụng với vai trị backup có rủi ro ln primary Giả sử, developer lỡ tay thực remove document khỏi collection primary mà quên không truyền điều kiện tong collection Tệ hơn, system admin vô ý gõ nhầm drop collection primary Cả hai tình đó, backup hidden member khơng thể cứu vãn Đó thực thảm họa Delay replica set member Là priority 0, hidden member, tham gia vào trình bầu cử failover Đây loại member giải hai tình mà hidden member bó tay Delay member replicate data từ oplog primary secondary khác có khác chút data set delay member cũ primary khoảng thời gian định Khoảng thời gian gọi slaveDelay cấu hình Như vậy, cố vô ý liệu thao tác sai lúc 9h sáng cịn data set nguyên vẹn thời điểm 8h sáng ( slaveDelay 3600s ) Tuy lượng data backup bị hụt so với data khoảng gần tiếng dù cố xảy bạn không hết Delay member có ưu việt hidden member không ? Tôi nghĩ không Mỗi loại member giải tốn khác Nếu tình primary bị hỏng ổ cứng, kernel panic… hidden member tỏ ưu việt delay member giữ gần tồn data set Tóm lại: MongoDB sử dụng Replica Set để thực Replication      Viết hoạt động đến nút Các thay đổi ghi vào lịch sử hoạt động Nhân không đồng đến thứ cấp Thứ cấp sap chép lịch sử nút Thứ cấp sử dụng đồng nguồn với thứ cấp Chức thành viên replica set    Primary: read, write operations Secondary: Asynchronous replication, can be primary Arbiter: just for voting – no replication, can not be primary -7- THIẾT LẬP REPLICA SET TRÊN WINDOWS Primary Server: port 27017, Secondary Server: port 27020, port 27021 Tạo thư mục data1 data ổ đĩa C Trong thư mục tạo thư mục con: config, db, log Trong thư mục config tạo tệp mongo.cfg ; thư mục log tạo tệp mongod.log Nội dung file config.cfg data1 dbpath =C:\data1\db\path logpath =C:\data1\log\mongod.log\ port=27020 data2 dbpath =C:\data2\db\path logpath =C:\data2\log\mongod.log\ port=27021 Tắt service MongoDB Service.msc Mở Command line quyền administrator (27017) mongod dbpath “C:\Program Files\MongoDB\Server\4.2\data” -logpath “C:\Program Files\MongoDB\Server\4.2\log\mongod.log” -port 27017 storageEngine=wiredTiger journal replSet r2schools //khởi động MongoDB server Mở Command line quyền administrator mongo port 27017 rsconf={_id:”r2schools”,members:[{_id:0,host:”localhost:27017”}]} rs.initiate(rsconf) -9- Mở Command line quyền administrator mongod dbpath “C:\data1\db” logpath “C:\data1\log\mongod.log” port 27020 -storageEngine=wiredTiger journal replSet r2schools //Khởi động MongoDB server cổng 27020 Mở Command line quyền administrator mongod dbpath “C:\data2\db” logpath “C:\data2\log\mongod.log” port 27021 -storageEngine=wiredTiger journal replSet r2schools //Khởi động MongoDB server cổng 27021 Mở Command line 27017 rs.add(“localhost:27020”) //Thêm thành viên tới Replica Set rs.status() //Trạng thái thành viên rs.add(“localhost:27021”) rs.status() Lúc có host Id:0 / name: localhost:27017 / stateStr: PRIMARY Id:1 / name: localhost:27020 / stateStr: SECONDARY Id:2 / name: localhost:27021 / stateStr: SECONDARY Mở Command line quyền administrator (27020) port 27020 //thao tác với server 27020 show dbs //hiển thị database rs.slaveOk() //lấy database từ PRIMARY (master) show dbs rs.isMaster() //kiểm tra server có phải master khơng - 11 - Khơng insert liệu port: 27020 khơng phải PRIMARY server Mở Command line quyền administrator (27021) port 27021 show dbs rs.slaveOk() show dbs rs.isMaster() Không insert liệu port: 27021 khơng phải PRIMARY server Thêm database vào port: 27017, thêm collection document mới, qua port: 27020 port: 27021 xem có cập nhật thêm database khơng, có cập nhật cài đặt thành cơng - 13 - Insert liệu PRIMARY server (port: 27017) Truy vấn liệu PRIMARY server Truy vấn liệu SECONDARY server (port:27020) Tạo collection tên QNU vào database qlsv SECONDARY server (port: 27020) xuất collection vừa tạo Khi PRIMARY server (port: 27017) bị hỏng lỗi bầu chọn SECONDARY server (port: 27020 port: 27021) kể trở thành PRIMARY server Ở port: 27020 bầu làm PRIMARY server II BACKUP Backup hành động chép lại toàn nội dung liệu gốc quan trọng database MongoDB phòng gặp cố, thao tác backup liệu hành động thiếu, liệu bị ảnh hưởng nghiêm trọng đến hoạt động người, doanh nghiệp sở hữu liệu - 15 - Lệnh Backup toàn Database mongodump Backup Database mongodump db tên database Backup collection mongodump db tên database collection tên collection Restore toàn Database mongorestore Restore Database mongorestore db tên database dump/tên database Restore Collection mongorestore db tên database collection dump/tên database.bson Drop CSDL db.dropDatabase() Drop Collection db.tên collection.drop() ẢNH MINH HOẠ Command line 1: database có, command line 2: thực lệnh backup Lệnh backup thành công, xuất thực mục dump Mỗi thư mục dump database backup, backup database Thử xoá database qlsv sau thực backup - 17 - Thực lệnh mongorestore, database qlvs vừa xoá khôi phục lại lúc trước thực backup, tương tự collection III SHARDING Khi thiết kế database hệ thống lớn, đòi hỏi thơng lượng cao ln tốn khó Nào tùy thuộc vào loại liệu nào, kiến trúc app hay nên chọn loại database cho phù hợp, nhiều yếu tố cần phải cân nhắc Sharding phương pháp để phân phối liệu nhiều máy mà MongoDB sử dụng để hỗ trợ triển khai với app liệu lớn địi hỏi thơng lượng cao Các hệ thống sở liệu với tập liệu lớn ứng dụng địi hỏi thơng lượng cao thách thức khả máy chủ Ví dụ ứng dụng chat có lượng lớn người dùng, người dùng ln địi hỏi việc gửi nhận tin nhắn họ phải real-time (thời gian thực) Lúc nhu cầu truy vấn cao địi hỏi lượng lớn RAM CPU mà chắn máy chủ khó lịng đáp ứng Sẽ có giải pháp ứng dụng kiểu là: mở rộng theo chiều ngang (horizontal scaling) mở rộng theo chiều dọc (vertical scaling)  Vertical scaling: scale theo chiều dọc liên quan đến việc tăng dung lượng máy chủ, chẳng hạn sử dụng CPU mạnh hay thêm RAM tăng dung lượng lưu trữ  Horizontal scaling: scale theo chiều ngang liên quan đến việc chia nhỏ liệu hệ thống tải chúng lên nhiều server, thêm server để tăng công suất Mặc dù tốc độ công suất chung máy máy xử lý tập hợp khối lượng liệu chung có khả mang lại hiệu tốt so với server công suất cao MongoDB hỗ trợ scale theo chiều ngang thông qua Sharding Sharded Cluster Để chia nhỏ khối liệu lớn nhiều máy trạm khác nhau, mongoDB có chế sharding Sharding kỹ thuật cho phép ghi sở liệu phân tán nhiều máy chủ khác Điều giúp cho khả mở rộng, lưu trữ xử lý hệ thống Một sharded cluster bao gồm thành phần sau: MongoDB sharded cluster gồm thành phần:  shard: shard chứa tập liệu tổng (đơn vị quản lý liệu sharded cluster) Ngồi shard triển khai shard khác, shard thường replica set  mongos: thành phần hoạt động định tuyến truy vấn (query router, cung cấp interface client sharded cluster  config servers: thành phần lưu trữ metadata cấu hình cho cluster (ví dụ document nằm shard nào,…Từ 3.0 trở đi, config server replicaset MongoDB phân chia liệu mức collection phân phối chúng shard cluster Shard Keys MongoDB sử dụng shard key để phân phối collections's documents shard Shard key bao gồm nhiều trường tồn document collection cần truy vấn Bạn phải chọn shard key sharding collection Việc lựa chọn shard key thay đổi sau sharding Một sharded collection có shard key - 19 - nhất, shard key trường unique, dùng shard key để định xem document nằm shard Hình minh họa với shard key x Việc lựa chọn shard key ảnh hưởng đến hiệu suất, hiệu khả mở rộng database Một cluster với phần cứng sở hạ tầng tốt bị ngẽn việc lựa chọn shard key không hiệu Ưu điểm việc sharding Khả đọc/ghi Đối với truy vấn kèm theo shard key, mongos hướng mục tiêu đến shard cụ thể Việc hướng mục tiêu chắn hiệu việc truy vấn tất Khả lưu trữ Việc sử dụng shards cluster cho phép shard chứa tập hợp liệu tổng Khi liệu lớn lên việc thêm shards tăng khả lưu trữ cluster Tính sẵn sàng cao Việc đọc ghi ổn cho dù có vài shard bị hỏng máy lưu shard máy khác đọc ghi Các ý trước sharding  Vì u cầu nhiều máy nên địi hỏi phải thiết kế bảo trì cẩn thận  Lựa chọn shard key cẩn thận ảnh hưởng đến hiệu xuất sau sharded ko thay đổi shard key  Khi truy vấn truy vấn shard key ko mongos truy vấn tất cá shard thời gian Sharded Non-Sharded Collections Một database bao gồm sharded unsharded collections Sharded collection chia phân phối cluster Unsharded collecton lưu shard (mỗi database có shard chính), shard chứa collection chứa phần collection, collection trải dài nhiều shard Từ ứng dụng kết nối tới database phải thông qua mongos để tương tác vs sharded unsharded colleciton - 21 - Chiến lược Sharding MongoDB hỗ trợ cách Hashed Sharding Ranged Sharding: Chunk: MongoDB chia liệu thành khối gọi Chunk Mỗi chunk đc chia liên quan đến shard key, cách chia phù hợp với shard có thay đổi đồng Ranged Sharding Ranged Sharding liên quan đến việc chia liệu dựa theo giá trị shard key Mỗi chunk sau đc gán với phạm vi (chia shard thành range liền nhau, ví dụ: shardA chiến từ -10 đến 10 shardB chiếm từ 11 đến 31 chẳng hạn, shard-key document rơi vào khoảng nằm vào shard đó) Hashed Sharding Chúng ta sử dụng hàm băm (hash function) shard key Mỗi phần sau gán phạm vi dựa giá trị hash shard key Mỗi giá trị shard key đưa qua hàm băm, sau lại đưa vào range cách ranged sharding cách giúp đảm bảo document phân tán triệt để MongoDB hỗ trợ hash function  ... Collections - 21 Chiến lược Sharding - 22 Ranged Sharding - 22 Hashed Sharding - 22 - -1- I SAO LẶP (REPLICATION) Replication gì? Là tiến trình đồng... có, command line 2: thực lệnh backup Lệnh backup thành công, xuất thực mục dump Mỗi thư mục dump database backup, backup database Thử xoá database qlsv sau thực backup - 17 - Thực lệnh mongorestore,... server công suất cao MongoDB hỗ trợ scale theo chiều ngang thông qua Sharding Sharded Cluster Để chia nhỏ khối liệu lớn nhiều máy trạm khác nhau, mongoDB có chế sharding Sharding kỹ thuật cho