Thực đơn
trang chủHướng dẫn

Xem "ACID" là gì trong các từ điển khác. Giao dịch. Thuộc tính của giao dịch ACID. Quản lý phục hồi. Thuật toán ARIES. Cố định hai pha

Đây cũng là cơ sở dữ liệu nhưng hướng dẫn sử dụng

Xin chào!

Hãy nói về cơ sở dữ liệu. Ngày nay, các giao dịch, định lý ACID và CAP là một lý thuyết quan trọng cho các bài viết sau.

Giao dịch

Giao dịch là một tập hợp các hành động dữ liệu được kết hợp thành một đơn vị logic. Nó có được thực hiện đầy đủ hay không. Một ví dụ kinh điển với thao tác chuyển tiền từ tài khoản này sang tài khoản khác:

Bắt đầu đọc số dư giao dịch trên tài khoản số 5 giảm số dư 10 đơn vị tiền tệ tiết kiệm cân bằng mới tài khoản số 5 đọc số dư tài khoản số 7 tăng số dư thêm 10 đơn vị tiền tệ lưu số dư mới tài khoản số 7 Kết thúc giao dịch

Nếu các thao tác này được thực hiện bên ngoài giao dịch, thì một lỗi trong bất kỳ thao tác nào trong số đó sẽ khiến cả hai tài khoản ở trạng thái không nhất quán: ví dụ: tiền sẽ được rút từ một tài khoản nhưng không nhận được ở tài khoản kia. Không có vấn đề nào như vậy với giao dịch - nếu xảy ra lỗi, tất cả các hoạt động sẽ được khôi phục và không có gì thay đổi đối với người dùng.

Mọi chuyện nghe có vẻ đơn giản khi một người dùng đang làm việc trên cơ sở dữ liệu: anh ta thực hiện lần lượt các giao dịch và không gặp vấn đề gì với việc giao dịch này can thiệp vào giao dịch khác. Mọi thứ thay đổi khi có nhiều người dùng.

Đây là những gì có thể xảy ra khi chạy song song các giao dịch không bị cô lập.

Mất bản cập nhật
Khi hai giao dịch được ghi lại những nghĩa khác nhau vào cùng một ô, một trong những thay đổi sẽ bị mất.

đọc bẩn
Khi dữ liệu được đọc, tại thời điểm đó dữ liệu sẽ bị thay đổi bởi giao dịch, sau đó giao dịch được khôi phục và dữ liệu biến mất.

Đọc không lặp lại
Khi dữ liệu được đọc nhiều lần, tại thời điểm đó sẽ bị thay đổi bởi giao dịch, mỗi lần dữ liệu đó có thể bị người khác từ chối.

Đọc ma
Trong quá trình thực hiện, một giao dịch sẽ chọn nhiều hàng bằng cách sử dụng cùng một tiêu chí nhiều lần. Một giao dịch khác, giữa các lựa chọn này, thêm hoặc xóa các hàng hoặc thay đổi cột của một số hàng được sử dụng trong tiêu chí lựa chọn của giao dịch đầu tiên và hoàn tất thành công. Kết quả là, các lựa chọn giống nhau trong giao dịch đầu tiên tạo ra các tập hợp hàng khác nhau.

Cách ly giao dịch

Để các giao dịch song song có thể được thực hiện mà không ảnh hưởng lẫn nhau, họ đã đưa ra khái niệm cô lập giao dịch. Tổng cộng có bốn cấp độ cách ly, nhưng một số cơ sở dữ liệu giới thiệu các cấp độ riêng của chúng.

Đọc dữ liệu không được cam kết
Hầu hết cấp thấp sự cách ly. Bạn có thể tự do đọc những thay đổi không được cam kết từ các giao dịch khác, nhưng việc viết phải tuân theo trình tự nghiêm ngặt. Bằng cách này, chỉ vấn đề mất bản cập nhật được loại bỏ: đảm bảo rằng cuối cùng tất cả các giao dịch sẽ ghi giá trị được yêu cầu vào ô.

Thông thường, điều này được thực hiện bằng cách sử dụng khóa ghi trên các ô dự định thay đổi trong giao dịch hiện tại. Không có khóa nào được đặt khi đọc.

Đọc dữ liệu đã cam kết
Bạn có thể thoải mái đọc mọi thay đổi trong giao dịch của mình và ghi lại những thay đổi trong giao dịch của người khác. Các bản cập nhật bị mất và các lần đọc sai được loại bỏ, trong khi các vấn đề về các lần đọc và ảo không thể lặp lại vẫn còn.

Đọc lặp lại
Bạn chỉ có thể đọc tất cả các thay đổi đối với giao dịch của mình. Dữ liệu được sửa đổi bởi các giao dịch khác không có sẵn. Vấn đề duy nhất còn lại là đọc ảo.

Có thể tuần tự hóa
Các giao dịch hoàn toàn tách biệt với nhau, mỗi giao dịch được thực hiện như thể không có giao dịch song song nào tồn tại.

axit

Đây là bộ bốn yêu cầu đối với hệ thống giao dịch, đảm bảo hoạt động đáng tin cậy và có thể dự đoán được nhất. Không phải tất cả cơ sở dữ liệu đều triển khai đầy đủ ACID.

Tính nguyên tử
Tính nguyên tử đảm bảo rằng mỗi giao dịch sẽ được hoàn thành hoàn toàn hoặc không hoàn thành. Các trạng thái trung gian không được phép.

Tính nhất quán
Tính nhất quán là yêu cầu rằng giao dịch sẽ mang lại dữ liệu hợp lệ. Đây không phải là vấn đề về công nghệ mà là logic kinh doanh: ví dụ: nếu số tiền trong tài khoản không thể âm thì logic giao dịch phải kiểm tra xem có dẫn đến giá trị âm hay không.

Sự cách ly
Đảm bảo rằng các giao dịch đồng thời không ảnh hưởng đến kết quả của các giao dịch khác. Chúng tôi đã giải quyết sự cô lập ở trên.

Độ bền
Những thay đổi do giao dịch phải được duy trì bất chấp mọi lỗi. Nói cách khác, nếu người dùng nhận được tín hiệu cho biết giao dịch đã hoàn tất, anh ta có thể chắc chắn rằng dữ liệu đã được lưu.

định lý CAP

Nó nói rằng trong hệ thống phân phối Chỉ có thể đạt được hai trong số ba thuộc tính: tính nhất quán, tính khả dụng và khả năng chống phân vùng. Giúp bạn hiểu cách một hệ thống phân tán cụ thể sẽ hoạt động và những gì mong đợi từ nó.

Tính nhất quán của dữ liệu
Khi ở tất cả các nút tại mỗi thời điểm, dữ liệu nhất quán với nhau, nghĩa là không mâu thuẫn với nhau. Nếu một nút có dữ liệu trong ô cơ sở dữ liệu thì tất cả các nút khác đều có cùng dữ liệu.

khả dụng
Khi bất kỳ yêu cầu nào cũng có thể được hệ thống xử lý, bất kể trạng thái của nó.

Dung sai phân vùng
Khi chia hệ thống thành nhiều phần riêng biệt không dẫn đến phản hồi không chính xác từ từng phần: mạng giữa hai nút đã ngừng hoạt động, nhưng mỗi nút trong số chúng có thể phản hồi chính xác với máy khách của mình.

Tất cả cơ sở dữ liệu phân tán dữ liệu theo cách này hay cách khác kịch bản hay nhất nhận ra hai thuộc tính trong số ba thuộc tính, hy sinh những thuộc tính còn lại.

Bài viết tiếp theo nói về những cơ sở dữ liệu hiếm có mà bạn sẽ không thấy trong các dự án thông thường. Đây là nơi toàn bộ lý thuyết này sẽ có ích.

7.1 Đặc tính axit

7.1.1 Trong quá trình kiểm tra điểm chuẩn này, Hệ thống được kiểm tra phải có các thuộc tính ACID (Tính nguyên tử, Tính nhất quán, Cách ly, Độ bền) là chìa khóa cho hệ thống xử lý giao dịch.

7.1.2 Mục đích của phần này là cung cấp một mô tả không chính thức Thuộc tính axit và chỉ định một loạt các thử nghiệm phải được thực hiện để chứng minh rằng việc sở hữu các đặc tính này được đảm bảo.

7.1.3 Không có chuỗi thử nghiệm hữu hạn nào có thể chứng minh rằng các thuộc tính ACID được hỗ trợ đầy đủ. Việc vượt qua các bài kiểm tra theo quy định là bắt buộc, nhưng không đủ điều kiện tuân thủ các yêu cầu về thuộc tính ACID. Tuy nhiên, để báo cáo rõ ràng, chỉ những bài kiểm tra được chỉ định ở đây mới được coi là cần thiết và chỉ những bài kiểm tra đó mới được báo cáo trong báo cáo kiểm tra điểm chuẩn này.
Lưu ý: Mục đích của các thử nghiệm này là để chứng minh rằng các nguyên tắc ACID được Hệ thống đang thử nghiệm hỗ trợ và được áp dụng trong quá trình Thực hiện thử nghiệm. Chúng không được thiết kế để kiểm tra đảm bảo chất lượng toàn diện.

7.1.4 Trong quá trình Thực hiện Kiểm tra, phải áp dụng cấu hình cần thiết để đảm bảo tuân thủ đầy đủ các thuộc tính ACID. Điều này áp dụng cho cả cơ sở dữ liệu (bao gồm TPC-E và Đã xác định người dùngđối tượng) và Phiên cơ sở dữ liệu được sử dụng để tiến hành kiểm tra ACID và Thực thi điểm chuẩn.
Lưu ý 1: Khái niệm "cấu hình" bao gồm tất cả các thuộc tính và đặc điểm cơ sở dữ liệu có thể được xác định từ bên ngoài; nó bao gồm, nhưng không giới hạn, các tệp cấu hình và khởi tạo, cài đặt môi trường, lệnh và các tệp được lưu trữ thủ tục SQL, các mô-đun và tiện ích bổ sung có thể tải xuống. Ví dụ: nếu SUT dựa trên Nhật ký hoàn tác/trả lại thì việc ghi nhật ký phải được duy trì cho tất cả các Giao dịch, bao gồm cả những giao dịch không chứa tùy chọn khôi phục trong Hồ sơ giao dịch.
Lưu ý 2: Trong trường hợp thử nghiệm điểm chuẩn này được triển khai trên hệ thống phân tán, các thử nghiệm phải được thực hiện để xác minh rằng Giao dịch được xử lý trên hai nút trở lên tuân thủ các thuộc tính ACID.

7.1.5 Mặc dù kiểm tra ACID không kiểm tra tất cả các loại Giao dịch trong phạm vi công việc này nhưng các thuộc tính ACID phải được đáp ứng cho tất cả các Giao dịch.

