Giới thiệu

Cách đây một thời gian, tôi được giao nhiệm vụ phát triển cụm chuyển đổi dự phòng cho PostgreSQL, hoạt động ở một số trung tâm dữ liệu được kết nối bằng cáp quang trong một thành phố và có khả năng chịu được sự cố (ví dụ: mất điện) của một trung tâm dữ liệu. Là phần mềm chịu trách nhiệm về khả năng chịu lỗi, tôi đã chọn Người dượt chạy đuavì đây là giải pháp chính thức của RedHat để tạo cụm chuyển đổi dự phòng. Điều này tốt vì RedHat cung cấp hỗ trợ cho nó và vì giải pháp này mang tính phổ quát (mô-đun). Với sự trợ giúp của nó, có thể đảm bảo khả năng chịu lỗi không chỉ của PostgreSQL mà còn của các dịch vụ khác, bằng cách sử dụng các mô-đun tiêu chuẩn hoặc tạo chúng cho các nhu cầu cụ thể.

Quyết định này đặt ra một câu hỏi hợp lý: khả năng chịu lỗi của cụm chuyển đổi dự phòng sẽ như thế nào? Để điều tra vấn đề này, tôi đã phát triển một băng ghế thử nghiệm mô phỏng các lỗi khác nhau trên các nút cụm, chờ dịch vụ được khôi phục, khôi phục nút bị lỗi và tiếp tục thử nghiệm trong một vòng lặp. Dự án này ban đầu được gọi là hapgsql, nhưng theo thời gian tôi cảm thấy nhàm chán với cái tên chỉ có một nguyên âm. Vì vậy, tôi bắt đầu gọi các cơ sở dữ liệu có khả năng chịu lỗi (và thả nổi IP trỏ đến chúng) krogan (một nhân vật trong trò chơi máy tính trong đó tất cả các cơ quan quan trọng đều được sao chép) và các nút, cụm và bản thân dự án được tuchanka (hành tinh nơi người krogans sinh sống).

Bây giờ quản lý đã cho phép mở dự án cho cộng đồng nguồn mở theo giấy phép MIT. README sẽ sớm được dịch sang tiếng Anh (vì dự kiến người tiêu dùng chính sẽ là các nhà phát triển Pacemaker và PostgreSQL), và tôi quyết định trình bày phiên bản tiếng Nga cũ của README (một phần) dưới dạng bài viết này.

Các cụm được triển khai trên máy ảo VirtualBox. Tổng cộng có 12 máy ảo (tổng cộng 36GiB) sẽ được triển khai, tạo thành 4 cụm có khả năng chịu lỗi (các tùy chọn khác nhau). Hai cụm đầu tiên bao gồm hai máy chủ PostgreSQL được đặt ở các trung tâm dữ liệu khác nhau và một máy chủ chung nhân chứng c thiết bị đại biểu (được lưu trữ trên một máy ảo giá rẻ ở trung tâm dữ liệu thứ ba), giải quyết vấn đề không chắc chắn 50% / 50%, đưa phiếu bầu của bạn cho một trong các bên. Cụm thứ ba trong ba trung tâm dữ liệu: một chủ, hai phụ, không thiết bị đại biểu. Cụm thứ tư bao gồm bốn máy chủ PostgreSQL, hai máy chủ cho mỗi trung tâm dữ liệu: một máy chủ chính, các bản sao còn lại và cũng sử dụng nhân chứng c thiết bị đại biểu. Loại thứ tư có thể chịu được sự cố của hai máy chủ hoặc một trung tâm dữ liệu. Giải pháp này có thể được mở rộng thành số lượng bản sao lớn hơn nếu cần thiết.

Dịch vụ thời gian chính xác ntpd cũng được cấu hình lại để có khả năng chịu lỗi, nhưng nó sử dụng chính phương thức đó ntpd (chế độ mồ côi). Máy chủ chia sẻ nhân chứng hoạt động như một máy chủ NTP trung tâm, phân phối thời gian của nó tới tất cả các cụm, từ đó đồng bộ hóa tất cả các máy chủ với nhau. Nếu như nhân chứng bị lỗi hoặc bị cô lập thì một trong các máy chủ của cụm (trong cụm) sẽ bắt đầu phân phối thời gian của nó. Bộ nhớ đệm phụ trợ HTTP proxy cũng được nâng lên nhân chứng, với sự trợ giúp của nó, các máy ảo khác có quyền truy cập vào kho Yum. Trên thực tế, các dịch vụ như thời gian chính xác và proxy rất có thể sẽ được lưu trữ trên các máy chủ chuyên dụng, nhưng chúng được lưu trữ trong gian hàng. nhân chứng chỉ để tiết kiệm số lượng máy ảo và dung lượng.

