Computer >> Máy Tính >  >> Lập trình >> Redis

Tầm quan trọng của tính bền vững và sao lưu cơ sở dữ liệu

Gần đây, chúng tôi đã có cơ hội làm việc với nhóm Cohesity để xác minh sự tích hợp giữa Helios và Redis Enterprise như một bước tham gia vào Chương trình Đối tác Kỹ thuật Redis. Cohesity SmartFiles, một dịch vụ chạy trên Helios, cung cấp một chế độ xem duy nhất và quản lý toàn cầu dữ liệu phi cấu trúc, bất kể dữ liệu đó nằm ở đâu. Trong ngữ cảnh của Redis Enterprise, SmartFiles cung cấp một chế độ xem duy nhất về ảnh chụp nhanh cơ sở dữ liệu.

Tại sao chúng ta bận tâm với sự bền bỉ và sao lưu? Đúng là:Nếu Redis được sử dụng làm bộ nhớ đệm và có thể được bù nước từ cơ sở dữ liệu phụ trợ với tác động hệ thống tối thiểu, thì không cần phải làm như vậy. Mặt khác, hãy xem xét khi nào Redis được sử dụng làm cơ sở dữ liệu hoạt động để cung cấp khả năng truy cập nhanh vào dữ liệu chậm (hãy nghĩ:lịch sử giao dịch, số lượng hàng tồn kho, tra cứu khách hàng). Cơ sở dữ liệu Redis cần nhanh chóng phục hồi sau các sự cố phần cứng hoặc thậm chí là chuyển đổi dự phòng sang một trung tâm dữ liệu khác.

Tính bền bỉ

Tất cả dữ liệu trong cơ sở dữ liệu Redis được lưu trữ và quản lý độc quyền trong RAM hoặc RAM + Bộ nhớ Flash (Redis on Flash); nó có nguy cơ bị mất khi quy trình hoặc lỗi máy chủ. Có một số chiến lược có thể được tuân theo để giảm thiểu rủi ro này:Cơ sở dữ liệu Tính sẵn sàng cao (HA) với các phân đoạn dữ liệu chính và phụ, cơ sở dữ liệu hoạt động tích cực được phân phối theo địa lý và tất nhiên là tính bền bỉ dựa trên đĩa. Từ góc độ hiệu suất, việc chuyển đổi dự phòng từ phân đoạn cơ sở dữ liệu chính sang phân đoạn cơ sở dữ liệu thứ cấp được đồng bộ hóa luôn được ưu tiên và đây là cách Redis Enterprise hoạt động; chỉ khi các phân đoạn chính và phụ bị mất thì cơ sở dữ liệu mới được khôi phục từ đĩa. Tương tự, trong trường hợp trung tâm dữ liệu bị lỗi, việc truy cập cơ sở dữ liệu đang hoạt động tích cực được đồng bộ hóa trong một trung tâm dữ liệu khác sẽ nhanh hơn so với việc khôi phục từ đĩa.

Đối với câu hỏi về tính bền bỉ, Redis hỗ trợ các tệp chỉ nối thêm (AOF) để có độ bền tốt hơn, mặc dù yêu cầu nhiều tài nguyên hơn và ảnh chụp nhanh (RDB), kém bền hơn trong khi yêu cầu ít tài nguyên hơn. Như với tất cả mọi thứ, có những sự cân bằng có thể được khám phá thêm trong tài liệu Redis Enterprise. Đối với mục đích của bài viết này, chúng tôi sẽ giả định rằng chúng tôi muốn AOF để có độ bền tốt hơn.

Tầm quan trọng của tính bền vững và sao lưu cơ sở dữ liệu

Backup

Redis Enterprise dựa vào sự bền bỉ để phục hồi khi cả phân đoạn cơ sở dữ liệu chính và phụ bị mất. Nếu hoạt động tích cực không được sử dụng và các giá đỡ chứa cơ sở dữ liệu cùng với bộ nhớ đính kèm bị mất, thì chúng ta phải khôi phục từ bản sao lưu. Trong trường hợp của Redis Enterprise, bản sao lưu luôn là một bản chụp nhanh, khi được kết hợp với AOF để bền bỉ, sẽ tạo ra một nền tảng dữ liệu có khả năng phục hồi và lâu bền.

Đây là lúc Cohesity SmartFiles phát huy tác dụng; Redis Enterprise sử dụng điểm cuối tương thích S3 do SmartFiles cung cấp một cách thuận tiện để sao lưu được quản lý trên các đám mây. Để thiết lập điều này, chúng tôi sử dụng API Redis Enterprise REST với các giả định sau:

  • $ S3_IP được đặt thành địa chỉ IP cửa hàng đối tượng Cohesity S3 và $ BUCKET được đặt thành tên nhóm
  • $ USER và $ PASS lần lượt được đặt thành tên người dùng và mật khẩu quản trị viên Redis Enterprise
  • $ ACCESS_KEY và $ SECRET_KEY lần lượt được đặt làm khóa truy cập cửa hàng đối tượng S3 và khóa bí mật

Kích hoạt tính ổn định của cơ sở dữ liệu.

curl -s -k -u $USER:$PASS -H content-type:application/json -XPUT 
https://localhost:9443/v1/bdbs/1 -d '{"data_persistence": "aof"}'

Định cấu hình cụm để sử dụng kho đối tượng S3 bằng cách đặt URL S3. Lưu ý rằng tên nhóm không được bao gồm trong URL S3.

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d '{"s3_url": '\"$S3_IP\"'}'

Định cấu hình sao lưu S3 cụm chỉ dành cho quyền riêng tư.

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d 
'{"s3_certificate_verification":false}'

Xác thực vị trí sao lưu. Lưu ý rằng phản hồi duy nhất khi thành công là HTTP 200 OK.

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/actions/validate_backup_location -d 
'{"backup_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "","access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

Tạo một bản sao lưu. Lưu ý rằng phản hồi duy nhất khi thành công là HTTP 200 OK.

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/1/actions/export -d 
'{"export_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "", "access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

Định cấu hình sao lưu định kỳ 30 phút một lần. Lưu ý rằng phản hồi duy nhất khi thành công là HTTP 200 OK.

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/bdbs/1 -d '{"backup":true, 
"backup_interval":1800, "backup_interval_offset":360, 
"backup_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "", "access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

Kết luận

Trong một thế giới không có ma sát, Redis Enterprise được định cấu hình với HA và Active-Active giúp bạn không phải lo lắng về tính bền bỉ và sao lưu. Chúng ta không sống trong một thế giới không có ma sát và chúng ta cần cả sự kiên trì và dự phòng (cùng với HA) khi Redis dự kiến ​​sẽ phục hồi sau các lỗi hệ thống. Người ta thường thấy một điểm cuối sao lưu S3 như có thể được nhìn thấy bởi các dịch vụ của thiết bị như Dell EMC, NetApp hoặc Pure Storage. May mắn thay, việc tích hợp đã được xác minh với Cohesity SmartFiles giúp bạn dễ dàng sử dụng điểm cuối này và đưa các bản sao lưu vào các chiến lược hoạt động.