7.1.6 Người tổ chức gửi kết quả TPC phải thực hiện kiểm tra ACID trên một trong các hệ thống bất kỳ mà kết quả được cung cấp, miễn là họ sử dụng cùng một hệ thống. phần mềm triển khai (ví dụ: Hệ điều hành, DBMS, chương trình giao dịch). Ví dụ: nội dung của đoạn này sẽ phù hợp khi Kết quả được cung cấp cho nhiều hệ thống từ cùng một dòng sản phẩm. Tuy nhiên, các bài kiểm tra Khả năng phục hồi được mô tả trong Điều 7.5.2.2, 7.5.2.3 và 7.5.2.4 phải được thông qua trên tất cả các hệ thống được đánh giá. Tất cả FDR phải hiển thị các hệ thống được sử dụng để xác minh các yêu cầu ACID, cũng như Mô tả đầy đủáp dụng các xét nghiệm ACID và kết quả thu được trong đó..

7.2 Yêu cầu về tính nguyên tử

7.2.1 Định nghĩa tính chất nguyên tử

Hệ thống được thử nghiệm phải đảm bảo rằng Giao dịch cơ sở dữ liệu là nguyên tử; hệ thống sẽ hoàn thành tất cả các thao tác riêng lẻ trên dữ liệu hoặc đảm bảo rằng không có thao tác nào được hoàn thành một phần có bất kỳ ảnh hưởng nào đến dữ liệu dưới bất kỳ hình thức nào.

7.2.2 Thử nghiệm tính nguyên tử

Thực hiện Giao dịch lệnh giao dịch thị trường bằng cách đặt cờ roll_it_back thành 0. Xác minh rằng các hàng thích hợp đã được thêm vào bảng TRADE và TRADE_HISTORY.
Thực hiện Giao dịch lệnh giao dịch trên thị trường bằng cách đặt cờ roll_it_back thành 1. Kiểm tra để chắc chắn rằng không có hàng nào liên quan đến Giao dịch lệnh giao dịch đã được thêm vào các bảng TRADE và TRADE_HISTORY.

7.3 Yêu cầu về trình tự

7.3.1 Xác định thuộc tính Sequence

Tính nhất quán là một thuộc tính của Ứng dụng nhằm đảm bảo rằng mọi thực thi Giao dịch cơ sở dữ liệu sẽ dẫn đến việc nó chuyển từ trạng thái này sang trạng thái khác.

7.3.1.1 Cơ sở dữ liệu TPC-E được điền lần đầu tiên bằng EgenLoader phải có các thuộc tính trình tự.

7.3.1.2 Nếu dữ liệu được sao chép như được cho phép trong khoản 2.3.3.3 thì mỗi bản sao phải tuân theo trạng thái trình tự như được mô tả trong khoản 7.3.2.

7.3.2 Trạng thái trình tự
Các đoạn văn sau đây xác định ba trạng thái trình tự. Mỗi điều kiện trong số ba điều kiện đều yêu cầu chứng minh rõ ràng rằng các điều kiện đó đều được đáp ứng.

7.3.2.1 Trạng thái chuỗi 1


B_NUM_TRADES = số(*)

đối với mỗi nhà môi giới, được xác định như sau:



7.3.2.2 Trạng thái chuỗi 2

Các bản ghi trong bảng MÔI GIỚI và THƯƠNG MẠI phải tôn trọng mối quan hệ:

B_COMM_TOTAL = tổng(T_COMM)

cho mỗi nhà môi giới được xác định bởi những điều sau đây:

(B_ID = CA_B_ID) và (CA_ID = T_CA_ID) và (T_ST_ID = 'CMPT').

7.3.2.3 Trạng thái chuỗi 3

Các bản ghi trong bảng HOLDING_SUMMARY và HOLDING phải tôn trọng mối quan hệ:

HS_QTY = tổng(H_QTY)

đối với từng nhóm tài sản được xác định như sau:

(HS_CA_ID = H_CA_ID) và (HS_S_SYMB = H_S_SYMB).

7.3.3 Trình tự thử nghiệm
Thử nghiệm kênh ba trạng thái phải được thực hiện cả sau khi tạo cơ sở dữ liệu ban đầu và sau bất kỳ thử nghiệm Phục hồi doanh nghiệp nào.

7.4 Yêu cầu cách nhiệt

7.4.1 Xác định đặc tính cách điện

7.4.1.1 Xem xét Giao dịch T1 và Giao dịch T2 đang thực hiện đồng thời, có thể mô tả hiện tượng sau (P0 đến P3) xảy ra trong T1.

  • P0 (Viết bẩn) - Giao dịch T2 sửa đổi (hoặc chèn) các mục dữ liệu của R. Sau đó, trước khi hành động CAM KẾT của giao dịch T2 diễn ra, Giao dịch T1 bắt đầu, có thể sửa đổi (hoặc xóa) các mục dữ liệu của R và sau đó có thể đưa ra một CAM KẾT.
Lưu ý: T2 có thể thực hiện các thao tác cơ sở dữ liệu bổ sung dựa trên trạng thái mà nó để lại các phần tử của R, tạo ra vấn đề tiềm ẩn về tính nhất quán của dữ liệu.
  • P1 (Đọc bẩn) - Giao dịch T2 sửa đổi (hoặc chèn) các mục dữ liệu R. Sau đó, trước khi T2 đưa ra CAM KẾT, Giao dịch T1 bắt đầu, đọc các mục dữ liệu R và có thể truy xuất trạng thái của các mục dữ liệu như sau T2 đã thay đổi. Sau đó, T2 có thể thực hiện thao tác ROLLBACK.
Lưu ý: T1 có thể thực hiện các thao tác cơ sở dữ liệu bổ sung dựa trên trạng thái của các mục dữ liệu của R đã được khôi phục và giả định là chưa từng tồn tại, tạo ra vấn đề tiềm tàng các chuỗi dữ liệu.
  • P2 (“Đọc không lặp lại”) - Giao dịch T1 đọc các mục dữ liệu R. Sau đó, trước khi Giao dịch T1 thực hiện CAM KẾT, Giao dịch T2 bắt đầu sửa đổi (hoặc xóa) các mục dữ liệu R và đưa ra CAM KẾT. Sau đó, T1 lặp lại việc đọc các mục dữ liệu R và có thể lấy trạng thái của các mục dữ liệu sau khi được Giao dịch T2 sửa đổi.
Lưu ý: Trước khi phát hiện trạng thái thay đổi (hoặc bị xóa) của các mục dữ liệu R, T1 có thể thực hiện các thao tác cơ sở dữ liệu bổ sung dựa trên trạng thái của các mục dữ liệu R không còn được coi là hợp lệ, tạo ra vấn đề tiềm ẩn về tính nhất quán của dữ liệu.
  • P3 (“Đọc ảo”) - Giao dịch T1 đọc một tập hợp các mục dữ liệu tương ứng với ai đó. Tiếp theo, trước khi Giao dịch T1 thực hiện thao tác COMMIT, Giao dịch T2 bắt đầu và chèn hoặc xóa một hoặc nhiều mục dữ liệu tương ứng với mục đang được T1 sử dụng. Sau đó, T1 lặp lại lần đọc đầu tiên trên cùng một dữ liệu và có thể thu được một tập hợp các mục dữ liệu khác với tập dữ liệu ban đầu.
Lưu ý: Trước khi khám phá tập hợp mục dữ liệu lớn hơn hoặc nhỏ hơn, T1 có thể thực hiện các thao tác cơ sở dữ liệu bổ sung dựa trên tập hợp các mục dữ liệu không còn được coi là phù hợp, tạo ra vấn đề tiềm ẩn về tính nhất quán của dữ liệu.

7.4.1.2 Cô lập là một thuộc tính của Giao dịch cho biết mức độ cô lập của Giao dịch đó với hành động của các Giao dịch khác chạy đồng thời với nó. Bảng bên dưới, được sắp xếp từ mức hạn chế thấp nhất (L0) đến cao nhất (L3), mô tả bốn mức độ cách ly dựa trên sự kiện nào sẽ không xảy ra

7.4.1.3 Trong quá trình Thực hiện Kiểm thử, mỗi Giao dịch TPC-E phải cung cấp một mức độ cách ly với các Giao dịch Tùy ý không thấp hơn mức được chỉ định trong bảng sau:

7.4.1.4 Trong quá trình Thực hiện Kiểm tra, SUT phải cho phép thực hiện đồng thời các Giao dịch Tùy ý.

7.4.1.5 Trong quá trình Thực hiện Kiểm tra, dữ liệu được đọc bởi mỗi Giao dịch TPC-E không được cũ hơn Dữ liệu đã được Xác minh gần đây nhất tại thời điểm Giao dịch bắt đầu.

7.4.1.6 Các hệ thống triển khai cách ly giao dịch bằng kỹ thuật chặn hoặc lập phiên bản phải chứng minh sự tuân thủ các yêu cầu cách ly bằng cách vượt qua các thử nghiệm được mô tả trong Điều 7.4.2.

7.4.1.7 Các hệ thống triển khai cách ly giao dịch bằng cách sử dụng các kỹ thuật khác ngoài việc chặn hoặc lập phiên bản có thể yêu cầu các kỹ thuật khác để chứng minh rằng các yêu cầu cách ly được đáp ứng. Trách nhiệm của Người tổ chức kiểm tra, cùng với Kiểm toán viên, là xác định các kỹ thuật này, triển khai, thực hiện chúng như một minh chứng cho việc tuân thủ các yêu cầu cách ly và cung cấp đủ thông tin trong FDR để hỗ trợ khẳng định rằng các yêu cầu cách ly đã được thực hiện. gặp.

7.4.2 Thử nghiệm cách điện
Các thử nghiệm cách ly sau đây được thiết kế để xác minh rằng cấu hình và cách triển khai Hệ thống đang được thử nghiệm cung cấp cho Giao dịch mức độ cách ly cần thiết như được mô tả trong khoản 7.4.1.3.

7.4.2.1 Kiểm tra đọc-ghi P3

Thử nghiệm này sẽ chứng minh rằng Giao dịch đọc-ghi kết quả giao dịch, trong khi thực hiện đồng thời với một Giao dịch đọc-ghi kết quả giao dịch khác, được bảo vệ khỏi Hiện tượng ma P3. Giao dịch Kết quả Thương mại thứ hai (Phần S4 bên dưới) thực hiện các chức năng của Giao dịch Ngẫu nhiên, thêm một hàng vào bảng HOLDING_SUMMARY đã được Giao dịch Kết quả Giao dịch đầu tiên truy cập (Phần S3 bên dưới).

Với mục đích thử nghiệm này, hai Giao dịch Kết quả Thương mại này phải được chuẩn bị để thực thi bản ghi hs_qty khi quay về từ Khung 1. Ngoài ra, Giao dịch Kết quả Thương mại do S3 thực hiện phải có khả năng lặp lại việc thực hiện Khung 1 và tạm dừng việc thực thi của nó trước khi Frame bắt đầu thực thi 2.



1. Từ S1 chọn acct_id. Sau khi thực hiện giao dịch được chỉ định ở chế độ chỉ đọc, hãy tìm giá trị ký hiệu không có hàng tương ứng trong bảng HOLDING_SUMMARY cho tham số acct_id đã chọn và cam kết.

2. Từ S1, gọi và hoàn tất thành công Giao dịch lệnh giao dịch cho các thông số acct_id và ký hiệu đã chọn ở bước 1. Ghi lại Trade_id được liên kết với các giao dịch này.