Phiên bản

v0. Hoạt động với CentOS 7 và PostgreSQL 11 trên VirtualBox 6.1.

Cấu trúc cụm

Tất cả các cụm được thiết kế để đặt ở nhiều trung tâm dữ liệu, kết hợp thành một mạng phẳng và phải chịu được sự cố hoặc sự cô lập mạng của một trung tâm dữ liệu duy nhất. Đó là lý do tại sao là không thể sử dụng để bảo vệ chống lại não phân chia Công nghệ máy tạo nhịp tim tiêu chuẩn được gọi là STONITH (Bắn Nút Khác Vào Đầu) hoặc hàng rào. Bản chất của nó: nếu các nút trong cụm bắt đầu nghi ngờ rằng có điều gì đó không ổn với một số nút, nó không phản hồi hoặc hoạt động không đúng, thì họ buộc phải tắt nó thông qua các thiết bị “bên ngoài”, chẳng hạn như thẻ điều khiển IPMI hoặc UPS. . Nhưng điều này sẽ chỉ hoạt động trong trường hợp, trong trường hợp xảy ra một lỗi duy nhất, máy chủ IPMI hoặc UPS vẫn tiếp tục hoạt động. Ở đây, chúng tôi dự định bảo vệ khỏi sự cố nghiêm trọng hơn nhiều, khi toàn bộ trung tâm dữ liệu bị lỗi (ví dụ: mất điện). Và với sự từ chối như vậy, mọi thứ đá-các thiết bị (IPMI, UPS, v.v.) cũng sẽ không hoạt động.

Thay vào đó, hệ thống này dựa trên ý tưởng về số đại biểu. Tất cả các nút đều có giọng nói và chỉ những nút có thể nhìn thấy hơn một nửa số nút mới có thể hoạt động. Số tiền “một nửa + 1” này được gọi là túc số. Nếu không đạt được số đại biểu thì nút sẽ quyết định rằng nó đang ở trạng thái cách ly mạng và phải tắt tài nguyên của nó, tức là. nó là thế này đây bảo vệ não phân chia. Nếu phần mềm chịu trách nhiệm về hành vi này không hoạt động thì cơ quan giám sát, chẳng hạn như dựa trên IPMI, sẽ phải hoạt động.

Nếu số lượng nút chẵn (một cụm trong hai trung tâm dữ liệu), thì cái gọi là sự không chắc chắn có thể phát sinh 50% / 50% (năm mươi năm mươi) khi cách ly mạng chia cụm chính xác làm đôi. Do đó, đối với số nút chẵn, chúng tôi thêm thiết bị đại biểu là một daemon đơn giản có thể được khởi chạy trên máy ảo rẻ nhất ở trung tâm dữ liệu thứ ba. Anh ta đưa ra phiếu bầu của mình cho một trong các phân đoạn (mà anh ta nhìn thấy), và do đó giải quyết được độ không chắc chắn 50%/50%. Tôi đã đặt tên cho máy chủ nơi thiết bị đại biểu sẽ được khởi chạy nhân chứng (thuật ngữ từ repmgr, tôi thích nó).

Tài nguyên có thể được di chuyển từ nơi này sang nơi khác, chẳng hạn như từ máy chủ bị lỗi sang máy chủ khỏe mạnh hoặc theo lệnh của quản trị viên hệ thống. Để khách hàng biết tài nguyên họ cần được đặt ở đâu (kết nối ở đâu?), IP nổi (IP nổi). Đây là những IP mà Máy tạo nhịp tim có thể di chuyển xung quanh các nút (mọi thứ đều nằm trên một mạng phẳng). Mỗi người trong số họ tượng trưng cho một tài nguyên (dịch vụ) và sẽ được đặt ở nơi bạn cần kết nối để có quyền truy cập vào dịch vụ này (trong trường hợp của chúng tôi là cơ sở dữ liệu).

Tuchanka1 (mạch nén)

Cấu trúc