3. Từ S2, yêu cầu và hoàn thành thành công một Giao dịch đặt hàng giao dịch khác cho các tham số acct_id và ký hiệu được sử dụng ở bước 2. Ghi lại Trade_id được liên kết với các giao dịch này.

4. Từ S3, truy vấn Trade_id từ Kết quả giao dịch được sử dụng ở bước 2. Tạm dừng giao dịch giữa Khung 1 và Khung 2. Ghi lại hs_qty và kiểm tra xem nó có được đặt thành 0 hay không.

5. Từ S4, truy vấn Trade_id từ Giao dịch kết quả thương mại được sử dụng ở bước 3. Xác minh rằng giao dịch hoàn thành Khung 1 và bắt đầu thực hiện Khung 2. Ghi lại hs_qty và xác minh rằng nó được đặt thành 0.

Trường hợp sử dụng A, trong trường hợp S4 dừng ở Khung 2 rồi quay lại trong khi S3 hoàn thành:
6A. Từ S3, lặp lại việc thực thi Khung 1 và tạm dừng lại giữa Khung 1 và Khung 2. Viết hs_qty và kiểm tra xem giá trị của nó có được đặt thành 0 hay không.
7A. Tiếp tục thực thi S3 trên Khung 2. Xác minh rằng các Khung còn lại hoàn tất thành công.
8A. Kiểm tra xem S4 đã được bơm ra chưa.




6C. Nếu tình huống như vậy xảy ra, bài kiểm tra được coi là không hợp lệ. Để kiểm tra chính xác khả năng bảo vệ đọc ảo, phiên S4 cần phải đạt đến điểm trong Khung 2 của Giao dịch kết quả giao dịch khi một hàng mới được thêm vào bảng HOLDING_SUMMARY. Có thể cần phải sửa đổi Giao dịch Kết quả Thương mại được sử dụng cho S4 để tránh bị chặn trong Khung 1. Ví dụ: nó có thể được chạy ở mức cách ly Giao dịch Tùy ý thấp hơn.

Lưu ý 1: Kiểm tra P3 đạt nếu xảy ra Trường hợp A hoặc B. Và nó thất bại nếu xảy ra Trường hợp C. Có thể có các tùy chọn hợp lệ khác (ví dụ: cả S3 và S4 đều có thể thất bại), nhưng nếu cả S3 và S4 đều ghi hs_qty = 0 trong quá trình thực thi Khung 1 thì tối đa một trong các Phiên này có thể hoàn thành bình thường và thực hiện Giao dịch. Mục đích của thử nghiệm này là để chứng minh rằng trong mọi trường hợp, nếu S3 đọc lại bảng HOLDING_SUMMARY sau khi S4 đã thêm (hoặc cố gắng thêm) một hàng mới cho các tham số acct_id và ký hiệu đã chọn thì vẫn không tìm thấy hàng phù hợp trong S3.
Lưu ý 2: bài kiểm tra này sự cô lập tạo ra một hoặc nhiều tài sản mới. Việc thực hiện Kiểm tra P2 sau đó ở chế độ Đọc-Ghi (xem đoạn 7.4.2.2) cho cùng các tham số đã chọn acct_id và ký hiệu có thể dẫn đến việc đóng vị trí được tạo trong quá trình kiểm tra này.

7.4.2.2 Kiểm tra P2 ở chế độ Đọc-Ghi

Thử nghiệm này cho thấy rằng Giao dịch đọc-ghi kết quả giao dịch, trong khi thực hiện đồng thời một Giao dịch đọc-ghi kết quả giao dịch khác, được bảo vệ khỏi hiện tượng Đọc không lặp lại P2. Giao dịch Kết quả Thương mại thứ hai (Phần S4 bên dưới) hoạt động như một Giao dịch Ngẫu nhiên cập nhật hàng trong bảng HOLDING_SUMMARY đã được Giao dịch Kết quả Giao dịch đầu tiên đọc (Phần S3 bên dưới).

Với mục đích thử nghiệm này, hai Giao dịch Kết quả Thương mại này phải được chuẩn bị để thực thi bản ghi hs_qty khi quay về từ Khung 1. Ngoài ra, Giao dịch Kết quả Thương mại do S3 thực hiện phải có khả năng lặp lại việc thực hiện Khung 1 và tạm dừng việc thực thi của nó trước khi Frame bắt đầu thực thi 2.

Sử dụng bốn Phiên S1 đến S4, các bước sau đây được thực hiện theo thứ tự thích hợp.
1. Từ S1 chọn acct_id. Với giao dịch được chỉ định ở chế độ chỉ đọc, hãy tìm giá trị ký hiệu có hàng tương ứng trong bảng HOLDING_SUMMARY cho acct_id đã chọn, ghi lại HS_QTY cho nội dung đó và cam kết.

2. Từ S1, yêu cầu và hoàn tất thành công Giao dịch đặt hàng giao dịch với thông số acct_id và ký hiệu được chọn ở bước 1. Ghi lại thông số Trade_id được liên kết với các giao dịch này.

3. Từ S2, yêu cầu và hoàn thành thành công một Giao dịch đặt hàng giao dịch khác với thông số acct_id và ký hiệu được sử dụng ở bước 2. Ghi lại thông số Trade_id được liên kết với các giao dịch này.

4. Từ S3, yêu cầu Giao dịch kết quả thương mại với thông số Trade_id thu được ở bước 2 và tạm dừng thực thi giữa Khung 1 và Khung 2. Ghi lại hs_qty và kiểm tra xem nó có bằng HS_QTY thu được ở bước 1 hay không.

5. Từ S4, yêu cầu Giao dịch kết quả thương mại với thông số Trade_id thu được ở bước 3. Kiểm tra xem nó có hoàn thành Khung 1 và bắt đầu thực hiện Khung 2 hay không. Viết hs_qty và kiểm tra xem nó có bằng HS_QTY thu được ở bước 1 hay không.

Trường hợp sử dụng A, nếu S4 dừng ở Khung 2, sau đó quay lại trong khi S3 hoàn thành:
6A. Từ S3, gọi lại Khung 1 và tạm dừng lại giữa Khung 1 và 2. Ghi lại hs_qty và kiểm tra xem nó có bằng HS_QTY thu được ở bước 1 hay không.
7A. Tiếp tục thực thi S3 bằng cách gọi Khung 2. Kiểm tra xem các Khung còn lại có thực thi thành công hay không.
8A. Kiểm tra xem S4 đã được bơm ra chưa.
Trường hợp sử dụng B, trong trường hợp S4 chấm dứt (có thể sau khi dừng) và S3 được khôi phục:
6B. Xác minh rằng S4 hoàn thành việc thực thi Khung 2 và các Khung còn lại.
7B. Kiểm tra xem S3 đã được tải xuống chưa.
Trường hợp C nếu S4 dừng ở Frame 1 (không đúng):
6C. Nếu tình huống như vậy xảy ra, bài kiểm tra được coi là không hợp lệ. Để kiểm tra chính xác tính bảo mật đối với sự kiện Đọc không lặp lại P2, phiên S4 cần phải đạt đến thời điểm trong Khung 2 của Giao dịch kết quả giao dịch khi một trong các hàng được cập nhật trong bảng HOLDING_SUMMARY. Có thể cần phải sửa đổi Giao dịch Kết quả Thương mại được sử dụng cho S4 để tránh bị chặn trong Khung 1. Ví dụ: nó có thể được chạy ở mức cách ly Giao dịch Tùy ý thấp hơn.

Lưu ý: Thử nghiệm này đạt nếu xảy ra Trường hợp A hoặc B. Và nó không thành công nếu xảy ra Trường hợp C. Có thể có các tùy chọn hợp lệ khác (ví dụ: cả S3 và S4 đều có thể thất bại), nhưng nếu S3 và S4 ghi cùng một giá trị hs_qty trong quá trình việc thực thi Khung 1 thì tối đa một trong các Phiên này có thể hoàn thành bình thường và thực hiện Giao dịch. Mục đích của thử nghiệm này là để chứng minh rằng trong bất kỳ điều kiện nào, khi S3 lặp lại việc đọc bảng HOLDING_SUMMARY đã cho acct_id và ký hiệu thì hàng và giá trị được tìm thấy sẽ giống như trong bước 1.


7.4.2.3 Kiểm tra P1 ở chế độ Đọc-Ghi

Thử nghiệm này cho thấy rằng Giao dịch đọc-ghi kết quả giao dịch, trong khi một Giao dịch đọc-ghi kết quả giao dịch khác đang thực hiện đồng thời, được bảo vệ khỏi sự kiện đọc bẩn P1. Để của thử nghiệm này Giao dịch Kết quả giao dịch phải được định cấu hình để thực thi bản ghi se_amount khi trả về từ Khung 5 và phải có khả năng tạm dừng thực thi trong Khung 6 ngay trước khi cam kết.

Sử dụng ba Phiên S1 đến S3 theo thứ tự thích hợp, các bước sau được thực hiện

1. Từ S1, gọi Giao dịch vị trí khách hàng trên tham số cust_id đã chọn, hoàn thành Giao dịch và ghi lại tập hợp tham số cuối cùng acct_id và cash_ball.

2. Từ S1, gọi và hoàn tất thành công Giao dịch đặt lệnh giao dịch với tham số acct_id được chọn từ tập hợp được ghi ở bước 1 của tham số đã cho ký hiệu và với type_is_margin được đặt thành 0. Viết ra Trade_id được chỉ định cho các giao dịch này.

3. Từ S1, gọi và hoàn tất thành công một Giao dịch đặt hàng thương mại khác có cùng tham số acct_id nhưng tham số ký hiệu khác với tham số được sử dụng ở bước 2 và tham số type_is_margin được đặt thành 0. Ghi lại Trade_id được chỉ định cho các giao dịch này.

4. Từ S2, gọi Kết quả giao dịch giao dịch với tham số đầu vào Trade_id thu được ở bước 2. Trước khi gọi Khung 6, hãy viết se_amount, sau đó gọi Khung 6 và tạm dừng trước khi cam kết.

5. Từ S3, gọi Kết quả giao dịch giao dịch với tham số đầu vào Trade_id nhận được ở bước 3. Giao dịch có thể bị tạm dừng, có thể không hoàn tất thành công hoặc có thể tạm thời bị chặn thực hiện hoàn toàn. Nếu nó đến đầu Khung 6, hãy viết se_amount, sau đó gọi Khung 6. Nếu nó đến cuối Khung 6, hãy tạm dừng trước khi xác nhận.

6. Từ S2, tiếp tục xác nhận và hoàn tất Giao dịch thành công. Ghi lại giá trị kết quả của tham số acct_bal.

7. Từ S3, tùy thuộc vào hành vi giao dịch ở cuối bước 5:
Nếu nó bị tạm dừng ở Khung 6, hãy cho phép nó tiếp tục và kiểm tra xem nó đã được Xác nhận và hoàn thành thành công hay chưa.

Nếu nó bị chặn trước khi hoàn thành Khung 5, hãy kiểm tra xem nó đã được mở khóa chưa, đã hoàn thành Khung 5, viết se_amount, gọi là Khung 6, đã được Xác nhận và hoàn thành thành công.