Ý tưởng là chúng tôi có nhiều cơ sở dữ liệu nhỏ với tải thấp, do đó việc duy trì một máy chủ nô lệ chuyên dụng ở chế độ chờ nóng cho các giao dịch chỉ đọc là không có lợi (không cần lãng phí tài nguyên như vậy).

Mỗi trung tâm dữ liệu có một máy chủ. Mỗi máy chủ có hai phiên bản PostgreSQL (theo thuật ngữ của PostgreSQL chúng được gọi là cụm, nhưng để tránh nhầm lẫn, tôi sẽ gọi chúng là phiên bản (tương tự với các cơ sở dữ liệu khác) và tôi sẽ chỉ gọi chúng là cụm cụm Máy tạo nhịp tim). Một phiên bản hoạt động ở chế độ chính và chỉ có nó cung cấp dịch vụ (chỉ IP float mới dẫn đến nó). Phiên bản thứ hai hoạt động như một phiên bản phụ cho trung tâm dữ liệu thứ hai và sẽ chỉ cung cấp dịch vụ nếu phiên bản chính của nó bị lỗi. Vì hầu hết chỉ có một trong hai phiên bản (phiên bản chính) sẽ cung cấp dịch vụ (thực hiện yêu cầu), nên tất cả tài nguyên máy chủ đều được tối ưu hóa cho phiên bản chính (bộ nhớ được phân bổ cho bộ đệm chia sẻ_buffers, v.v.), nhưng do đó phiên bản thứ hai cũng có đủ tài nguyên (mặc dù hoạt động dưới mức tối ưu thông qua bộ đệm của hệ thống tệp) trong trường hợp một trong các trung tâm dữ liệu bị lỗi. Máy phụ không cung cấp dịch vụ (không thực hiện các yêu cầu chỉ đọc) trong quá trình hoạt động bình thường của cụm, do đó không có chiến tranh giành tài nguyên với máy chủ trên cùng một máy.

Trong trường hợp có hai nút, khả năng chịu lỗi chỉ có thể xảy ra khi sao chép không đồng bộ, vì với sao chép đồng bộ, lỗi của một nút phụ sẽ dẫn đến việc nút chính bị dừng.

Không làm chứng được

Không làm chứng (thiết bị đại biểu) Tôi sẽ chỉ xem xét cụm Tuchanka1, với tất cả các cụm khác, nó sẽ có cùng một câu chuyện. Nếu nhân chứng thất bại, sẽ không có gì thay đổi trong cấu trúc cụm, mọi thứ sẽ tiếp tục hoạt động như cũ. Nhưng số đại biểu sẽ trở thành 2 trên 3, và do đó, bất kỳ thất bại nào tiếp theo sẽ gây thiệt hại nặng nề cho cụm. Nó vẫn sẽ phải được sửa chữa khẩn cấp.

Tuchanka1 từ chối

Sự cố của một trong các trung tâm dữ liệu của Tuchanka1. Trong trường hợp này nhân chứng bỏ phiếu bầu cho nút thứ hai trong trung tâm dữ liệu thứ hai. Ở đó, nô lệ cũ biến thành chủ, kết quả là cả hai chủ đều làm việc trên cùng một máy chủ và IP float của cả hai đều trỏ đến họ.

Tuchanka2 (cổ điển)

Cấu trúc

Sơ đồ cổ điển của hai nút. Người chủ làm việc trên cái này, người nô lệ làm việc thứ hai. Cả hai đều có thể thực thi các yêu cầu (nô lệ chỉ đọc), vì vậy cả hai đều được trỏ đến bởi IP float: krogan2 là chủ, krogan2s1 là nô lệ. Cả chủ và nô lệ đều có khả năng chịu lỗi.

Trong trường hợp có hai nút, khả năng chịu lỗi chỉ có thể thực hiện được khi sao chép không đồng bộ, vì với sao chép đồng bộ, lỗi của nô lệ sẽ dẫn đến việc dừng chủ.

Tuchanka2 từ chối

Nếu một trong các trung tâm dữ liệu bị lỗi nhân chứng bỏ phiếu cho cái thứ hai. Trên trung tâm dữ liệu đang hoạt động duy nhất, master sẽ được nâng lên và cả hai IP float sẽ trỏ đến nó: master và Slave. Tất nhiên, phiên bản phải được cấu hình sao cho có đủ tài nguyên (giới hạn kết nối, v.v.) để chấp nhận đồng thời tất cả các kết nối và yêu cầu từ IP float chính và phụ. Nghĩa là, trong quá trình hoạt động bình thường, nó phải được cung cấp đủ các giới hạn.