Nếu nó không hoàn thành thành công và bị khôi phục, hãy gọi lại Giao dịch kết quả giao dịch với cùng thông số đầu vào Trade_id. Xác minh rằng Giao dịch Kết quả Thương mại được thực hiện hoàn toàn, ghi giá trị se_amount vào đầu Khung 6, cam kết ở cuối Khung 6 và hoàn tất thành công.

8. Từ S3, ghi lại acct_bal kết quả và kiểm tra xem nó có bằng giá trị cash_bal từ bước 1 hay không (sử dụng acct_id đã chọn ở bước 2) cộng với tổng se_amount đầu ra cho hai Giao dịch Kết quả Giao dịch này.

7.4.2.4 Kiểm tra P1 ở chế độ Đọc-Ghi

Thử nghiệm này cho thấy rằng Giao dịch Đọc-Ghi Vị trí Khách hàng trong quá trình thực hiện đồng thời Giao dịch Đọc-Ghi Kết quả Giao dịch được bảo vệ khỏi sự kiện đọc sai P1. Với mục đích thử nghiệm này, Giao dịch Kết quả Thương mại phải có khả năng tạm dừng thực hiện trong Khung 6 ngay trước khi xác nhận.

Sử dụng bốn Phiên S1 đến S4, các bước sau được thực hiện theo thứ tự thích hợp:

1. Từ S1, gọi Giao dịch vị trí khách hàng trên tham số cust_id đã chọn, hoàn thành Giao dịch và ghi lại tập hợp tham số cuối cùng acct_id và cash_ball.

2. Từ S1, gọi và hoàn tất thành công Giao dịch đặt hàng giao dịch trong đó tham số đầu vào tương ứng acct_id khớp với một trong các tham số acct_id được ghi ở bước 1 và giá trị của type_is_margin là 0. Ghi lại Trade_id được gán cho các giao dịch này.

3. Từ S2, gọi Kết quả giao dịch giao dịch với tham số đầu vào Trade_id nhận được ở bước 2, sau đó tạm dừng thực hiện trong Khung 6 trước khi cam kết.

4. Từ S3, gọi Giao dịch vị trí khách hàng với tham số đầu vào cust_id được chọn ở bước 1. Giao dịch có thể thành công hoặc thất bại hoặc có thể tạm thời bị chặn thực thi hoàn toàn.

5. Từ S2, tiếp tục tiếp tục và hoàn thành thành công Giao dịch kết quả giao dịch. Ghi lại acct_bal kết quả.

6. Từ S3 phụ thuộc vào hành vi của Giao dịch vị trí khách hàng ở cuối bước 4:

Nếu hoàn tất, hãy ghi lại tập hợp kết quả acct_id và cash_bal và kiểm tra xem giá trị cash_bal ​​cho acct_id được sử dụng ở bước 2 có không thay đổi so với bước đầu tiên hay không.

Nếu nó bị chặn, hãy kiểm tra xem nó đã hoàn tất chưa, ghi lại tập hợp acct_id và cash_bal kết quả và kiểm tra xem giá trị cash_bal cho acct_id đã cho được sử dụng ở bước 2 có khớp với acct_bal từ bước 5 hay không.

Nếu nó chưa được hoàn thành, hãy chuyển sang bước tiếp theo.

7. Từ S4, gọi Giao dịch Vị trí khách hàng với tham số cust_id đã chọn ở bước 1, hoàn tất Giao dịch, ghi lại tập hợp tham số kết quả acct_id và cash_bal và kiểm tra xem cash_bal cho acct_id đã cho được sử dụng ở bước 2 có thay đổi so với bước không 1 và phản ánh khối lượng giao dịch được thực hiện ở giai đoạn 5 (bằng cách so sánh với acct_bal từ giai đoạn 5).


7.5 Yêu cầu về độ ổn định

Hệ thống được thử nghiệm phải được cấu hình để đáp ứng các yêu cầu về độ bền được quy định trong điều khoản này. Hệ thống được thử nghiệm thể hiện các đặc tính ổn định trong trường hợp lưu Giao dịch đã được xác nhận và duy trì cấu trúc cơ sở dữ liệu sau các lỗi được liệt kê trong khoản 7.5.2. Kiểm tra khả năng phục hồi được thực hiện bằng cách gọi các lỗi thảm khốc và không thảm khốc trên các thành phần SUT. Các lỗi không nghiêm trọng, được mô tả trong điều 7.5.5, kiểm tra khả năng của SUT trong việc duy trì khả năng truy cập dữ liệu. Những lỗi nghiêm trọng được mô tả trong điều khoản 7.5.6 kiểm tra khả năng của SUT trong việc duy trì ảnh hưởng của Giao dịch được xác nhận. Khoảng thời gian ảnh hưởng của Thất bại thảm khốc được mô tả trong Báo cáo thử nghiệm là Thời gian phục hồi kinh doanh. Không một ai trong số họ hệ thống hiện có không mang lại sự ổn định tuyệt đối (tức là sự ổn định trong mọi tình huống lỗi). Tập hợp cụ thể các lỗi đơn lẻ được liệt kê trong Điều 7.5.2 được coi là biểu thị đầy đủ để khẳng định sự hiện diện của Khả năng phục hồi trong các trường hợp xảy ra các lỗi đó. Tuy nhiên, bản chất hạn chế của các thử nghiệm được trình bày không nên được hiểu là cho phép tồn tại các trường hợp lỗi đơn lẻ không thể phục hồi khác.

7.5.1 Định nghĩa các khái niệm

Tính sẵn sàng: Khả năng thực hiện các hoạt động cơ sở dữ liệu với toàn quyền truy cập dữ liệu sau một sự cố vĩnh viễn không thể phục hồi của bất kỳ ai Người vận chuyển thường trực chứa các bảng cơ sở dữ liệu, dữ liệu nhật ký khôi phục hoặc Siêu dữ liệu cơ sở dữ liệu. Xem Điều 7.5.2.1.

7.5.1.1 Khôi phục ứng dụng Thảm họa

7.5.1.2 Thời gian hồi phụcứng dụng: Thời gian trôi qua từ khi bắt đầu Khôi phục ứng dụng đến khi kết thúc (xem Điểm 0).

7.5.1.3 Phục hồi kinh doanh: Quá trình khôi phục ứng dụng doanh nghiệp sau Thảm họa lỗi hệ thống và đạt đến điểm mà doanh nghiệp đạt được các tiêu chí hoạt động nhất định.

7.5.1.4 Thời gian phục hồi kinh doanh: Thời gian trôi qua từ khi bắt đầu Khôi phục ứng dụng đến khi kết thúc (xem Điều 7.5.6.8).

7.5.1.5 Thảm họa: Một loại lỗi trong đó quá trình xử lý bị gián đoạn mà không có cảnh báo từ SUT. Sau lỗi này, chỉ đối với cơ sở dữ liệu bị lỗi, tất cả bộ nhớ sẽ bị xóa và tất cả bối cảnh ứng dụng đang hoạt động đều bị mất.

7.5.1.6 Đã xác nhận: Giao dịch được xác nhận khi các hành động của nó (Thêm, xóa, sửa đổi) là vĩnh viễn và hiển thị đối với các Giao dịch khác

7.5.1.7 Lưu ý: Các giao dịch có thể được thực hiện mà sau đó Trình điều khiển không được thông báo về thực tế này, vì tính toàn vẹn của thông báo là không cần thiết.

7.5.1.8.Phục hồi cơ sở dữ liệu: Quá trình khôi phục cơ sở dữ liệu sau lỗi hệ thống thảm khốc.

7.5.1.9 Thời gian khôi phục cơ sở dữ liệu: Thời lượng từ đầu Phục hồi cơ sở dữ liệu cho đến khi các tập tin cơ sở dữ liệu được khôi phục hoàn toàn.

Yêu cầu đánh giá tính bền vững: các điều kiện mà SUT phải đáp ứng trong tất cả các thử nghiệm Độ ổn định (xem Điều 7.5.3)

7.5.1.10 Mạnh mẽ: Trạng thái có thể chịu được lỗi (như được mô tả trong Điều 7.5.2) và có ngữ nghĩa cập nhật giao dịch.

7.5.1.11 Người vận chuyển thường trực: Lưu trữ dữ liệu ổn định, ổn định như đĩa từ hoặc băng từ.

7.5.1.12 Ý tưởng Không thảm họađề cập đến một lỗi duy nhất không làm gián đoạn quá trình xử lý nhưng có thể làm giảm hiệu suất và khiến SUT không còn ở trạng thái ổn định cho đến khi nó phục hồi sau lỗi.

7.5.2 Điểm thất bại duy nhất
Những điểm sau đây mô tả các thành phần riêng lẻ SUT được thử nghiệm bằng các sự cố Không thảm khốc và Thất bại thảm khốc được mô tả trong khoản 7.5.5 và 7.5.6. Các điểm lỗi duy nhất áp dụng cho các thành phần SUT cần thiết để đáp ứng các yêu cầu về Khả năng phục hồi.

Đơn vị tổ chức thử nghiệm có thể áp dụng một thử nghiệm duy nhất để thực hiện thử nghiệm khả năng phục hồi trên nhiều điểm lỗi duy nhất (ví dụ: có thể áp dụng một "kiểm tra lỗi toàn hệ thống" cho ba điểm lỗi được mô tả trong Điều 7.5.2.2, 7.5.2.3 và 7.5 .2.4 ).

7.5.2.1 Lỗi vĩnh viễn không thể phục hồi của một trong các phương tiện Persistent.

7.5.2.2 Nghỉ ngay lập tức(lỗi hệ thống/hệ thống bị treo) trong quá trình xử lý, yêu cầu khởi động lại hệ thống để khôi phục.
Lưu ý: Điều này cũng có nghĩa chấm dứt sai công việc yêu cầu tải xuống một bản sao mới Hệ điều hành Với thiết bị khởi động. Nó không nhất thiết có nghĩa là mất dữ liệu trong bộ nhớ cố định. Một ví dụ về cơ chế khắc phục sự kiện hủy bỏ tức thời trong quá trình xử lý là Nhật ký Hoàn tác/Làm lại.

7.5.2.3 Lỗi toàn bộ không gian bộ nhớ(mất nội dung).
Lưu ý: Điều này giả định rằng tất cả dung lượng bộ nhớ đã bị lỗi. Điều này có thể xảy ra do mất nguồn cung cấp cung cấp điện bên ngoài hoặc hỏng bo mạch bộ nhớ vĩnh viễn.

7.5.2.4 Ngắt nguồn điện bên ngoài tới SUT trong một khoảng thời gian không xác định (mất điện). Điều này phải bao gồm ít nhất tất cả các phần của SUT có liên quan đến các bước làm việc Giao dịch cơ sở dữ liệu.

Lưu ý: Có thể đáp ứng các yêu cầu về bảo vệ khi mất điện bằng cách sử dụng đủ UPS để đảm bảo tính khả dụng của tất cả các bộ phận gặp sự cố mất điện ở phía hệ thống trong vòng 30 phút. Việc sử dụng cấu hình được bảo vệ của UPS sẽ không tạo ra các điểm lỗi mới mà không được các phần khác của cấu hình bảo vệ. Tuyên bố này có thể được chứng minh bằng cách đo hoặc tính toán mức tiêu thụ điện trong 30 phút (tính bằng Watt) của phần được bảo vệ của SUT, nhân với 1,4.

7.5.3 Yêu cầu đánh giá độ ổn định.

Tất cả các bài kiểm tra Độ ổn định phải đáp ứng các yêu cầu sau:

  • trong Khoảng thời gian đo được thực hiện với cùng số lượng Người dùng được định cấu hình và Tải trình điều khiển
  • xảy ra ở trạng thái ổn định
  • đáp ứng các hạn chế về Thời gian đáp ứng được nêu trong khoản 6.5.1.7.
  • đáp ứng các yêu cầu về Kết hợp các Giao dịch được liệt kê trong khoản 6.3.1.
  • được thực thi ở giá trị hiệu suất từ ​​95% trở lên của Báo cáo mà không có lỗi
  • khớp với tất cả các cài đặt cấu hình Trình điều khiển và SUT được áp dụng trong Khoảng thời gian đo.
7.5.4 Nhiều phiên bản của Hệ điều hành

7.5.4.1 Trong các cấu hình trong đó các chức năng đo điểm chuẩn tương tự được thực hiện bởi nhiều phiên bản của Hệ điều hành, các thử nghiệm lỗi được liệt kê trong khoản 7.5.2 phải được thực hiện trên ít nhất một trong các phiên bản đó.

7.5.4.2 Nếu nhiều phiên bản của Hệ điều hành quản lý dữ liệu được xử lý dưới dạng một hình ảnh theo quan điểm của các ứng dụng đo điểm chuẩn (ví dụ: cụm cơ sở dữ liệu), thì kiểm tra Lỗi nguồn cũng phải được chạy đồng thời trên tất cả các phiên bản của Hệ điều hành. những trường hợp này.

Lưu ý: Sự cố mất điện của nhiều trường hợp trong SUT phải xảy ra trong vòng 3 giây để tạo ra sự khác biệt trong kết quả của quy trình thủ công có thể được sử dụng để hoàn thành bài kiểm tra.

7.5.4.3 Nếu có nhiều phiên bản của Hệ điều hành quản lý dữ liệu được xử lý trong ứng dụng điểm chuẩn dưới dạng một hình ảnh duy nhất và được kết nối bằng Phương tiện vật lý không phải là bus nhúng (ví dụ: cáp mở rộng bus, mạng LAN tốc độ cao hoặc phương pháp cung cấp liên lạc khác giữa nhiều phiên bản của Hệ điều hành có thể bị gián đoạn vật lý), bao gồm cả sự gián đoạn tức thời của hoạt động liên lạc đó trong danh mục đối tượng phải kiểm tra theo khoản 7.5.2.2. Chỉ một trong các trường hợp kết nối sử dụng dự phòng cần được kiểm tra lỗi.

Lưu ý: đoạn này không nhằm mục đích thiết lập yêu cầu chấm dứt kết nối với bộ lưu trữ đĩa hoặc hệ thống con đĩa với sự dư thừa.

7.5.5 Sự cố không nghiêm trọng

Lỗi không nghiêm trọng là lỗi không làm mất dữ liệu được lưu trong bộ nhớ SUT hoặc không yêu cầu tải xuống mới Hệ điều hành từ thiết bị khởi động. Các lỗi không nghiêm trọng được mô tả trong đoạn này có tác động đến quyền truy cập vào dữ liệu được lưu trữ trên Persistent Media. Những yêu cầu này còn được gọi là yêu cầu về Tính sẵn có của Dữ liệu.

7.5.5.1 SUT sẽ duy trì quyền truy cập vào dữ liệu trên Phương tiện liên tục trong và sau lỗi được xác định trong điều khoản 7.5.2.1 (lỗi vĩnh viễn không thể khôi phục của bất kỳ Phương tiện liên tục nào chứa bảng cơ sở dữ liệu, dữ liệu nhật ký khôi phục hoặc Siêu dữ liệu cơ sở dữ liệu). Người tổ chức kiểm tra cũng phải khôi phục môi trường Persistent Media về trạng thái trước khi xảy ra lỗi trong khi vẫn duy trì khả năng truy cập dữ liệu trên Persistent Media.

7.5.5.2 Phương tiện liên tục có thể là phương tiện ổn định hoặc không ổn định được cấu hình phù hợp để đáp ứng các yêu cầu của khoản 7.5.2.1. Phương tiện truyền thông không bay hơi thường đĩa từ, sử dụng bản sao (sao chép RAID-1) hoặc các phương pháp bảo vệ khác (RAID-5, v.v.) để đảm bảo quyền truy cập vào dữ liệu khi xảy ra lỗi Phương tiện liên tục. Phương tiện dễ bay hơi, chẳng hạn như bộ nhớ, có thể được sử dụng ở nơi phương tiện dễ bay hơi có thể cung cấp khả năng truyền dữ liệu tự động trước khi bất kỳ dữ liệu nào bị mất vào phương tiện không khả biến sau khi mất điện, bất kể khi nào có điện trở lại.

Lưu ý 1: Nguồn được cấu hình và đánh giá Nguồn điện liên tục(UPS) không được tính nguồn bên ngoài dinh dưỡng.

Lưu ý 2: Bộ nhớ có thể được coi là Bộ lưu trữ vĩnh viễn nếu nó có thể lưu giữ dữ liệu đủ lâu để đáp ứng các yêu cầu được mô tả ở trên, ví dụ: nếu nó được bổ sung Nguồn điện liên tục và nội dung của bộ nhớ có thể được chuyển hướng đến bộ lưu trữ cố định tại khoảnh khắc thất bại. Cần lưu ý rằng không có sự phân biệt nào giữa bộ nhớ chính và bộ nhớ thực hiện các chức năng lưu trữ tạm thời hoặc vĩnh viễn tương tự trong các phần khác của hệ thống (ví dụ: bộ nhớ đệm của bộ điều khiển đĩa). Nếu bộ nhớ chính được sử dụng làm phương tiện liên tục thì nó phải được coi là một điểm lỗi tiềm ẩn. Một ví dụ về giải pháp cho một lỗi phương tiện Liên tục là phản chiếu phương tiện Liên tục.

Nếu bộ nhớ là phương tiện cố định và việc sao chép được sử dụng để đảm bảo sự ổn định thì ngân hàng bộ nhớ được phản chiếu phải có nguồn điện độc lập.

7.5.5.3 Kiểm tra tính sẵn có của dữ liệu (còn gọi là Kiểm tra lỗi không thảm khốc) phải tuân thủ các Yêu cầu đánh giá khả năng phục hồi trong điều khoản 7.5.3.

7.5.5.4 Mức độ dự phòng
Mức dự phòng biểu thị mức độ đảm bảo tính khả dụng của dữ liệu trong trường hợp xảy ra lỗi duy nhất trong các thành phần lưu trữ dữ liệu. SUT phải sử dụng một trong cấp độ tiếp theo Sự dư thừa:

  • Dự phòng cấp 1 (Dự phòng phương tiện liên tục): Đảm bảo quyền truy cập vào dữ liệu trên Phương tiện liên tục trong trường hợp xảy ra lỗi trên một trong các Phương tiện liên tục.
Lưu ý: nhiệm vụ cấp độ này dự phòng là để kiểm tra môi trường phương tiện Liên tục nhằm chống lại lỗi của một trong các phương tiện Liên tục và tiếp tục xử lý các yêu cầu từ Hệ điều hành và/hoặc DBMS.

Ví dụ: Người tổ chức thử nghiệm đã triển khai việc sử dụng RAID-1 (sao chép) trên các đĩa trong bộ lưu trữ. Trong trường hợp xảy ra lỗi trên một trong các đĩa, Ban tổ chức phải cung cấp quyền truy cập vào dữ liệu trên tất cả các đĩa còn lại.

  • Dự phòng cấp 2 (Dự phòng bộ điều khiển phương tiện liên tục): Cho phép Dự phòng cấp 1 và đảm bảo quyền truy cập vào dữ liệu trên Phương tiện liên tục khi xảy ra lỗi duy nhất trong bộ điều khiển lưu trữ được sử dụng để đạt được mức dự phòng hoặc trong giao tiếp giữa bộ điều khiển lưu trữ và Persistent Phương tiện truyền thông.
Lưu ý: Mục đích của mức độ dư thừa này là để kiểm tra khả năng Đề án đã thực hiện tồn tại sau sự cố của bộ điều khiển lưu trữ thực hiện Dự phòng cấp 1.

Ví dụ: Nếu Đạt được Dự phòng Cấp 1 bằng cách triển khai bảo vệ RAID-5 trên đĩa thì Dự phòng Cấp 2 sẽ được kiểm tra bằng cách hỏng phần cứng được sử dụng để triển khai bảo vệ RAID-5.

Nếu bộ điều khiển triển khai RAID-5 được chứa trong cấu trúc đĩa (hoặc thiết bị gắn bên ngoài tương tự), thì Ban tổ chức phải chứng minh rằng nó vẫn có thể truy cập dữ liệu được lưu trữ trong cấu trúc.

Nếu bộ điều khiển triển khai RAID-5 được đặt tách biệt với vỏ chứa các đĩa và bộ điều khiển không được sử dụng làm phương tiện liên tục (ví dụ: bộ nhớ đệm ghi được phản chiếu), thì việc ngắt kết nối giữa bộ điều khiển và bộ điều khiển là đủ. cấu trúc đĩa.

  • Dự phòng cấp 3 (Dự phòng hoàn toàn): Cho phép Dự phòng cấp 2 và đảm bảo quyền truy cập vào dữ liệu trên Persistent Media khi xảy ra một lỗi duy nhất trong hệ thống Persistent Media, bao gồm các liên kết giữa Lớp B và hệ thống Persistent Media.
Lưu ý 1: Hệ thống Persistent Media chứa tất cả các thành phần cần thiết để đáp ứng các yêu cầu về tính bền vững được mô tả ở trên. Điều này không bao gồm hệ thống Cấp B hoặc bus hệ thống, nhưng bao gồm một bộ chuyển đổi cho xe buýt hệ thống và tất cả các thành phần nằm “bên dưới” bộ chuyển đổi.

Lưu ý 2: Mục đích của điều khoản này là để kiểm tra khả năng của hệ thống Cấp B trong việc chống lại các lỗi của các thành phần và tiếp tục xử lý Giao dịch.

Lưu ý: Các thành phần được thử nghiệm trong đoạn này được coi là các mô-đun có thể thay thế nhanh chóng. Mục đích của điều khoản này không phải là yêu cầu Ban tổ chức kiểm tra tính ổn định của bảng nối đa năng trong việc lưu trữ Persistent Media hoặc các thành phần không thể thay thế tương tự. Đồng thời, nhiệm vụ kiểm tra bao gồm kiểm tra đặc tính chịu lỗi của bộ điều khiển lưu trữ, bao gồm bộ nhớ đệm được nhân bản trên bộ điều khiển và phần mềm tương ứng.