Tuchanka4 (nhiều nô lệ)

Cấu trúc

Đã là một thái cực khác. Có những cơ sở dữ liệu nhận được rất nhiều yêu cầu chỉ đọc (trường hợp điển hình của một trang web có tải trọng cao). Tuchanka4 là tình huống có thể có từ ba nô lệ trở lên để xử lý các yêu cầu đó nhưng vẫn không quá nhiều. Với số lượng nô lệ rất lớn, sẽ cần phải phát minh ra một hệ thống sao chép có thứ bậc. Trong trường hợp tối thiểu (trong hình), mỗi trung tâm dữ liệu có hai máy chủ, mỗi máy chủ có một phiên bản PostgreSQL.

Một tính năng khác của sơ đồ này là có thể tổ chức một bản sao đồng bộ. Nó được cấu hình để sao chép, nếu có thể, sang một trung tâm dữ liệu khác, thay vì một bản sao trong cùng trung tâm dữ liệu với trung tâm dữ liệu chính. Master và mỗi Slave được trỏ đến bởi một IP nổi. May mắn thay, bằng cách nào đó, giữa các nô lệ sẽ cần phải cân bằng các yêu cầu. proxy sql, ví dụ: về phía khách hàng. Các loại khách hàng khác nhau có thể yêu cầu các loại khác nhau proxy sqlvà chỉ nhà phát triển khách hàng mới biết ai cần cái nào. Chức năng này có thể được triển khai bằng daemon bên ngoài hoặc bằng thư viện máy khách (nhóm kết nối), v.v. Tất cả điều này vượt xa chủ đề về cụm cơ sở dữ liệu chuyển đổi dự phòng (chuyển đổi dự phòng Proxy SQL có thể được thực hiện độc lập, cùng với khả năng chịu lỗi của khách hàng).

Tuchanka4 từ chối

Nếu một trung tâm dữ liệu (tức là hai máy chủ) bị lỗi, nhân chứng sẽ bỏ phiếu cho trung tâm thứ hai. Kết quả là, hai máy chủ đang chạy trong trung tâm dữ liệu thứ hai: một máy chủ đang chạy máy chủ chính và IP float chính trỏ đến nó (để nhận yêu cầu đọc-ghi); và trên máy chủ thứ hai có một máy chủ nô lệ đang chạy với bản sao đồng bộ và một trong các IP nổi nô lệ trỏ đến nó (đối với các yêu cầu chỉ đọc).

Điều đầu tiên cần lưu ý là không phải tất cả các IP nổi nô lệ đều sẽ là công nhân mà chỉ có một IP. Và để làm việc với nó một cách chính xác, điều cần thiết là proxy sql đã chuyển hướng tất cả các yêu cầu đến IP float duy nhất còn lại; và nếu proxy sql không, khi đó bạn có thể liệt kê tất cả các địa chỉ IP nổi được phân tách bằng dấu phẩy trong URL kết nối. Trong trường hợp này, với libpq kết nối sẽ đến IP hoạt động đầu tiên, việc này được thực hiện trong hệ thống kiểm tra tự động. Có lẽ trong các thư viện khác, chẳng hạn như JDBC, điều này sẽ không hoạt động và cần thiết proxy sql. Điều này được thực hiện vì IP float cho nô lệ bị cấm được nâng lên đồng thời trên một máy chủ, do đó chúng được phân bổ đồng đều giữa các máy chủ nô lệ nếu có một vài trong số chúng đang chạy.

Thứ hai: ngay cả trong trường hợp trung tâm dữ liệu bị lỗi, việc sao chép đồng bộ vẫn được duy trì. Và ngay cả khi xảy ra lỗi thứ cấp, tức là một trong hai máy chủ ở trung tâm dữ liệu còn lại bị lỗi thì cụm mặc dù sẽ ngừng cung cấp dịch vụ nhưng vẫn sẽ giữ lại thông tin về tất cả các giao dịch đã cam kết mà nó đã đưa ra xác nhận cam kết. (sẽ không có thông tin mất mát trong trường hợp xảy ra lỗi thứ cấp).

Tuchanka3 (3 trung tâm dữ liệu)

Cấu trúc