7.5.5.5 Quy trình kiểm tra độ chắc chắn về tính sẵn có của dữ liệu

1. Xác định số lượng giao dịch đã hoàn thành hiện tại trong cơ sở dữ liệu bằng cách chạy truy vấn:
chọn số(*) là số1 từ KẾT LUẬN

2. Bắt đầu gửi Giao dịch để xử lý và tăng hiệu suất lên mức Yêu cầu đánh giá khả năng phục hồi (như được mô tả trong khoản 7.5.3) và duy trì ở cấp độ này trong ít nhất 5 phút.

Lưu ý: Sau khi đáp ứng các Yêu cầu Đánh giá Độ ổn định:

  • Mọi thay đổi đối với cấu hình Trình điều khiển đều bị cấm cho đến khi hoàn thành giai đoạn 5
  • Mọi thay đổi đối với cấu hình SUT đều bị cấm ngoại trừ những thay đổi cần thiết để hoàn thành bước 3 và 4.
3. Không thể xác minh mức độ dư thừa nếu cần thiết.

4. Bắt đầu thủ tục cần thiết sự hồi phục.

5. Tiếp tục chạy Trình điều khiển trong 20 phút.

6. Chấm dứt thực thi chính xác từ Trình điều khiển.

7. Nhận số lượng giao dịch đã hoàn thành mới trong cơ sở dữ liệu bằng cách chạy:



8. So sánh số lượng Giao dịch Kết quả Giao dịch được Tài xế thực hiện với giá trị
(đếm2 - đếm1). Kiểm tra xem (count2 - count1) có bằng số lượng mục nhập của Giao dịch Kết quả Giao dịch thành công trong tệp nhật ký Trình điều khiển hay không.

9. Cho phép quá trình khôi phục hoàn tất như mong đợi.

7.5.6 Sự cố thảm khốc.

Một số lỗi có thể mang tính chất thảm khốc và trong những trường hợp như vậy, quyền truy cập vào dữ liệu sẽ bị mất. SUT phải có khả năng lưu trạng thái của cơ sở dữ liệu và khôi phục quyền truy cập vào dữ liệu trong thời gian ngắn nhất.
Thất bại thảm hại có tính chất đột ngột và không thể đoán trước, thường dẫn đến những tổn thất không lường trước được trong quá trình xử lý giao dịch. Các yêu cầu trong điều khoản này kiểm tra khả năng của SUT trong việc duy trì hậu quả của Giao dịch được xác nhận. Vì khả năng xử lý các giao dịch là yếu tố then chốt trong môi trường OLTP nên Người tổ chức kiểm thử phải đo lường và báo cáo thời gian để DBMS phục hồi sau các lỗi thảm khốc. Thời gian phục hồi này được gọi là Thời gian phục hồi kinh doanh.
Lưu ý: Thất bại thảm khốc là sự gián đoạn lớn đối với quy trình kinh doanh, do đó doanh nghiệp bắt buộc phải phục hồi sau những thất bại đó càng nhanh càng tốt. Có nhiều thông lệ và thông lệ cấu hình cơ sở dữ liệu ảnh hưởng trực tiếp đến hiệu suất của DBMS và thời gian phục hồi của nó sau một sự cố thảm khốc. Mặc dù mọi người đều biết rằng thời gian tải hệ thống khác nhau có thể thay đổi trong một phạm vi rất lớn, các tham số tải có ảnh hưởng rất nhỏ đến hiệu suất của DBMS và không nằm trong Thời gian khôi phục doanh nghiệp.


7.5.6.1 Thử nghiệm sự cố thảm khốc phải tuân thủ các Yêu cầu đánh giá khả năng phục hồi được đưa ra trong Điều 7.5.3.

7.5.6.2 Triển khai hình ảnh khôi phục từ bản sao lưu trữ cơ sở dữ liệu (ví dụ: một bản sao được tạo trước khi thực thi), việc sử dụng dữ liệu nhật ký Khôi phục/Hoàn tác không được chấp nhận làm cơ chế khôi phục cho các lỗi được liệt kê trong các điều khoản 7.5.2.2, 7.5.2.3 và 7.5.2.4. Cần lưu ý rằng Điểm kiểm soát, Cơ sở dữ liệu Điểm xác thực, Điểm trình tự (và tương tự) được tạo trong khi công việc đang chạy không được coi là dữ liệu đã lưu trữ.

7.5.6.3 Nếu cơ chế khôi phục dựa vào nội dung của bộ nhớ khả biến trước khi xảy ra lỗi thì phương tiện được sử dụng để tránh mất nội dung của bộ nhớ khả biến (ví dụ: Nguồn cung cấp điện liên tục) phải được tính đến khi tính toán chi phí của hệ thống (xem điều 8.3.1.3).

7.5.6.4 Thời điểm bắt đầu khôi phục cơ sở dữ liệu là thời điểm các tệp cơ sở dữ liệu được truy cập lần đầu tiên bởi một quy trình có hiểu biết về nội dung của các tệp đó và có ý định khôi phục cơ sở dữ liệu hoặc thực hiện các Giao dịch hoạt động trên cơ sở dữ liệu.

Lưu ý: truy cập vào các tệp theo quy trình của Hệ điều hành để kiểm tra tính toàn vẹn hệ thống tập tin hoặc khối lượng để sửa lỗi trong cấu trúc dữ liệu không có nghĩa là bắt đầu Khôi phục cơ sở dữ liệu.

7.5.6.5 Quá trình khôi phục cơ sở dữ liệu Kết thúc là thời điểm các tệp cơ sở dữ liệu đã được khôi phục.

Lưu ý: Thông thường cơ sở dữ liệu sẽ chỉ ra thời điểm này trong tệp nhật ký của nó.

7.5.6.6 Bắt đầu Khôi phục Ứng dụng là thời điểm Giao dịch đầu tiên được gửi sau khi bắt đầu Khôi phục Cơ sở dữ liệu.

7.5.6.7 Kết thúc quá trình khôi phục ứng dụng là thời điểm mà SUT bắt đầu hoạt động với hiệu suất lớn hơn hoặc bằng 95% so với mức được báo cáo và tiếp tục hoạt động như vậy trong ít nhất 20 phút.

7.5.6.8 Quy trình thử nghiệm đối với các hư hỏng thảm khốc

1. Xác định số lượng giao dịch đã hoàn thành hiện tại trong cơ sở dữ liệu bằng cách chạy:
chọn số(*) là số1 từ QUYẾT ĐỊNH.

2. Bắt đầu thực hiện Giao dịch và tăng hiệu suất lên mức Yêu cầu đánh giá khả năng phục hồi (như được mô tả trong khoản 7.5.3) và tuân thủ các yêu cầu này trong ít nhất 20 phút.

3. Thực hiện một hoặc nhiều Lỗi nghiêm trọng từ đoạn 7.5.2.2, 7.5.2.3 hoặc 7.5.2.4.

4. Nếu nó khớp cấu hình thử nghiệm, ngừng gửi Giao dịch.

5. Nếu cần, hãy khởi động lại SUT (có thể phải khởi động lại cứng).

6. Đánh dấu thời điểm bắt đầu Khôi phục cơ sở dữ liệu (xem đoạn 7.5.6.4), do người vận hành thực hiện tự động hoặc thủ công.

7. Khi quy trình Khôi phục cơ sở dữ liệu kết thúc, hãy ghi lại thời gian. Điều này có thể xảy ra trong thời gian bước tiếp theo(xem đoạn 7.5.6.5).

8. Bắt đầu Thực hiện Kiểm tra 2 hoặc tiếp tục gửi Giao dịch và đánh dấu thời điểm này là thời điểm bắt đầu Khôi phục Ứng dụng (xem Điều 7.5.6.6). Tăng năng suất lên 95% Năng suất được báo cáo.

Lưu ý: Nếu có khoảng cách thời gian giữa thời điểm kết thúc Khôi phục cơ sở dữ liệu và thời điểm bắt đầu Khôi phục ứng dụng, đồng thời nếu Trình điều khiển và Giao dịch cần được khởi động lại (thay vì chỉ tiếp tục) thì Giao dịch dọn dẹp thương mại có thể được bắt đầu trong khoảng thời gian này.

9. Đánh dấu sự kết thúc của quá trình Khôi phục ứng dụng, như được mô tả trong đoạn 7.5.6.7.

10. Tắt Driver đúng cách.

11. Kiểm tra xem Trình điều khiển chưa báo bất kỳ lỗi nào trong các bước từ 7 đến 10. Điều này nhằm đảm bảo rằng người dùng cuối sẽ không chứng kiến ​​bất kỳ tác động tiêu cực(ngoài tính khả dụng của ứng dụng và khả năng giảm hiệu suất) do lỗi SUT và quá trình Khôi phục Doanh nghiệp sau đó.

12. Nhận số lượng giao dịch đã hoàn thành mới trong cơ sở dữ liệu bằng cách chạy:
chọn số(*) là số2 từ KHOẢN GIẢI QUYẾT

13. So sánh số lượng Giao dịch Kết quả Thương mại được Người lái xe hoàn thành với giá trị (count2 - count1). Xác minh rằng (count2 - count1) lớn hơn hoặc bằng tổng số mục nhập Giao dịch Kết quả Thương mại thành công trong tệp nhật ký Trình điều khiển liên quan đến các lần chạy được thực hiện trong giai đoạn 2 và giai đoạn 7.
Nếu có sự bất đẳng thức thì bảng GIẢI QUYẾT phải chứa mục bổ sung và sự khác biệt phải nhỏ hơn hoặc bằng Số lớn nhất Các giao dịch có thể đồng thời đang trong quá trình được chuyển từ Trình điều khiển sang SUT. Con số này liên quan đến việc triển khai Driver và cài đặt cấu hình tại thời điểm xảy ra lỗi.

Lưu ý: Sự khác biệt này chỉ tồn tại do các Giao dịch được cam kết trên Hệ thống đang được kiểm tra, mặc dù vậy, không có đầu ra nào được trả về Trình điều khiển trước khi thất bại.

14. Kiểm tra các điều kiện trình tự như quy định tại Điều 7.3.3.

15. Tính Thời gian khôi phục doanh nghiệp bằng tổng của Thời gian khôi phục ứng dụng và Thời gian khôi phục cơ sở dữ liệu, trừ khi các khoảng thời gian này trùng nhau. Nếu Quá trình khôi phục ứng dụng bắt đầu trước khi kết thúc quá trình Khôi phục cơ sở dữ liệu thì Thời gian khôi phục doanh nghiệp là khoảng thời gian trôi qua từ khi bắt đầu Khôi phục cơ sở dữ liệu đến khi kết thúc Khôi phục ứng dụng.

7.5.7 Yêu cầu báo cáo bền vững.

7.5.7.1 Người tổ chức kiểm tra phải mô tả Mức độ dư thừa và mô tả (các) bài kiểm tra được sử dụng để chứng minh sự tuân thủ trong Báo cáo.

7.5.7.2 Biểu đồ sẵn có dữ liệu
Báo cáo phải trình bày biểu đồ Hiệu suất được đo lường so với thời gian đã trôi qua đối với các đoạn thực hiện Kiểm tra tính khả dụng của dữ liệu, được chuẩn bị theo các quy ước sau:

  • Trục X biểu thị thời gian đã trôi qua của các lần chạy thử được mô tả trong Điều 7.5.5.5, cho các giai đoạn 2 đến 6
  • Trục Y biểu thị hiệu suất được biểu thị bằng tpsE
Lưu ý: Mục đích là để chứng minh tác động của quy trình khôi phục đến hiệu suất.

7.5.7.3 Báo cáo đánh giá
Thời gian phục hồi hoạt động kinh doanh phải được nêu rõ trong Lệnh thực thi cuối cùng và trong Báo cáo. Nếu các lỗi được mô tả trong Điều 7.5.2.2, 7.5.2.3 và 7.5.2.4 không được kết hợp thành một thử nghiệm Khả năng phục hồi duy nhất (thường bằng cách cắt điện Máy chủ cơ sở dữ liệu trong khi thực thi), thì Thời gian khôi phục doanh nghiệp cho lỗi được mô tả cho ngừng hoạt động đột ngột là - đây là Thời gian phục hồi kinh doanh cần được đưa vào Lệnh thực thi cuối cùng. Tất cả các giá trị Thời gian khôi phục doanh nghiệp cho mỗi thử nghiệm yêu cầu Khôi phục doanh nghiệp phải được báo cáo trong Báo cáo.

7.5.7.4Dòng thời gian phục hồi kinh doanh
Báo cáo phải bao gồm biểu đồ Hiệu suất được đo lường so với thời gian đã trôi qua đối với các phân đoạn thực hiện kiểm tra Khôi phục hoạt động kinh doanh, được chuẩn bị theo các cách sắp xếp sau:
  • Trục X hiển thị thời gian trôi qua tối đa cho hai lần chạy thử được mô tả trong đoạn 7.5.6.8 cho giai đoạn 2 và 8
  • Trục Y biểu thị hiệu suất được biểu thị bằng tpsE
  • Nên sử dụng kích thước tỷ lệ đồ thị là 1 phút.
  • Dữ liệu trục Y phải được vẽ cho cả hai lần chạy trên cùng một biểu đồ, với điểm cuối của mỗi lần chạy được đánh dấu rõ ràng.
  • Với mục đích tạo biểu đồ, điểm tham chiếu bằng 0 được xác định như sau:
  • Đối với lần chạy được mô tả ở bước 2 trong điều khoản 7.5.6.8, điểm tham chiếu 0 được xác định là thời điểm mà Giao dịch đầu tiên được áp dụng cho cơ sở dữ liệu
  • Đối với lần chạy được mô tả ở bước 8 trong điều khoản 7.5.6.8, điểm tham chiếu 0 được xác định là thời điểm mà Quá trình khôi phục cơ sở dữ liệu bắt đầu.
  • Với mục đích tạo lịch trình, thời điểm kết thúc một lượt chạy được xác định như sau:
  • Đối với lần chạy được mô tả ở bước 2 trong điều khoản 7.5.6.8, kết thúc lần chạy là thời điểm xảy ra lỗi (xem bước 3 của điều khoản 7.5.6.8)
  • Đối với lần chạy được mô tả ở bước 8 trong điều khoản 7.5.6.8, kết thúc lần chạy là thời điểm Quá trình khôi phục ứng dụng hoàn tất thành công (xem bước 8 trong điều khoản 7.5.6.8)
  • Đối với quá trình chạy được mô tả ở bước 8 trong điều khoản 7.5.6.8, nếu có bất kỳ khoảng thời gian nào giữa thời điểm kết thúc quá trình Khôi phục cơ sở dữ liệu và thời điểm bắt đầu Khôi phục ứng dụng thì khoảng thời gian này sẽ được bỏ qua và hai khoảng thời gian đó phải được vẽ liền kề với mỗi khoảng thời gian. khác.










Không có gì bí mật khi có một quy tắc heuristic được xây dựng có tên là Định lý CAP, trái ngược với hệ thống RDBMS thông thường, lớp giải pháp NoSQL không thể cung cấp hỗ trợ đầy đủ ACID. Phải nói rằng đối với một số nhiệm vụ thì không cần đến điều này và việc hỗ trợ một trong các yếu tố dẫn đến sự thỏa hiệp trong việc giải quyết các nhiệm vụ khác, do đó - có rất nhiều giải pháp hiện có. Trong bài viết này, tôi muốn xem xét các phương pháp kiến ​​trúc khác nhau để giải quyết các vấn đề đáp ứng một phần yêu cầu của một hệ thống giao dịch.

Tính nguyên tử "A"

Tính nguyên tử đảm bảo rằng không có giao dịch nào được cam kết một phần với hệ thống. Hoặc tất cả các hoạt động phụ của nó sẽ được thực hiện hoặc không có hoạt động nào được thực hiện.

Hệ thống NoSQL thường được chọn hiệu suất cao không phải vì ngữ nghĩa giao dịch, vì việc tuân thủ nó sẽ phát sinh thêm chi phí xử lý. Nhiều hệ thống vẫn cung cấp bảo đảm cấp khóa hoặc cấp hàng (Google BigTable) hoặc cung cấp API hoạt động nguyên tử (Amazon DynamoDB), trong đó chỉ một luồng có thể sửa đổi bản ghi nếu, ví dụ: nếu bạn muốn bộ đếm lần truy cập của người dùng được phân phối trên toàn bộ cụm . Hầu hết các hệ thống đều tuân theo các vòng lặp đọc-sửa-ghi không chặn. Chu kỳ bao gồm ba giai đoạn- đọc giá trị, sửa đổi, viết. Như bạn có thể thấy, trong môi trường đa luồng, có rất nhiều điều có thể xảy ra sai sót, chẳng hạn như điều gì sẽ xảy ra nếu ai đó thay đổi bản ghi giữa giai đoạn đọc và ghi. Cơ chế chính để giải quyết những xung đột như vậy là sử dụng thuật toán So sánh và Hoán đổi - nếu ai đó thay đổi bản ghi trong chu trình - chúng ta phải hiểu rằng bản ghi đã thay đổi và lặp lại chu trình cho đến khi giá trị của chúng ta được thiết lập, thuật toán này có vẻ thích hợp hơn hoàn toàn. cơ chế chặn ghi. Số chu kỳ như vậy có thể rất lớn nên chúng ta cần một khoảng thời gian chờ nhất định cho thao tác, sau đó thao tác sẽ bị từ chối.

Tính nhất quán "C"

Một giao dịch đạt đến mức hoàn thành bình thường và do đó cam kết kết quả của nó sẽ duy trì tính nhất quán của cơ sở dữ liệu. Xem xét tính đặc hiệu của NoSQL đối với việc phân phối thông tin trên các máy chủ, điều này có nghĩa là liệu tất cả các bản sao chứa bản sao dữ liệu có luôn chứa cùng một phiên bản dữ liệu hay không

Do đặc thù của nó, NoSQL hiện đại phải chọn tính sẵn sàng cao và khả năng chia tỷ lệ ngang cụm - hóa ra là hệ thống không thể đảm bảo tính nhất quán dữ liệu hoàn chỉnh và đưa ra một số giả định trong việc xác định khái niệm tính nhất quán. Có hai cách tiếp cận:

Tính nhất quán chặt chẽ
Các hệ thống như vậy đảm bảo rằng các bản sao luôn có thể đồng ý về một phiên bản dữ liệu được trả về cho người dùng. Một số bản sao sẽ không chứa giá trị này, nhưng khi hệ thống xử lý yêu cầu về một giá trị theo khóa, máy sẽ luôn có thể quyết định giá trị nào cần trả về - không phải lúc nào giá trị đó cũng là giá trị cuối cùng. Nó hoạt động như thế nào - ví dụ chúng tôi có N bản sao của cùng một khóa. Khi có yêu cầu cập nhật giá trị khóa, hệ thống sẽ không trả về kết quả cho người dùng cho đến khi W bản sao sẽ không phản hồi rằng họ đã nhận được bản cập nhật. Khi người dùng yêu cầu một giá trị, hệ thống sẽ trả lời phản hồi cho người dùng khi ít nhất R bản sao trả về cùng một giá trị. Sau đó, chúng tôi coi hệ thống là nhất quán nghiêm ngặt nếu điều kiện được đáp ứng R+W>N. Chọn giá trị R Và Wảnh hưởng đến số lượng máy phải phản hồi trước khi phản hồi được trả lại cho người dùng, thường là chọn một điều kiện R+W=N+1- tối thiểu Điều kiện cần thiếtđể đảm bảo tính nhất quán chặt chẽ.
Tính nhất quán có thể có
Một số hệ thống ( Voldemort, Cassandra, Riak) cho phép bạn chọn R Và W tại đó R+W . Khi người dùng yêu cầu thông tin, đôi khi hệ thống không thể giải quyết xung đột giữa các phiên bản của một giá trị khóa. Để giải quyết xung đột, một loại phiên bản gọi là đồng hồ vector được sử dụng. Đây là một vectơ được liên kết với mỗi khóa chứa bộ đếm thay đổi cho mỗi bản sao. Hãy để máy chủ MỘT, B Và C- bản sao của cùng một khóa, vectơ sẽ chứa ba giá trị (N_A, N_B, N_C), ban đầu được khởi tạo trong (0,0,0) . Mỗi khi một bản sao thay đổi giá trị của một khóa, nó sẽ tăng bộ đếm của nó trong vectơ. Nếu B thay đổi giá trị của khóa đã có phiên bản trước đó (39, 1, 5) - vectơ sẽ thay đổi giá trị của nó thành (39, 2, 5) . Khi một bản sao khác, nói C, nhận được cập nhật từ bản sao B nó so sánh giá trị vectơ với giá trị vectơ của nó. Miễn là tất cả các bộ đếm của vectơ đều nhỏ hơn bộ đếm đi kèm B, giá trị trả về là phiên bản ổn định và bạn có thể ghi đè lên bản sao của chính mình. Nếu bật B Và C có những vectơ trong đó một số bộ đếm lớn hơn và một số bộ đếm nhỏ hơn, ví dụ, (39, 2, 5) Và (39, 1, 6) , thì hệ thống sẽ xác định xung đột.

Cách giải quyết xung đột này khác nhau trên các hệ thống khác nhau, Voldemort trả về nhiều bản sao của giá trị, để lại việc giải quyết xung đột cho người dùng. Hai phiên bản giỏ hàng của người dùng trên một trang web có thể được hợp nhất mà không làm mất thông tin, trong khi việc hợp nhất hai phiên bản của cùng một tài liệu có thể chỉnh sửa cần có sự can thiệp của người dùng. Cassandra, lưu trữ dấu thời gian của mỗi bản ghi, trả về bản mới nhất nếu phát hiện xung đột; cách tiếp cận này không cho phép hợp nhất hai phiên bản mà không làm mất thông tin, nhưng nó đơn giản hóa phần máy khách.

Cassandra, kể từ phiên bản 1.1, đảm bảo rằng nếu bạn nâng cấp:

CẬP NHẬT người dùng
THIẾT LẬP thông tin đăng nhập="đăng nhập" VÀ mật khẩu="mật khẩu"
Phím WHERE="khóa"