Đây là cụm dành cho trường hợp có ba trung tâm dữ liệu hoạt động đầy đủ, mỗi trung tâm có một máy chủ cơ sở dữ liệu hoạt động đầy đủ. Trong trường hợp này thiết bị đại biểu không cần thiết. Một trung tâm dữ liệu có nhân viên chủ, hai trung tâm còn lại có nhân viên phụ. Quá trình sao chép diễn ra đồng bộ, gõ BẤT KỲ (slave1, Slave2), tức là máy khách sẽ nhận được xác nhận cam kết khi bất kỳ máy phụ nào là người đầu tiên phản hồi rằng anh ta đã chấp nhận cam kết. Tài nguyên được biểu thị bằng một IP nổi cho chủ và hai cho phụ. Không giống như Tuchanka4, cả ba IP float đều có khả năng chịu lỗi. Để cân bằng các truy vấn SQL chỉ đọc, bạn có thể sử dụng proxy sql (với khả năng chịu lỗi riêng) hoặc chỉ định một IP nổi nô lệ cho một nửa số máy khách và nửa còn lại cho nửa số máy khách thứ hai.

Tuchanka3 từ chối

Nếu một trong các trung tâm dữ liệu bị hỏng thì vẫn còn lại hai trung tâm. Trong một, IP chính và IP float từ IP chính được nâng lên, trong lần thứ hai - IP float phụ và cả IP float phụ (phiên bản phải có nguồn dự trữ kép để chấp nhận tất cả các kết nối từ cả hai IP float phụ). Sao chép đồng bộ giữa chủ và nô lệ. Ngoài ra, cụm sẽ lưu thông tin về các giao dịch đã cam kết và xác nhận (sẽ không bị mất thông tin) trong trường hợp hai trung tâm dữ liệu bị phá hủy (nếu chúng không bị phá hủy đồng thời).

Tôi quyết định không đưa vào mô tả chi tiết về cấu trúc và cách triển khai tệp. Bất cứ ai muốn tìm hiểu đều có thể đọc tất cả trong README. Tôi chỉ cung cấp mô tả về thử nghiệm tự động.

Hệ thống kiểm tra tự động

Để kiểm tra khả năng chịu lỗi của các cụm bằng cách mô phỏng các lỗi khác nhau, một hệ thống kiểm tra tự động đã được tạo ra. Ra mắt bởi kịch bản test/failure. Tập lệnh có thể lấy số lượng cụm mà bạn muốn kiểm tra làm tham số. Ví dụ lệnh này:

test/failure 2 3

sẽ chỉ kiểm tra cụm thứ hai và thứ ba. Nếu các tham số không được chỉ định thì tất cả các cụm sẽ được kiểm tra. Tất cả các cụm đều được kiểm tra song song và kết quả được hiển thị trong bảng tmux. Tmux sử dụng một máy chủ tmux chuyên dụng, do đó tập lệnh có thể được chạy từ dưới tmux mặc định, dẫn đến một tmux lồng nhau. Tôi khuyên bạn nên sử dụng thiết bị đầu cuối trong một cửa sổ lớn và có phông chữ nhỏ. Trước khi bắt đầu thử nghiệm, tất cả các máy ảo sẽ được khôi phục về trạng thái ảnh chụp nhanh tại thời điểm tập lệnh hoàn tất setup.

Thiết bị đầu cuối được chia thành các cột theo số cụm đang được kiểm tra; theo mặc định (trong ảnh chụp màn hình) có bốn cột. Tôi sẽ mô tả nội dung của các cột bằng ví dụ về Tuchanka2. Các bảng trong ảnh chụp màn hình được đánh số:

Thống kê kiểm tra được hiển thị ở đây. Cột:
- thất bại — tên của bài kiểm tra (chức năng trong tập lệnh) mô phỏng lỗi.
- phản ứng - thời gian trung bình số học tính bằng giây trong đó cụm khôi phục chức năng của nó. Nó được đo từ khi bắt đầu tập lệnh mô phỏng lỗi cho đến thời điểm cụm khôi phục chức năng và có thể tiếp tục cung cấp dịch vụ. Nếu thời gian rất ngắn, chẳng hạn như sáu giây (điều này xảy ra trong các cụm có nhiều nô lệ (Tuchanka3 và Tuchanka4)), điều này có nghĩa là lỗi xảy ra ở nô lệ không đồng bộ và không ảnh hưởng đến hiệu suất theo bất kỳ cách nào; chuyển đổi trạng thái cụm.
- sai lệch - hiển thị mức độ lan truyền (độ chính xác) của giá trị phản ứng sử dụng phương pháp độ lệch chuẩn.
- tính - thử nghiệm này đã được thực hiện bao nhiêu lần.
Nhật ký ngắn cho phép bạn đánh giá những gì cụm hiện đang làm. Số lần lặp (kiểm tra), dấu thời gian và tên của thao tác được hiển thị. Chạy quá lâu (> 5 phút) cho thấy có vấn đề.
tim (trái tim) - thời điểm hiện tại. Để đánh giá trực quan hiệu suất thạc sĩ Thời gian hiện tại được ghi liên tục vào bảng của nó bằng cách sử dụng IP chính float. Nếu thành công, kết quả sẽ được hiển thị trong bảng này.
đánh bại (xung) - “thời gian hiện tại”, được ghi lại trước đó bằng tập lệnh tim để làm chủ, bây giờ đọc từ nô lệ thông qua IP nổi của nó. Cho phép bạn đánh giá trực quan hiệu suất của nô lệ và bản sao. Trong Tuchanka1 không có nô lệ nào có IP float (không có nô lệ nào cung cấp dịch vụ), nhưng có hai phiên bản (DB) nên sẽ không hiển thị ở đây đánh bạiVà tim trường hợp thứ hai.
Theo dõi tình trạng cụm bằng tiện ích pcs mon. Hiển thị cấu trúc, phân phối tài nguyên trên các nút và thông tin hữu ích khác.
Giám sát hệ thống từ mỗi máy ảo trong cụm được hiển thị ở đây. Có thể có nhiều bảng như vậy tùy thuộc vào số lượng máy ảo mà cụm đó có. Hai đồ thị Tải CPU (máy ảo có hai bộ xử lý), tên máy ảo, Tải hệ thống (được đặt tên là Load Average vì nó được tính trung bình trong 5, 10 và 15 phút), xử lý dữ liệu và phân bổ bộ nhớ.
Dấu vết của kịch bản thực hiện thử nghiệm. Trong trường hợp xảy ra sự cố - hoạt động bị gián đoạn đột ngột hoặc chu kỳ chờ đợi vô tận - tại đây bạn có thể biết lý do của hành vi này.

Thử nghiệm được thực hiện trong hai giai đoạn. Đầu tiên, tập lệnh sẽ trải qua tất cả các loại thử nghiệm, chọn ngẫu nhiên một máy ảo để áp dụng thử nghiệm này. Sau đó, một chu kỳ kiểm tra vô tận được thực hiện, các máy ảo và lỗi được chọn ngẫu nhiên mỗi lần. Việc chấm dứt đột ngột tập lệnh kiểm thử (bảng dưới cùng) hoặc vòng lặp vô tận chờ đợi điều gì đó (thời gian thực hiện > 5 phút cho một thao tác, điều này có thể được nhìn thấy trong dấu vết) cho thấy rằng một số thử nghiệm trên cụm này đã thất bại.

Mỗi bài kiểm tra bao gồm các hoạt động sau:

Khởi chạy một chức năng mô phỏng một lỗi.
Sẳn sàng? — chờ cụm được khôi phục (khi tất cả các dịch vụ được cung cấp).
Hiển thị thời gian chờ khôi phục cụm (phản ứng).
Sửa chữa — cụm đang được “sửa chữa”. Sau đó, nó sẽ trở lại trạng thái hoạt động đầy đủ và sẵn sàng cho sự cố tiếp theo.

Dưới đây là danh sách các bài kiểm tra kèm theo mô tả về những gì chúng thực hiện:

ForkBom: Tạo ra "Hết bộ nhớ" bằng cách sử dụng bom phân nhánh.
Ngoài Không Gian: Ổ cứng đã đầy. Nhưng thử nghiệm mang tính biểu tượng hơn; với tải không đáng kể được tạo ra trong quá trình thử nghiệm, PostgreSQL thường không bị lỗi khi ổ cứng đầy.
Postgres-KILL: giết PostgreSQL bằng lệnh killall -KILL postgres.
Postgres-STOP: treo lệnh PostgreSQL killall -STOP postgres.
Tắt nguồn: “ngắt điện” máy ảo bằng lệnh VBoxManage controlvm "виртуалка" poweroff.
Xóa và làm lại: làm quá tải máy ảo bằng lệnh VBoxManage controlvm "виртуалка" reset.
SBD-STOP: đình chỉ con quỷ SBD bằng lệnh killall -STOP sbd.
Tắt: gửi lệnh đến máy ảo thông qua SSH systemctl poweroff, hệ thống sẽ tắt một cách duyên dáng.
Hủy liên kết: cách ly mạng, lệnh VBoxManage controlvm "виртуалка" setlinkstate1 off.