Khi đó, không đọc đồng thời sẽ thấy dữ liệu cập nhật một phần (thông tin đăng nhập đã thay đổi, nhưng mật khẩu thì không) và điều này chỉ đúng ở cấp độ các hàng nằm trong cùng một họ cột và có một khóa chung. Điều này có thể tương ứng với mức độ cô lập giao dịch đọc không cam kết, trong đó xung đột được giải quyết mất bản cập nhật. Nhưng Cassandra không cung cấp cơ chế khôi phục ở cấp cụm, ví dụ: có thể xảy ra tình huống khi thông tin đăng nhập và mật khẩu sẽ được lưu trên một số nút nhất định, nhưng không đủ Wđể cung cấp cho người dùng kết quả chính xác, người dùng buộc phải tự mình giải quyết xung đột này. Cơ chế đảm bảo sự cô lập là đối với mỗi bản ghi được thay đổi, một phiên bản riêng biệt, ẩn dành cho máy khách sẽ được tạo ra, sau đó sẽ tự động thay thế phiên bản cũ thông qua cơ chế So sánh và Hoán đổi được mô tả ở trên.

Độ tin cậy "D"

Bất kể sự cố ở cấp độ thấp hơn (ví dụ: mất hệ thống hoặc lỗi phần cứng), các thay đổi được thực hiện bởi giao dịch đã hoàn thành thành công sẽ vẫn được lưu sau khi hệ thống được đưa trở lại hoạt động. Nói cách khác, nếu người dùng nhận được xác nhận từ hệ thống rằng giao dịch đã hoàn tất, anh ta có thể chắc chắn rằng những thay đổi mình đã thực hiện sẽ không bị hoàn tác do một số lỗi.

Kịch bản lỗi dễ đoán nhất là mất điện hoặc khởi động lại máy chủ. Trong trường hợp này, một hệ thống hoàn toàn đáng tin cậy sẽ không trả lời phản hồi cho người dùng cho đến khi nó ghi tất cả các thay đổi từ bộ nhớ vào đĩa cứng. Việc ghi vào đĩa mất quá nhiều thời gian và nhiều hệ thống NoSQL phải thỏa hiệp vì mục đích hiệu suất.

Đảm bảo độ tin cậy trong một máy chủ duy nhất
Một đĩa tiêu chuẩn có thể chịu được 70-150 thao tác mỗi giây, tức là thông lượng lên tới 150 MB/s, ssd - 700 MB/s, DDR - 6000 - 17000 MB/s. Do đó, việc đảm bảo độ tin cậy trong một máy chủ đồng thời đảm bảo hiệu suất cao là giảm số lần ghi truy cập ngẫu nhiên và tăng số lần ghi tuần tự. Lý tưởng nhất là hệ thống nên giảm thiểu số lượng mục nhập giữa các cuộc gọi fsync(đồng bộ hóa dữ liệu trong bộ nhớ và trên đĩa). Một số kỹ thuật được sử dụng cho việc này.
Kiểm soát tần số fsync
Redis cung cấp một số cách để định cấu hình thời điểm gọi fsync. Bạn có thể định cấu hình nó để được gọi sau mỗi lần thay đổi bản ghi - đây là lựa chọn chậm nhất và an toàn nhất. Để cải thiện hiệu suất, bạn có thể kích hoạt việc xóa ổ đĩa mỗi lần N giây, trong trường hợp xấu nhất bạn sẽ mất dữ liệu trong N giây cuối cùng, điều này có thể khá chấp nhận được đối với một số người dùng. Nếu độ tin cậy không hề quan trọng thì bạn có thể tắt fsync và dựa vào chính hệ thống tại một thời điểm nào đó để đồng bộ hóa bộ nhớ với đĩa.
Tăng tính năng ghi tuần tự thông qua ghi nhật ký
Để tìm kiếm dữ liệu một cách hiệu quả, hệ thống NoSQL thường sử dụng các cấu trúc bổ sung, ví dụ như cây B để xây dựng chỉ mục; làm việc với nó sẽ gây ra nhiều truy cập ngẫu nhiên vào đĩa. Để giảm điều này, một số hệ thống ( Cassandra, HBase, Riak) thêm các thao tác cập nhật vào một tệp được ghi tuần tự có tên làm lại nhật ký. Trong khi một số cấu trúc hiếm khi được ghi vào đĩa thì nhật ký lại được ghi thường xuyên. Sau sự cố, các bản ghi bị thiếu có thể được khôi phục bằng nhật ký.
Tăng thông lượng bằng cách nhóm các bản ghi
Cassandra nhóm nhiều thay đổi đồng thời trong một cửa sổ ngắn có thể được kết hợp thành một fsync. Cách tiếp cận này, được gọi là cam kết nhóm, tăng thời gian phản hồi cho một người dùng, bởi vì anh ta buộc phải đợi một số giao dịch khác để ghi lại giao dịch của mình. Lợi thế ở đây có được bằng cách tăng thông lượng tổng thể, bởi vì nhiều mục ngẫu nhiên có thể được hợp nhất.
Đảm bảo độ tin cậy trong cụm máy chủ
Do khả năng xảy ra lỗi đĩa và máy chủ không mong muốn, cần phải phân phối thông tin trên nhiều máy.
làm lạiđại diện cho một cổ điển chủ nô kiến trúc để sao chép dữ liệu. Tất cả các hoạt động liên quan đến bản gốc sẽ được chuyển xuống bản sao dưới dạng nhật ký.
MongoDB là một cấu trúc trong đó một số lượng máy chủ nhất định lưu trữ từng tài liệu và có thể đặt số lượng máy chủ W , được mô tả ở trên, là mức tối thiểu cần thiết để ghi lại và trả lại quyền kiểm soát cho người dùng.
HBaseđạt được độ tin cậy của nhiều máy chủ thông qua việc sử dụng hệ thống tệp phân tán HDFS.

Nói chung, người ta có thể nhận thấy một xu hướng nhất định trong các công cụ NoSQL hiện đại hướng tới việc cung cấp tính nhất quán dữ liệu cao hơn. Tuy nhiên, các công cụ SQL và NoSQL có thể tồn tại và phát triển song song và giải quyết các vấn đề hoàn toàn khác nhau.

Bạn có thể đã nghe thuật ngữ như giao dịch . Nếu chưa hoặc đã quên thì hãy để chúng tôi nhắc bạn điều đó dưới giao dịch đề cập đến một chuỗi thao tác nhất định (các hành động chèn, cập nhật hoặc xóa) trong cơ sở dữ liệu phải được thực hiện như một phần của một tổng thể duy nhất.

Tất cả chúng ta đều sử dụng dịch vụ của ngân hàng và thực hiện nhiều giao dịch khác nhau bằng tiền. Làm thế nào để đạt được độ tin cậy trong trường hợp này? Các yêu cầu bảo mật để thực hiện các hoạt động trong các hệ thống như vậy được tăng lên. Bây giờ hãy tưởng tượng rằng bạn đang chuyển tiền cho một người mà bạn biết. Bạn muốn tiền được ghi nợ từ tài khoản của bạn và chuyển vào tài khoản của người nhận. Nhưng điều gì sẽ xảy ra trong trường hợp mất điện, chẳng hạn như mất điện hoặc trường hợp khẩn cấp khác? Ai đảm bảo với bạn rằng bạn sẽ không rơi vào tình huống tiền đã ra khỏi tài khoản nhưng việc chuyển tiền vào tài khoản người nhận chưa xảy ra. Giúp ngăn chặn những tình huống như vậy giao dịch.

Cam kết và khôi phục một giao dịch.

Một giao dịch kết hợp một số câu lệnh SQL. Nếu có bất kỳ lỗi nào xảy ra do việc thực hiện ít nhất một trong các yêu cầu, giao dịch sẽ ngay lập tức được khôi phục ( quay lại). Nếu mọi thứ đều ổn và tất cả các hành động trong một giao dịch đều được hoàn thành thành công thì cam kết sẽ được thực hiện ( làm) giao dịch và chỉ trong trường hợp này những thay đổi tương ứng mới được ghi vào cơ sở dữ liệu.

Bây giờ hãy trình bày một ví dụ về việc sử dụng các giao dịch trong Cơ sở dữ liệu MySQL(phổ biến nhất cơ sở dữ liệu cơ chế này về cơ bản không khác biệt):

Hãy để chúng tôi có một bảng kiểm tra tài khoản, nơi lưu trữ thông tin về tài khoản người dùng. Và một lĩnh vực mà chúng tôi quan tâm được gọi là THĂNG BẰNG. Khi chuyển từ tài khoản này sang tài khoản khác, tiền phải được ghi nợ vào một tài khoản và ghi có vào tài khoản khác (vì mục đích thực hành, bạn có thể tự tạo một cơ sở dữ liệu nhỏ).

Giao dịch bắt đầu bằng một từ khóa BẮT ĐẦU. Hai toán tử CẬP NHẬT các giao dịch bên trong là một phần của cùng một giao dịch và có thể được thực hiện cả hai cùng lúc hoặc không thực hiện cả hai giao dịch đó (phải xảy ra quá trình khôi phục). Đội LÀM dùng để chỉ ra sự kết thúc của một giao dịch và cam kết thay đổi. Nếu cam kết thành công thì tất cả thay đổi trong cơ sở dữ liệu nguồn sẽ được hiển thị.

Để khôi phục một giao dịch, bạn có thể viết lệnh một cách rõ ràng HOÀN LẠI.

Thuộc tính ACID.

Vì vậy, chúng ta đã làm quen với khái niệm giao dịch, cam kết và khôi phục. Bây giờ chúng ta hãy xem xét bốn đặc tính rất quan trọng của một giao dịch mà mọi người thường thích hỏi trong các cuộc phỏng vấn. Yêu cầu axit vào cuối những năm 70 do Jim Gray (người đoạt giải Turing vì đóng góp của ông cho việc phát triển cơ sở dữ liệu) xây dựng. Và đây là âm thanh của chúng:

  • Tính nguyên tử- tính nguyên tử. Những gì chúng ta đã nói ở trên. giao dịch là nguyên tử, nghĩa là tất cả các hành động được thực hiện trong một giao dịch là một tổng thể duy nhất.
  • Tính nhất quán- Tính nhất quán. Mỗi giao dịch mới sẽ chuyển cơ sở dữ liệu từ trạng thái nhất quán này sang trạng thái nhất quán khác. Nếu cơ sở dữ liệu của bạn được phân phối thì tất cả các bản sao của nó phải chứa cùng một phiên bản dữ liệu để đảm bảo tính khả dụng. Quy tắc này thường bị vi phạm bởi nhiều người NoSQL cơ sở dữ liệu.
  • Sự cách ly- sự cách ly. Các giao dịch không ảnh hưởng lẫn nhau. Trong trường hợp thực hiện song song, việc cập nhật dữ liệu một phần sẽ không xảy ra.
  • Độ bền- độ tin cậy. Bạn có muốn lưu tất cả các thay đổi do giao dịch này thực hiện trong trường hợp thất bại không? Đó là lý do tại sao danh sách này có đặc tính đáng tin cậy.