Hoàn thành kiểm tra bằng lệnh tmux tiêu chuẩn "kill-window" Ctrl-b &, hoặc lệnh "tách-client" Ctrl-b d: tại thời điểm này quá trình kiểm tra kết thúc, tmux đóng, máy ảo bị tắt.

Các vấn đề được xác định trong quá trình thử nghiệm

Hiện nay cơ quan giám sát quỷ sbd hoạt động bằng cách dừng các daemon được quan sát nhưng không đóng băng chúng. Và kết quả là những lỗi chỉ dẫn đến đóng băng corosync и Người dượt chạy đua, nhưng không treo sbd. Để kiểm tra corosync đã có PR#83 (trên GitHub tại sbd), được chấp nhận vào chủ đề chủ. Họ đã hứa (trong PR#83) rằng sẽ có thứ gì đó tương tự dành cho Máy tạo nhịp tim, tôi hy vọng rằng bằng cách Mũ đỏ 8 sẽ làm. Nhưng những “trục trặc” như vậy chỉ mang tính suy đoán và có thể dễ dàng được mô phỏng một cách giả tạo bằng cách sử dụng, ví dụ: killall -STOP corosyncnhưng chưa bao giờ gặp nhau ngoài đời.
У Người dượt chạy đua trong phiên bản dành cho CentOS 7 đặt sai đồng bộ_thời gian chờ у thiết bị đại biểu, kết quả là nếu một nút bị lỗi, có khả năng nút thứ hai cũng khởi động lại, mà chủ nhân được cho là sẽ di chuyển. Chữa bệnh bằng cách mở rộng đồng bộ_thời gian chờ у thiết bị đại biểu trong quá trình triển khai (trong tập lệnh setup/setup1). Sửa đổi này không được các nhà phát triển chấp nhận Người dượt chạy đua, thay vào đó họ hứa sẽ thiết kế lại cơ sở hạ tầng theo cách (tại một số tương lai không xác định) mà thời gian chờ này sẽ được tính toán tự động.
Nếu cấu hình cơ sở dữ liệu chỉ định rằng LC_MESSAGES (tin nhắn văn bản) Unicode có thể được sử dụng, ví dụ: ru_RU.UTF-8, sau đó khi khởi động bưu điện trong môi trường mà ngôn ngữ không phải là UTF-8, chẳng hạn như trong môi trường trống (ở đây máy tạo nhịp tim+pssqlms(paf) chạy bưu điện), sau đó nhật ký sẽ chứa các dấu chấm hỏi thay vì các chữ cái UTF-8. Các nhà phát triển PostgreSQL chưa thống nhất phải làm gì trong trường hợp này. Nó tốn kém, bạn cần phải cài đặt LC_MESSAGES=en_US.UTF-8 khi định cấu hình (tạo) một phiên bản cơ sở dữ liệu.
Nếu wal_receiver_timeout được đặt (theo mặc định là 60 giây), thì trong quá trình kiểm tra PostgreSQL-STOP trên bản gốc trong cụm tuchanka3 và tuchanka4 bản sao không kết nối lại với chủ mới. Quá trình sao chép diễn ra đồng bộ nên không chỉ máy phụ mà cả máy chủ mới cũng dừng. Hoạt động bằng cách đặt wal_receiver_timeout=0 khi định cấu hình PostgreSQL.
Thỉnh thoảng tôi quan sát thấy tình trạng sao chép bị treo trong PostgreSQL trong thử nghiệm ForkBomb (tràn bộ nhớ). Sau ForkBomb, đôi khi nô lệ có thể không kết nối lại với chủ mới. Tôi chỉ gặp phải điều này trong cụm tuchanka3 và tuchanka4, nơi bản gốc bị treo do sao chép đồng bộ. Sự cố sẽ tự biến mất sau một thời gian dài (khoảng hai giờ). Cần nhiều nghiên cứu hơn để sửa lỗi này. Các triệu chứng tương tự như lỗi trước đó, do một nguyên nhân khác gây ra nhưng có cùng hậu quả.