Mục tiêu chính của Patroni là cung cấp Tính sẵn sàng cao cho PostgreSQL. Nhưng Patroni chỉ là một mẫu, không phải là một công cụ làm sẵn (nói chung, được nói trong tài liệu). Thoạt nhìn, sau khi thiết lập Patroni trong phòng thử nghiệm, bạn có thể thấy nó là một công cụ tuyệt vời như thế nào và nó xử lý các nỗ lực phá cụm của chúng tôi dễ dàng như thế nào. Tuy nhiên, trên thực tế, trong môi trường sản xuất, không phải lúc nào mọi thứ cũng diễn ra đẹp đẽ và trang nhã như trong phòng thí nghiệm.
Tôi sẽ nói với bạn một chút về bản thân mình. Tôi bắt đầu với vai trò quản trị viên hệ thống. Làm việc trong lĩnh vực phát triển web. Tôi đã làm việc tại Data Egret từ năm 2014. Công ty đang tham gia tư vấn trong lĩnh vực Postgres. Và chúng tôi phục vụ chính xác Postgres và chúng tôi làm việc với Postgres mỗi ngày, vì vậy chúng tôi có chuyên môn khác nhau liên quan đến hoạt động.
Và vào cuối năm 2018, chúng tôi bắt đầu dần dần sử dụng Patroni. Và một số kinh nghiệm đã được tích lũy. Bằng cách nào đó, chúng tôi đã chẩn đoán nó, điều chỉnh nó, áp dụng các phương pháp hay nhất của chúng tôi. Và trong báo cáo này tôi sẽ nói về chúng.
Ngoài Postgres, tôi yêu Linux. Tôi thích mò mẫm trong đó và khám phá, tôi thích thu thập lõi. Tôi thích ảo hóa, container, docker, Kubernetes. Tất cả điều này làm tôi quan tâm, bởi vì thói quen quản trị cũ đang ảnh hưởng. Tôi thích đối phó với giám sát. Và tôi thích postgres những thứ liên quan đến quản trị, tức là sao chép, sao lưu. Và trong thời gian rảnh rỗi, tôi viết bằng Go. Tôi không phải là kỹ sư phần mềm, tôi chỉ viết cho chính mình bằng Go. Và nó mang lại cho tôi niềm vui.
- Tôi nghĩ rằng nhiều người trong số các bạn biết rằng Postgres không có sẵn HA (Tính khả dụng cao). Để có được HA, bạn cần cài đặt một cái gì đó, định cấu hình nó, nỗ lực và lấy nó.
- Có một số công cụ và Patroni là một trong số đó giải quyết HA khá hay và rất tốt. Nhưng bằng cách đưa tất cả vào phòng thí nghiệm thử nghiệm và chạy nó, chúng tôi có thể thấy rằng tất cả đều hoạt động, chúng tôi có thể tái tạo một số vấn đề, xem Patroni phục vụ chúng như thế nào. Và chúng ta sẽ thấy rằng tất cả đều hoạt động tốt.
- Nhưng trong thực tế, chúng tôi phải đối mặt với những vấn đề khác nhau. Và tôi sẽ nói về những vấn đề này.
- Tôi sẽ cho bạn biết chúng tôi đã chẩn đoán nó như thế nào, chúng tôi đã điều chỉnh những gì - liệu nó có giúp ích cho chúng tôi hay không.
- Tôi sẽ không cho bạn biết cách cài đặt Patroni, vì bạn có thể google trên Internet, bạn có thể xem các tệp cấu hình để hiểu tất cả bắt đầu như thế nào, cấu hình nó như thế nào. Bạn có thể hiểu sơ đồ, kiến trúc, tìm kiếm thông tin về nó trên Internet.
- Tôi sẽ không nói về kinh nghiệm của người khác. Tôi sẽ chỉ nói về những vấn đề mà chúng tôi gặp phải.
- Và tôi sẽ không nói về những vấn đề nằm ngoài Patroni và PostgreSQL. Ví dụ, nếu có vấn đề liên quan đến cân bằng, khi cụm của chúng tôi bị sập, tôi sẽ không nói về nó.
Và một tuyên bố từ chối trách nhiệm nhỏ trước khi chúng tôi bắt đầu báo cáo của mình.
Tất cả những vấn đề mà chúng tôi gặp phải, chúng tôi đã gặp phải trong 6-7-8 tháng đầu tiên hoạt động. Theo thời gian, chúng tôi đã đạt được các phương pháp hay nhất trong nội bộ của mình. Và các vấn đề của chúng tôi biến mất. Do đó, bản báo cáo đã được công bố khoảng sáu tháng trước, khi nó còn mới mẻ trong đầu tôi và tôi nhớ rất rõ.
Trong quá trình chuẩn bị báo cáo, tôi đã đưa ra các khám nghiệm tử thi cũ, xem nhật ký. Và một số chi tiết có thể bị quên hoặc một số chi tiết không thể được nghiên cứu đầy đủ trong quá trình phân tích vấn đề, vì vậy ở một số điểm có vẻ như vấn đề chưa được xem xét đầy đủ hoặc thiếu thông tin. Và vì vậy tôi yêu cầu bạn thứ lỗi cho tôi trong thời điểm này.
Patroni là gì?
- Đây là một mẫu để xây dựng HA. Đó là những gì nó nói trong tài liệu. Và theo quan điểm của tôi, đây là một sự làm rõ rất chính xác. Thần hộ mệnh không phải là viên đạn bạc có thể giải quyết mọi vấn đề của bạn, tức là bạn cần nỗ lực để nó hoạt động và mang lại lợi ích.
- Đây là một dịch vụ đại lý được cài đặt trên mọi dịch vụ cơ sở dữ liệu và là một loại hệ thống khởi tạo cho Postgres của bạn. Nó khởi động Postgres, dừng, khởi động lại, định cấu hình lại và thay đổi cấu trúc liên kết của cụm của bạn.
- Theo đó, để lưu trữ trạng thái của cụm, đại diện hiện tại của nó, có vẻ như vậy, cần có một số loại lưu trữ. Và từ quan điểm này, Patroni đã đi theo con đường lưu trữ trạng thái trong một hệ thống bên ngoài. Nó là một hệ thống lưu trữ cấu hình phân tán. Nó có thể là Etcd, Consul, ZooKeeper hoặc kubernetes Etcd, tức là một trong các tùy chọn này.
- Và một trong những tính năng của Patroni là bạn lấy bộ lọc tự động ra khỏi hộp, chỉ bằng cách thiết lập nó. Nếu chúng tôi lấy Repmgr để so sánh, thì trình quay phim được bao gồm ở đó. Với Repmgr, chúng tôi nhận được một chuyển đổi, nhưng nếu chúng tôi muốn một bộ lọc tự động, thì chúng tôi cần định cấu hình bổ sung cho nó. Patroni đã có sẵn một bộ lọc tự động.
- Và còn nhiều thứ khác nữa. Ví dụ: bảo trì cấu hình, đổ bản sao mới, sao lưu, v.v. Nhưng điều này nằm ngoài phạm vi của báo cáo, tôi sẽ không nói về nó.
Và một kết quả nhỏ là nhiệm vụ chính của Patroni là thực hiện tốt và đáng tin cậy một tệp tự động để cụm của chúng tôi vẫn hoạt động và ứng dụng không nhận thấy những thay đổi trong cấu trúc liên kết cụm.
Nhưng khi chúng tôi bắt đầu sử dụng Patroni, hệ thống của chúng tôi sẽ phức tạp hơn một chút. Nếu trước đó chúng ta có Postgres, thì khi sử dụng Patroni, chúng ta có chính Patroni, chúng ta có DCS nơi lưu trữ trạng thái. Và tất cả phải hoạt động bằng cách nào đó. Vì vậy, những gì có thể đi sai?
Có thể phá vỡ:
- Postgres có thể phá vỡ. Nó có thể là bản chính hoặc bản sao, một trong số chúng có thể bị lỗi.
- Bản thân Patroni có thể bị phá vỡ.
- DCS nơi lưu trữ trạng thái có thể bị hỏng.
- Và mạng có thể bị hỏng.
Tất cả những điểm này tôi sẽ xem xét trong báo cáo.
Tôi sẽ xem xét các trường hợp khi chúng trở nên phức tạp hơn, không phải từ quan điểm rằng trường hợp đó liên quan đến nhiều thành phần. Và theo quan điểm cảm nhận chủ quan của mình là case này khó, tháo ra khó... và ngược lại, case nào nhẹ thì tháo ra dễ dàng.
Và trường hợp đầu tiên là dễ nhất. Đây là trường hợp khi chúng tôi lấy một cụm cơ sở dữ liệu và triển khai bộ lưu trữ DCS trên cùng một cụm. Đây là sai lầm phổ biến nhất. Đây là một sai lầm trong việc xây dựng kiến trúc, tức là kết hợp các thành phần khác nhau vào một chỗ.
Vì vậy, đã có một người quay phim, chúng ta hãy giải quyết những gì đã xảy ra.
Và ở đây chúng tôi quan tâm đến thời điểm người quay phim xảy ra. Đó là, chúng tôi quan tâm đến thời điểm này khi trạng thái cụm thay đổi.
Nhưng trình quay phim không phải lúc nào cũng tức thời, tức là không mất bất kỳ đơn vị thời gian nào, nó có thể bị trì hoãn. Nó có thể được lâu dài.
Do đó, nó có thời gian bắt đầu và thời gian kết thúc, tức là nó là một sự kiện liên tục. Và chúng tôi chia tất cả các sự kiện thành ba khoảng thời gian: chúng tôi có thời gian trước khi quay phim, trong khi quay phim và sau khi quay phim. Đó là, chúng tôi xem xét tất cả các sự kiện trong dòng thời gian này.
Và điều đầu tiên, khi xảy ra một cuộc chạy trốn, chúng tôi tìm kiếm nguyên nhân của những gì đã xảy ra, đâu là nguyên nhân dẫn đến việc chạy trốn.
Nếu chúng ta xem nhật ký, chúng sẽ là nhật ký Patroni cổ điển. Anh ấy nói với chúng tôi rằng máy chủ đã trở thành chủ và vai trò của chủ đã được chuyển cho nút này. Ở đây nó được đánh dấu.
Tiếp theo, chúng ta cần hiểu lý do tại sao trình quay phim lại xảy ra, tức là sự kiện nào đã xảy ra khiến vai trò chính chuyển từ nút này sang nút khác. Và trong trường hợp này, mọi thứ đều đơn giản. Chúng tôi gặp lỗi khi tương tác với hệ thống lưu trữ. Bậc thầy nhận ra rằng anh ta không thể làm việc với DCS, tức là có một số vấn đề với sự tương tác. Và anh ấy nói rằng anh ấy không thể làm chủ được nữa và từ chức. Dòng này "hạ cấp tự" nói chính xác điều đó.
Nếu chúng ta xem xét các sự kiện xảy ra trước trình quay phim, chúng ta có thể thấy ở đó chính những lý do gây ra sự cố tiếp tục trình hướng dẫn.
Nếu chúng ta xem nhật ký của Patroni, chúng ta sẽ thấy rằng chúng ta có rất nhiều lỗi, hết thời gian chờ, tức là tác nhân Patroni không thể hoạt động với DCS. Trong trường hợp này, đây là đại lý Consul, đang giao tiếp trên cổng 8500.
Và vấn đề ở đây là Patroni và cơ sở dữ liệu đang chạy trên cùng một máy chủ. Và các máy chủ Lãnh sự đã được khởi chạy trên cùng một nút. Bằng cách tạo tải trên máy chủ, chúng tôi cũng tạo ra sự cố cho máy chủ Lãnh sự. Họ không thể giao tiếp đúng cách.
Sau một thời gian, khi tải giảm xuống, Patroni của chúng tôi đã có thể liên lạc lại với các đại lý. Công việc bình thường lại tiếp tục. Và cùng một máy chủ Pgdb-2 lại trở thành máy chủ. Đó là, đã xảy ra một sự cố lật nhỏ, do đó nút đã từ bỏ quyền hạn của chủ và sau đó tiếp quản chúng một lần nữa, tức là mọi thứ trở lại như cũ.
Và điều này có thể được coi là một báo động giả, hoặc có thể được coi là Patroni đã làm đúng mọi thứ. Đó là, anh ta nhận ra rằng anh ta không thể duy trì trạng thái của cụm và loại bỏ quyền lực của mình.
Và ở đây, vấn đề nảy sinh do các máy chủ của Lãnh sự nằm trên cùng một phần cứng với các căn cứ. Theo đó, bất kỳ tải nào: cho dù đó là tải trên đĩa hay bộ xử lý, nó cũng ảnh hưởng đến sự tương tác với cụm Consul.
Và chúng tôi quyết định rằng nó không nên sống cùng nhau, chúng tôi đã phân bổ một cụm riêng cho Lãnh sự. Và Patroni đã làm việc với một Lãnh sự riêng, tức là đã có một cụm Postgres riêng, một cụm Lãnh sự riêng. Đây là hướng dẫn cơ bản về cách mang và giữ tất cả những thứ này để chúng không sống chung với nhau.
Như một tùy chọn, bạn có thể thay đổi các tham số ttl, loop_wait, retry_timeout, tức là cố gắng duy trì các đỉnh tải ngắn hạn này bằng cách tăng các tham số này. Nhưng đây không phải là lựa chọn phù hợp nhất, vì tải này có thể kéo dài trong thời gian. Và chúng ta sẽ đơn giản vượt ra ngoài giới hạn của các tham số này. Và điều đó có thể không thực sự hữu ích.
Vấn đề đầu tiên, như bạn hiểu, rất đơn giản. Chúng tôi đã lấy và đặt DCS cùng với đế, chúng tôi gặp sự cố.
Vấn đề thứ hai tương tự như vấn đề thứ nhất. Nó tương tự ở chỗ chúng ta lại gặp vấn đề về khả năng tương tác với hệ thống DCS.
Nếu xem nhật ký, chúng tôi sẽ thấy rằng chúng tôi lại gặp lỗi giao tiếp. Và Patroni nói rằng tôi không thể tương tác với DCS nên chủ hiện tại chuyển sang chế độ bản sao.
Người chủ cũ trở thành một bản sao, ở đây Patroni hoạt động, như nó phải vậy. Nó chạy pg_rewind để tua lại nhật ký giao dịch và sau đó kết nối với chủ mới để bắt kịp chủ mới. Ở đây Patroni hoạt động, như anh ấy nên làm.
Ở đây, chúng ta phải tìm vị trí đứng trước trình quay phim, tức là những lỗi khiến chúng ta có trình quay phim. Và về vấn đề này, nhật ký Patroni khá thuận tiện để làm việc. Anh ấy viết những tin nhắn giống nhau trong một khoảng thời gian nhất định. Và nếu chúng ta bắt đầu cuộn nhanh qua các nhật ký này, thì chúng ta sẽ thấy từ các nhật ký rằng nhật ký đã thay đổi, điều đó có nghĩa là một số vấn đề đã bắt đầu. Chúng ta mau quay lại nơi này, xem chuyện gì xảy ra.
Và trong một tình huống bình thường, các bản ghi trông giống như thế này. Chủ sở hữu của khóa được kiểm tra. Và nếu chủ sở hữu, chẳng hạn, đã thay đổi, thì một số sự kiện có thể xảy ra mà Patroni phải ứng phó. Nhưng trong trường hợp này, chúng tôi ổn. Chúng tôi đang tìm kiếm nơi bắt đầu xảy ra lỗi.
Và sau khi cuộn đến điểm bắt đầu xuất hiện lỗi, chúng tôi thấy rằng chúng tôi đã tự động chuyển đổi tệp. Và vì các lỗi của chúng tôi liên quan đến tương tác với DCS và trong trường hợp của chúng tôi, chúng tôi đã sử dụng Lãnh sự, chúng tôi cũng xem nhật ký của Lãnh sự, điều gì đã xảy ra ở đó.
So sánh sơ bộ thời gian của người nộp hồ sơ và thời gian trong nhật ký của Lãnh sự, chúng ta thấy rằng những người hàng xóm của chúng ta trong cụm Lãnh sự bắt đầu nghi ngờ về sự tồn tại của các thành viên khác trong cụm Lãnh sự.
Và nếu bạn cũng xem nhật ký của các nhân viên Lãnh sự khác, bạn cũng có thể thấy rằng một số kiểu sập mạng đang diễn ra ở đó. Và tất cả các thành viên trong cụm Consul đều nghi ngờ sự tồn tại của nhau. Và đây là động lực cho người quay phim.
Nếu bạn nhìn vào những gì đã xảy ra trước những lỗi này, bạn có thể thấy rằng có đủ loại lỗi, chẳng hạn như thời hạn, RPC giảm, nghĩa là rõ ràng có một số vấn đề trong sự tương tác của các thành viên cụm Lãnh sự với nhau .
Câu trả lời đơn giản nhất là sửa chữa mạng. Nhưng với tôi, đứng trên bục giảng, nói ra điều này thật dễ dàng. Nhưng hoàn cảnh như vậy mà không phải lúc nào khách hàng cũng có đủ khả năng để sửa chữa mạng. Anh ta có thể sống ở DC và có thể không sửa được mạng, ảnh hưởng đến thiết bị. Và vì vậy một số tùy chọn khác là cần thiết.
Có các tùy chọn:
- Theo tôi, tùy chọn đơn giản nhất được viết, ngay cả trong tài liệu, là vô hiệu hóa kiểm tra của Lãnh sự, tức là chỉ cần chuyển một mảng trống. Và chúng tôi nói với đại lý Lãnh sự không sử dụng bất kỳ séc nào. Với những kiểm tra này, chúng tôi có thể bỏ qua những cơn bão mạng này và không khởi chạy trình quay phim.
- Một tùy chọn khác là kiểm tra lại bè_multiplier. Đây là một tham số của chính máy chủ Lãnh sự. Theo mặc định, giá trị này được đặt thành 5. Giá trị này được tài liệu khuyến nghị cho môi trường dàn dựng. Trên thực tế, điều này ảnh hưởng đến tần suất nhắn tin giữa các thành viên trong mạng lưới Lãnh sự. Trên thực tế, tham số này ảnh hưởng đến tốc độ giao tiếp dịch vụ giữa các thành viên của cụm Consul. Và để sản xuất, nên giảm nó để các nút trao đổi tin nhắn thường xuyên hơn.
- Một tùy chọn khác mà chúng tôi đã đưa ra là tăng mức độ ưu tiên của các quy trình Lãnh sự trong số các quy trình khác cho bộ lập lịch quy trình của hệ điều hành. Có một tham số "đẹp" như vậy, nó chỉ xác định mức độ ưu tiên của các quy trình được bộ lập lịch trình hệ điều hành tính đến khi lập lịch trình. Chúng tôi cũng đã giảm giá trị tốt đẹp cho các đại lý Lãnh sự, tức là. đã tăng mức độ ưu tiên để hệ điều hành cung cấp cho các quy trình Consul nhiều thời gian hơn để làm việc và thực thi mã của chúng. Trong trường hợp của chúng tôi, điều này đã giải quyết vấn đề của chúng tôi.
- Một tùy chọn khác là không sử dụng Lãnh sự. Tôi có một người bạn là người rất ủng hộ Etcd. Và chúng tôi thường xuyên tranh luận với anh ấy cái nào tốt hơn Etcd hay Consul. Nhưng xét về cái nào tốt hơn, chúng tôi thường đồng ý với anh ấy rằng Consul có một tác nhân sẽ chạy trên mỗi nút có cơ sở dữ liệu. Tức là sự tương tác của Patroni với cụm Consul đều thông qua tác nhân này. Và tác nhân này trở thành nút thắt cổ chai. Nếu có điều gì đó xảy ra với đại lý, thì Patroni không thể hoạt động với cụm Lãnh sự nữa. Và đây là vấn đề. Không có đại lý trong kế hoạch Etcd. Patroni có thể làm việc trực tiếp với danh sách các máy chủ Etcd và đã giao tiếp với chúng. Về vấn đề này, nếu bạn sử dụng Etcd trong công ty của mình, thì Etcd có lẽ sẽ là lựa chọn tốt hơn Consul. Nhưng chúng tôi với khách hàng luôn bị giới hạn bởi những gì khách hàng đã chọn và sử dụng. Và chúng tôi có Lãnh sự phần lớn cho tất cả khách hàng.
- Và điểm cuối cùng là sửa lại các giá trị tham số. Chúng tôi có thể nâng các tham số này lên với hy vọng rằng các sự cố mạng ngắn hạn của chúng tôi sẽ không xảy ra và không nằm ngoài phạm vi của các tham số này. Bằng cách này, chúng tôi có thể giảm tính hung hăng của Patroni đối với tính năng tự động gửi nếu một số sự cố mạng xảy ra.
Tôi nghĩ rằng nhiều người sử dụng Patroni đã quen thuộc với lệnh này.
Lệnh này hiển thị trạng thái hiện tại của cụm. Và thoạt nhìn, bức tranh này có vẻ bình thường. Chúng tôi có một bản gốc, chúng tôi có một bản sao, không có độ trễ sao chép. Nhưng bức tranh này chính xác là bình thường cho đến khi chúng ta biết rằng cụm này phải có ba nút chứ không phải hai.
Theo đó, đã có một autofile. Và sau tệp tự động này, bản sao của chúng tôi đã biến mất. Chúng ta cần tìm ra lý do tại sao cô ấy biến mất và đưa cô ấy trở lại, khôi phục cô ấy. Và chúng tôi lại xem nhật ký và xem lý do tại sao chúng tôi có tệp tự động chuyển đổi.
Trong trường hợp này, bản sao thứ hai trở thành bản chính. Tất cả đều ổn ở đây.
Và chúng ta cần xem xét bản sao đã bị loại bỏ và bản sao nào không có trong cụm. Chúng tôi mở nhật ký Patroni và thấy rằng chúng tôi đã gặp sự cố trong quá trình kết nối với cụm ở giai đoạn pg_rewind. Để kết nối với cụm, bạn cần tua lại nhật ký giao dịch, yêu cầu nhật ký giao dịch bắt buộc từ máy chủ và sử dụng nó để bắt kịp với máy chủ.
Trong trường hợp này, chúng tôi không có nhật ký giao dịch và bản sao không thể bắt đầu. Theo đó, chúng tôi dừng Postgres do lỗi. Và do đó nó không nằm trong cụm.
Chúng ta cần hiểu tại sao nó không có trong cụm và tại sao không có nhật ký. Chúng tôi đến gặp chủ nhân mới và xem anh ta có gì trong nhật ký. Hóa ra là khi pg_rewind hoàn thành, một trạm kiểm soát đã xảy ra. Và một số nhật ký giao dịch cũ đã được đổi tên đơn giản. Khi chủ cũ cố gắng kết nối với chủ mới và truy vấn các nhật ký này, chúng đã được đổi tên, chúng không tồn tại.
Tôi đã so sánh dấu thời gian khi những sự kiện này xảy ra. Và ở đó, sự khác biệt đúng là 150 mili giây, tức là điểm kiểm tra hoàn thành sau 369 mili giây, các phân đoạn WAL đã được đổi tên. Và theo đúng nghĩa đen vào năm 517, sau 150 mili giây, quá trình tua lại bắt đầu trên bản sao cũ. Tức là, theo nghĩa đen, 150 mili giây là đủ để chúng tôi không thể kết nối và kiếm tiền từ bản sao.
Các tùy chọn là gì?
Ban đầu chúng tôi sử dụng các vị trí sao chép. Chúng tôi nghĩ rằng nó là tốt. Mặc dù ở giai đoạn đầu tiên của hoạt động, chúng tôi đã tắt các vị trí. Đối với chúng tôi, dường như nếu các vị trí tích lũy nhiều phân đoạn WAL, chúng tôi có thể loại bỏ bản gốc. Anh ta sẽ gục ngã. Chúng tôi đã phải chịu đựng một thời gian mà không có khe cắm. Và chúng tôi nhận ra rằng chúng tôi cần các vị trí, chúng tôi đã trả lại các vị trí.
Nhưng có một vấn đề ở đây, đó là khi bản chính đi tới bản sao, nó sẽ xóa các vị trí và xóa các đoạn WAL cùng với các vị trí. Và để loại bỏ vấn đề này, chúng tôi đã quyết định tăng tham số wal_keep_segments. Nó mặc định là 8 đoạn. Chúng tôi đã tăng nó lên 1 và xem chúng tôi có bao nhiêu dung lượng trống. Và chúng tôi đã tặng 000 gigabyte cho wal_keep_segments. Nghĩa là, khi chuyển đổi, chúng tôi luôn có 16 gigabyte dự trữ nhật ký giao dịch trên tất cả các nút.
Và hơn nữa - nó vẫn phù hợp với các nhiệm vụ bảo trì dài hạn. Giả sử chúng ta cần cập nhật một trong các bản sao. Và chúng tôi muốn tắt nó đi. Chúng tôi cần cập nhật phần mềm, có thể là hệ điều hành, thứ gì đó khác. Và khi chúng tôi tắt một bản sao, khe cắm cho bản sao đó cũng bị xóa. Và nếu chúng ta sử dụng một wal_keep_segments nhỏ, thì khi không có bản sao trong thời gian dài, nhật ký giao dịch sẽ bị mất. Chúng tôi sẽ tạo một bản sao, nó sẽ yêu cầu các nhật ký giao dịch mà nó đã dừng, nhưng chúng có thể không có trên bản gốc. Và bản sao cũng sẽ không thể kết nối. Vì vậy, chúng tôi giữ một lượng lớn tạp chí.
Chúng tôi có một cơ sở sản xuất. Đã có dự án đang triển khai.
Có một người quay phim. Chúng tôi đã đi vào và xem xét - mọi thứ đều theo thứ tự, các bản sao được đặt đúng chỗ, không có độ trễ sao chép. Không có lỗi trong nhật ký, mọi thứ đều theo thứ tự.
Nhóm sản phẩm nói rằng sẽ có một số dữ liệu, nhưng chúng tôi thấy dữ liệu đó từ một nguồn nhưng chúng tôi không thấy dữ liệu đó trong cơ sở dữ liệu. Và chúng ta cần hiểu chuyện gì đã xảy ra với họ.
Rõ ràng là pg_rewind đã bỏ lỡ chúng. Chúng tôi ngay lập tức hiểu điều này, nhưng đã đi xem chuyện gì đang xảy ra.
Trong nhật ký, chúng tôi luôn có thể tìm thấy thời điểm người quay phim xảy ra, ai đã trở thành chủ và chúng tôi có thể xác định ai là chủ cũ và khi nào anh ta muốn trở thành bản sao, tức là chúng tôi cần những nhật ký này để tìm ra số lượng nhật ký giao dịch mà đã bị mất.
Chủ cũ của chúng tôi đã khởi động lại. Và Patroni đã được đăng ký trong autorun. Ra mắt Patroni. Sau đó, anh ấy bắt đầu Postgres. Chính xác hơn, trước khi bắt đầu Postgres và trước khi biến nó thành bản sao, Patroni đã khởi chạy quy trình pg_rewind. Theo đó, anh ta đã xóa một phần nhật ký giao dịch, tải xuống những cái mới và kết nối. Ở đây, Patroni đã làm việc thông minh, đúng như mong đợi. Cụm đã được khôi phục. Chúng tôi có 3 nút, sau khi quay 3 nút - mọi thứ đều ổn.
Chúng tôi đã mất một số dữ liệu. Và chúng ta cần hiểu chúng ta đã mất bao nhiêu. Chúng tôi đang tìm kiếm khoảnh khắc mà chúng tôi đã tua lại. Chúng ta có thể tìm thấy nó trong các mục nhật ký như vậy. Tua lại bắt đầu, làm một cái gì đó ở đó và kết thúc.
Chúng ta cần tìm vị trí trong nhật ký giao dịch mà chủ cũ đã bỏ dở. Trong trường hợp này, đây là dấu hiệu. Và chúng ta cần một điểm đánh dấu thứ hai, tức là khoảng cách mà chủ cũ khác với chủ mới.
Chúng tôi lấy pg_wal_lsn_diff thông thường và so sánh hai điểm này. Và trong trường hợp này, chúng tôi nhận được 17 megabyte. Nhiều hay ít, mọi người tự quyết định. Bởi vì đối với ai đó 17 megabyte không phải là nhiều, đối với ai đó thì rất nhiều và không thể chấp nhận được. Ở đây, mỗi cá nhân tự xác định phù hợp với nhu cầu của doanh nghiệp.
Nhưng chúng ta đã khám phá ra điều gì cho chính mình?
Trước tiên, chúng ta phải tự quyết định - chúng ta có luôn cần Patroni tự khởi động sau khi khởi động lại hệ thống không? Điều thường xảy ra là chúng ta phải đến gặp ông chủ cũ, xem ông ấy đã đi được bao xa. Có lẽ kiểm tra các phần của nhật ký giao dịch, xem có gì ở đó. Và để hiểu liệu chúng ta có thể mất dữ liệu này hay không hoặc liệu chúng ta có cần chạy bản gốc cũ ở chế độ độc lập để lấy dữ liệu này ra hay không.
Và chỉ sau đó, chúng tôi phải quyết định xem chúng tôi có thể loại bỏ dữ liệu này hay có thể khôi phục dữ liệu đó, kết nối nút này dưới dạng bản sao với cụm của chúng tôi.
Ngoài ra, còn có thông số "maximum_lag_on_failover". Theo mặc định, nếu bộ nhớ của tôi phục vụ tôi, tham số này có giá trị là 1 megabyte.
Làm thế nào để anh ấy làm việc? Nếu bản sao của chúng tôi chậm hơn 1 megabyte dữ liệu trong độ trễ sao chép, thì bản sao này không tham gia cuộc bầu chọn. Và nếu đột nhiên có một tập tin overover, Patroni sẽ xem bản sao nào bị tụt lại phía sau. Nếu họ đứng sau một số lượng lớn nhật ký giao dịch, họ không thể trở thành chủ. Đây là một tính năng bảo mật rất tốt giúp bạn không bị mất nhiều dữ liệu.
Nhưng có một vấn đề là độ trễ sao chép trong cụm Patroni và DCS được cập nhật ở một khoảng thời gian nhất định. Tôi nghĩ 30 giây là giá trị ttl mặc định.
Theo đó, có thể xảy ra trường hợp có một độ trễ sao chép cho các bản sao trong DCS, nhưng trên thực tế có thể có độ trễ hoàn toàn khác hoặc có thể không có độ trễ nào cả, tức là điều này không phải là thời gian thực. Và nó không phải lúc nào cũng phản ánh bức tranh thực tế. Và nó không đáng để làm logic hoa mỹ trên đó.
Và nguy cơ mất mát luôn luôn tồn tại. Và trong trường hợp xấu nhất, một công thức và trong trường hợp trung bình, một công thức khác. Tức là khi lập kế hoạch triển khai Patroni và đánh giá lượng dữ liệu có thể mất, chúng ta phải dựa vào các công thức này và hình dung đại khái lượng dữ liệu có thể mất.
Và có một tin tốt. Khi chủ cũ đã đi trước, anh ta có thể tiếp tục do một số quy trình nền. Đó là, có một số loại autovacuum, anh ấy đã viết dữ liệu, lưu chúng vào nhật ký giao dịch. Và chúng ta có thể dễ dàng bỏ qua và làm mất dữ liệu này. Không có vấn đề gì trong việc này.
Và đây là cách nhật ký trông giống như nếu max_lag_on_failover được đặt và một trình quay phim đã xảy ra và bạn cần chọn một bản gốc mới. Bản sao tự đánh giá là không có khả năng tham gia bầu cử. Và cô ấy từ chối tham gia cuộc đua giành vị trí thủ lĩnh. Và cô ấy đợi một chủ mới được chọn, để sau đó cô ấy có thể kết nối với nó. Đây là một biện pháp bổ sung chống mất dữ liệu.
Ở đây, chúng tôi có một nhóm sản phẩm đã viết rằng sản phẩm của họ đang gặp sự cố với Postgres. Đồng thời, không thể truy cập bản chính vì nó không khả dụng qua SSH. Và autofile cũng không xảy ra.
Máy chủ này đã buộc phải khởi động lại. Do khởi động lại, một tệp tự động đã xảy ra, mặc dù có thể thực hiện tệp tự động thủ công, như tôi đã hiểu bây giờ. Và sau khi khởi động lại, chúng tôi sẽ xem những gì chúng tôi có với chủ hiện tại.
Đồng thời, chúng tôi đã biết trước rằng chúng tôi có vấn đề với đĩa, tức là chúng tôi đã biết từ việc theo dõi đào ở đâu và tìm gì.
Chúng tôi đã vào nhật ký postgres, bắt đầu xem điều gì đang xảy ra ở đó. Chúng tôi đã thấy các cam kết kéo dài ở đó trong một, hai, ba giây, điều này hoàn toàn không bình thường. Chúng tôi thấy rằng autovacuum của chúng tôi khởi động rất chậm và kỳ lạ. Và chúng tôi đã thấy các tệp tạm thời trên đĩa. Đó là, đây là tất cả các chỉ báo về các vấn đề với đĩa.
Chúng tôi đã xem xét hệ thống dmesg (nhật ký hạt nhân). Và chúng tôi thấy rằng chúng tôi có vấn đề với một trong các đĩa. Hệ thống con đĩa là Raid phần mềm. Chúng tôi đã xem /proc/mdstat và thấy rằng chúng tôi đang thiếu một ổ đĩa. Tức là có 8 đĩa Raid, chúng ta đang thiếu XNUMX đĩa. Nếu bạn xem kỹ trang trình bày, thì ở đầu ra, bạn có thể thấy rằng chúng tôi không có sde ở đó. Tại chúng tôi, nói một cách có điều kiện, đĩa đã bị rơi ra ngoài. Điều này gây ra các sự cố về đĩa và các ứng dụng cũng gặp sự cố khi làm việc với cụm Postgres.
Và trong trường hợp này, Patroni sẽ không giúp được gì cho chúng ta, vì Patroni không có nhiệm vụ theo dõi trạng thái của máy chủ, trạng thái của đĩa. Và chúng ta phải theo dõi những tình huống như vậy bằng cách giám sát bên ngoài. Chúng tôi đã nhanh chóng thêm giám sát đĩa vào giám sát bên ngoài.
Và đã có một ý nghĩ như vậy - phần mềm đấu kiếm hoặc giám sát có thể giúp chúng ta không? Chúng tôi nghĩ rằng anh ấy khó có thể giúp chúng tôi trong trường hợp này, bởi vì trong suốt quá trình gặp sự cố, Patroni vẫn tiếp tục tương tác với cụm DCS và không thấy có vấn đề gì. Đó là, theo quan điểm của DCS và Patroni, mọi thứ đều ổn với cụm, mặc dù trên thực tế đã có vấn đề với đĩa, có vấn đề với tính khả dụng của cơ sở dữ liệu.
Theo tôi, đây là một trong những vấn đề kỳ lạ nhất mà tôi đã nghiên cứu trong một thời gian rất dài, tôi đã đọc rất nhiều nhật ký, chọn lại và gọi nó là giả lập cụm.
Vấn đề là bản gốc cũ không thể trở thành một bản sao bình thường, tức là. Patroni đã bắt đầu nó, Patroni cho thấy rằng nút này hiện diện dưới dạng một bản sao, nhưng đồng thời nó không phải là một bản sao bình thường. Bây giờ bạn sẽ thấy tại sao. Đây là những gì tôi đã giữ lại từ việc phân tích vấn đề đó.
Và làm thế nào mà tất cả bắt đầu? Nó bắt đầu, như trong vấn đề trước, với phanh đĩa. Chúng tôi đã cam kết trong một giây, hai.
Có sự gián đoạn trong các kết nối, tức là, các khách hàng đã bị phá vỡ.
Có sự tắc nghẽn ở mức độ nghiêm trọng khác nhau.
Và theo đó, hệ thống con của đĩa không phản hồi tốt.
Và điều bí ẩn nhất đối với tôi là yêu cầu tắt máy ngay lập tức đã đến. Postgres có ba chế độ tắt máy:
- Thật thú vị khi chúng tôi đợi tất cả các máy khách tự ngắt kết nối.
- Sẽ rất nhanh khi chúng tôi buộc khách hàng phải ngắt kết nối vì chúng tôi sắp tắt máy.
- Và ngay lập tức. Trong trường hợp này, ngay lập tức thậm chí không yêu cầu khách hàng tắt, nó chỉ tắt mà không có cảnh báo. Và đối với tất cả các máy khách, hệ điều hành đã gửi một thông báo RST (một thông báo TCP rằng kết nối bị gián đoạn và máy khách không còn gì để bắt).
Ai đã gửi tín hiệu này? Các quy trình nền Postgres không gửi các tín hiệu như vậy cho nhau, tức là đây là kill-9. Họ không gửi những thứ như vậy cho nhau, họ chỉ phản ứng với những thứ như vậy, tức là đây là sự khởi động lại khẩn cấp của Postgres. Ai gửi, tôi không biết.
Tôi đã xem lệnh "cuối cùng" và tôi thấy một người cũng đã đăng nhập vào máy chủ này với chúng tôi, nhưng tôi quá ngại để đặt câu hỏi. Có lẽ đó là kill -9. Tôi sẽ thấy kill -9 trong nhật ký, bởi vì Postgres nói rằng nó đã giết -9, nhưng tôi không thấy nó trong nhật ký.
Nhìn xa hơn, tôi thấy rằng Patroni đã không ghi vào nhật ký trong một thời gian khá dài - 54 giây. Và nếu chúng ta so sánh hai dấu thời gian, sẽ không có tin nhắn nào trong khoảng 54 giây.
Và trong thời gian này đã có một autofile. Patroni đã làm một công việc tuyệt vời ở đây một lần nữa. Chủ cũ của chúng tôi không có ở đó, có chuyện gì đó đã xảy ra với anh ấy. Và cuộc bầu chọn chủ nhân mới bắt đầu. Mọi thứ diễn ra tốt đẹp ở đây. pssql01 của chúng tôi đã trở thành nhà lãnh đạo mới.
Chúng tôi có một bản sao đã trở thành một bậc thầy. Và có một phản ứng thứ hai. Và đã có vấn đề với bản sao thứ hai. Cô thử cấu hình lại. Theo tôi hiểu, cô ấy đã cố gắng thay đổi recovery.conf, khởi động lại Postgres và kết nối với chủ mới. Cô ấy viết tin nhắn cứ sau 10 giây rằng cô ấy đang cố gắng, nhưng cô ấy không thành công.
Và trong những lần thử này, một tín hiệu tắt máy ngay lập tức đến chủ cũ. Master được khởi động lại. Và quá trình khôi phục cũng dừng lại vì bản gốc cũ khởi động lại. Tức là bản sao không thể kết nối với nó vì nó đang ở chế độ tắt máy.
Tại một số thời điểm, nó hoạt động, nhưng quá trình sao chép không bắt đầu.
Dự đoán duy nhất của tôi là có một địa chỉ chính cũ trong recovery.conf. Và khi một chủ mới xuất hiện, bản sao thứ hai vẫn cố gắng kết nối với chủ cũ.
Khi Patroni khởi động trên bản sao thứ hai, nút khởi động nhưng không thể sao chép. Và độ trễ sao chép đã được hình thành, trông giống như thế này. Đó là, cả ba nút đều ở đúng vị trí, nhưng nút thứ hai bị tụt lại phía sau.
Đồng thời, nếu bạn nhìn vào nhật ký đã được viết, bạn có thể thấy rằng quá trình sao chép không thể bắt đầu vì các nhật ký giao dịch khác nhau. Và những nhật ký giao dịch mà chủ cung cấp, được chỉ định trong recovery.conf, đơn giản là không phù hợp với nút hiện tại của chúng tôi.
Và ở đây tôi đã phạm sai lầm. Tôi phải đến và xem những gì trong recovery.conf để kiểm tra giả thuyết của mình rằng chúng tôi đang kết nối với chủ nhân sai. Nhưng sau đó tôi mới xử lý việc này và nó không xảy ra với tôi, hoặc tôi thấy rằng bản sao bị tụt lại phía sau và sẽ phải nạp lại, tức là bằng cách nào đó tôi đã làm việc cẩu thả. Đây là khớp của tôi.
Sau 30 phút, quản trị viên đã đến, tức là tôi đã khởi động lại Patroni trên bản sao. Tôi đã chấm dứt nó, tôi nghĩ rằng nó sẽ phải được nạp lại. Và tôi nghĩ - Tôi sẽ khởi động lại Patroni, có thể điều gì đó tốt đẹp sẽ xảy ra. Phục hồi bắt đầu. Và cơ sở thậm chí đã mở, nó đã sẵn sàng để chấp nhận các kết nối.
Nhân rộng đã bắt đầu. Nhưng một phút sau, cô ấy gặp phải lỗi rằng nhật ký giao dịch không phù hợp với cô ấy.
Tôi nghĩ rằng tôi muốn khởi động lại một lần nữa. Tôi đã khởi động lại Patroni một lần nữa và tôi đã không khởi động lại Postgres mà khởi động lại Patroni với hy vọng rằng nó sẽ khởi động cơ sở dữ liệu một cách kỳ diệu.
Quá trình sao chép bắt đầu lại, nhưng các dấu hiệu trong nhật ký giao dịch đã khác, chúng không giống với lần thử bắt đầu trước đó. Sao chép dừng lại một lần nữa. Và thông điệp đã hơi khác một chút. Và nó không có nhiều thông tin cho tôi.
Và sau đó tôi chợt nhận ra - điều gì sẽ xảy ra nếu tôi khởi động lại Postgres, tại thời điểm này, tôi tạo một điểm kiểm tra trên máy chủ hiện tại để di chuyển điểm trong nhật ký giao dịch về phía trước một chút để quá trình khôi phục bắt đầu từ một thời điểm khác? Thêm vào đó, chúng tôi vẫn còn cổ phiếu của WAL.
Tôi đã khởi động lại Patroni, thực hiện một vài điểm kiểm tra trên bản gốc, một vài điểm khởi động lại trên bản sao khi nó mở. Và nó đã giúp. Tôi đã suy nghĩ rất lâu tại sao nó lại hữu ích và nó hoạt động như thế nào. Và bản sao bắt đầu. Và bản sao không còn bị rách nữa.
Một vấn đề như vậy đối với tôi là một trong những vấn đề bí ẩn hơn, mà tôi vẫn băn khoăn về điều gì đã thực sự xảy ra ở đó.
Ý nghĩa ở đây là gì? Patroni có thể hoạt động như dự định và không có bất kỳ lỗi nào. Nhưng đồng thời, đây không phải là sự đảm bảo 100% rằng mọi thứ đều ổn với chúng tôi. Bản sao có thể bắt đầu, nhưng nó có thể ở trạng thái bán hoạt động và ứng dụng không thể hoạt động với một bản sao như vậy vì sẽ có dữ liệu cũ.
Và sau khi quay phim, bạn luôn cần kiểm tra xem mọi thứ có theo thứ tự với cụm không, nghĩa là có đủ số lượng bản sao cần thiết, không có độ trễ sao chép.
Và khi chúng ta giải quyết những vấn đề này, tôi sẽ đưa ra các khuyến nghị. Tôi đã cố gắng kết hợp chúng thành hai slide. Có lẽ, tất cả các câu chuyện có thể được kết hợp thành hai slide và chỉ được kể.
Khi bạn sử dụng Patroni, bạn phải có giám sát. Bạn phải luôn biết khi nào xảy ra quá trình tự động chuyển tệp, bởi vì nếu bạn không biết mình đã có một tệp tự động chuyển, bạn sẽ không kiểm soát được cụm. Và điều đó thật tệ.
Sau mỗi lần quay phim, chúng tôi luôn phải kiểm tra cụm theo cách thủ công. Chúng tôi cần đảm bảo rằng chúng tôi luôn có số lượng bản sao cập nhật, không có độ trễ sao chép, không có lỗi trong nhật ký liên quan đến sao chép phát trực tuyến, với Patroni, với hệ thống DCS.
Tự động hóa có thể hoạt động thành công, Patroni là một công cụ rất tốt. Nó có thể hoạt động, nhưng điều này sẽ không đưa cụm đến trạng thái mong muốn. Và nếu chúng ta không tìm hiểu về nó, chúng ta sẽ gặp rắc rối.
Và Patroni không phải là viên đạn bạc. Chúng ta vẫn cần hiểu cách Postgres hoạt động, cách sao chép hoạt động và cách Patroni hoạt động với Postgres cũng như cách cung cấp giao tiếp giữa các nút. Điều này là cần thiết để có thể khắc phục sự cố bằng tay của bạn.
Làm thế nào để tôi tiếp cận vấn đề chẩn đoán? Tình cờ là chúng tôi làm việc với các máy khách khác nhau và không ai có ngăn xếp ELK và chúng tôi phải sắp xếp nhật ký bằng cách mở 6 bảng điều khiển và 2 tab. Trong một tab, đây là nhật ký Patroni cho mỗi nút, trong tab còn lại, đây là nhật ký Lãnh sự hoặc Postgres nếu cần. Rất khó để chẩn đoán điều này.
Tôi đã thực hiện những cách tiếp cận nào? Đầu tiên, tôi luôn xem khi người quay phim đến. Và đối với tôi đây là một bước ngoặt. Tôi nhìn vào những gì đã xảy ra trước người quay phim, trong khi quay phim và sau khi quay phim. Fileover có hai điểm: đây là thời gian bắt đầu và kết thúc.
Tiếp theo, tôi tìm trong nhật ký các sự kiện xảy ra trước trình quay phim, tức là các sự kiện xảy ra trước trình quay phim, tức là tôi tìm kiếm lý do tại sao trình quay phim lại xảy ra.
Và điều này đưa ra một bức tranh về sự hiểu biết những gì đã xảy ra và những gì có thể được thực hiện trong tương lai để những trường hợp như vậy không xảy ra (và kết quả là không có người quay phim).
Và chúng ta thường tìm ở đâu? tôi nhìn:
- Đầu tiên, đến nhật ký Patroni.
- Tiếp theo, tôi xem nhật ký Postgres hoặc nhật ký DCS, tùy thuộc vào nội dung được tìm thấy trong nhật ký Patroni.
- Và nhật ký hệ thống đôi khi cũng cung cấp thông tin về nguyên nhân gây ra trình quay phim.
Tôi cảm thấy thế nào về Patroni? Tôi có mối quan hệ rất tốt với Patroni. Theo tôi, đây là điều tốt nhất hiện nay. Tôi biết nhiều sản phẩm khác. Đó là Stolon, Repmgr, PG_auto_failover, PAF. 4 công cụ. Tôi đã thử tất cả. Patroni là yêu thích của tôi.
Nếu họ hỏi tôi: "Tôi có giới thiệu Patroni không?". Tôi sẽ nói có, bởi vì tôi thích Patroni. Và tôi nghĩ tôi đã học được cách nấu nó.
Nếu bạn muốn xem Patroni còn có vấn đề gì khác ngoài những vấn đề tôi đã đề cập, bạn luôn có thể xem trang này trên GitHub. Có nhiều câu chuyện khác nhau và nhiều vấn đề thú vị được thảo luận ở đó. Và kết quả là, một số lỗi đã được đưa ra và giải quyết, nghĩa là đây là một bài đọc thú vị.
Có một số câu chuyện thú vị về những người tự bắn vào chân mình. Rất nhiều thông tin. Bạn đọc và hiểu rằng không cần thiết phải làm như vậy. Tôi tự đánh dấu mình.
Và tôi muốn gửi lời cảm ơn sâu sắc tới Zalando vì đã phát triển dự án này, cụ thể là Alexander Kukushkin và Alexey Klyukin. Aleksey Klyukin là một trong những đồng tác giả, ông không còn làm việc tại Zalando, nhưng đây là hai người bắt đầu làm việc với sản phẩm này.
Và tôi nghĩ rằng Patroni là một thứ rất tuyệt. Tôi rất vui vì cô ấy tồn tại, thật thú vị với cô ấy. Và xin chân thành cảm ơn tất cả những người đóng góp đã viết các bản vá lỗi cho Patroni. Tôi hy vọng rằng Patroni sẽ trưởng thành hơn, ngầu hơn và hiệu quả hơn theo tuổi tác. Nó đã hoạt động, nhưng tôi hy vọng nó sẽ tốt hơn nữa. Do đó, nếu bạn định sử dụng Patroni, thì đừng sợ. Đây là một giải pháp tốt, nó có thể được thực hiện và sử dụng.
Đó là tất cả. Nếu bạn có câu hỏi, cứ tự nhiên.
câu hỏi
Cảm ơn bạn đã báo cáo! Nếu sau khi quay phim, bạn vẫn cần xem xét kỹ lưỡng ở đó, thì tại sao chúng ta lại cần một trình quay phim tự động?
Vì là hàng mới Chúng tôi mới ở bên cô ấy được một năm. Tốt hơn để được an toàn. Chúng tôi muốn đến và thấy rằng mọi thứ thực sự diễn ra theo cách nó nên làm. Đây là mức độ không tin tưởng của người lớn - tốt hơn hết bạn nên kiểm tra kỹ và xem.
Ví dụ, chúng tôi đã đi vào buổi sáng và xem xét, phải không?
Không phải buổi sáng, chúng tôi thường tìm hiểu về autofile gần như ngay lập tức. Chúng tôi nhận được thông báo, chúng tôi thấy rằng một tệp tự động đã xảy ra. Chúng tôi gần như ngay lập tức đi và xem xét. Nhưng tất cả những kiểm tra này nên được đưa đến cấp độ giám sát. Nếu bạn truy cập Patroni qua API REST, sẽ có một lịch sử. Theo lịch sử, bạn có thể xem dấu thời gian khi trình quay phim xảy ra. Dựa trên điều này, giám sát có thể được thực hiện. Bạn có thể xem lịch sử, có bao nhiêu sự kiện ở đó. Nếu chúng tôi có nhiều sự kiện hơn, thì tệp tự động đã xảy ra. Bạn có thể đi và xem. Hoặc hệ thống tự động hóa giám sát của chúng tôi đã kiểm tra để đảm bảo rằng chúng tôi có tất cả các bản sao tại chỗ, không có độ trễ và mọi thứ đều ổn.
Cảm ơn bạn!
Cảm ơn rất nhiều vì câu chuyện tuyệt vời! Nếu chúng ta chuyển cụm DCS đi đâu đó xa cụm Postgres, thì cụm này cũng cần được bảo dưỡng định kỳ? Các phương pháp hay nhất mà một số phần của cụm DCS cần phải tắt là gì, phải làm gì với chúng, v.v.? Làm thế nào để toàn bộ cấu trúc này tồn tại? Và làm thế nào để bạn làm những điều này?
Đối với một công ty, cần phải tạo ra một ma trận các vấn đề, điều gì sẽ xảy ra nếu một trong các thành phần hoặc một số thành phần bị lỗi. Theo ma trận này, chúng tôi lần lượt duyệt qua tất cả các thành phần và xây dựng các kịch bản trong trường hợp các thành phần này gặp sự cố. Theo đó, đối với mỗi tình huống thất bại, bạn có thể có một kế hoạch hành động để phục hồi. Và trong trường hợp của DCS, nó là một phần của cơ sở hạ tầng tiêu chuẩn. Và quản trị viên quản lý nó, và chúng tôi đã dựa vào các quản trị viên quản lý nó và khả năng khắc phục sự cố của họ trong trường hợp xảy ra sự cố. Nếu không có DCS nào cả, thì chúng tôi sẽ triển khai nó, nhưng đồng thời chúng tôi không đặc biệt giám sát nó, vì chúng tôi không chịu trách nhiệm về cơ sở hạ tầng, nhưng chúng tôi đưa ra khuyến nghị về cách thức và nội dung cần giám sát.
Tức là tôi đã hiểu đúng rằng tôi cần tắt Patroni, tắt trình quay phim, tắt mọi thứ trước khi làm bất cứ điều gì với máy chủ?
Nó phụ thuộc vào số lượng nút chúng tôi có trong cụm DCS. Nếu có nhiều nút và nếu chúng tôi chỉ vô hiệu hóa một trong các nút (bản sao), thì cụm sẽ duy trì số đại biểu dự kiến. Và Patroni vẫn hoạt động. Và không có gì được kích hoạt. Nếu chúng tôi có một số hoạt động phức tạp ảnh hưởng đến nhiều nút hơn, sự vắng mặt của chúng có thể làm hỏng số đại biểu cần thiết, thì - vâng, có thể hợp lý khi tạm dừng Patroni. Nó có một lệnh tương ứng - tạm dừng bảo trợ, tiếp tục bảo trợ. Chúng tôi chỉ tạm dừng và trình lọc tự động không hoạt động vào thời điểm đó. Chúng tôi bảo trì cụm DCS, sau đó chúng tôi tạm dừng và tiếp tục hoạt động.
Cảm ơn bạn rất nhiều!
Cảm ơn bạn rất nhiều vì báo cáo của bạn! Nhóm sản phẩm cảm thấy thế nào về việc dữ liệu bị mất?
Các nhóm sản phẩm không quan tâm và các trưởng nhóm lo lắng.
Có gì đảm bảo?
Bảo lãnh là rất khó khăn. Alexander Kukushkin có một báo cáo “Cách tính RPO và RTO”, tức là thời gian khôi phục và lượng dữ liệu chúng ta có thể mất. Tôi nghĩ chúng ta cần tìm những slide này và nghiên cứu chúng. Theo như tôi nhớ, có các bước cụ thể về cách tính toán những thứ này. Chúng ta có thể mất bao nhiêu giao dịch, bao nhiêu dữ liệu chúng ta có thể mất. Như một tùy chọn, chúng tôi có thể sử dụng sao chép đồng bộ ở cấp độ Patroni, nhưng đây là con dao hai lưỡi: chúng tôi có độ tin cậy của dữ liệu hoặc chúng tôi mất tốc độ. Có sao chép đồng bộ, nhưng nó cũng không đảm bảo bảo vệ 100% khỏi mất dữ liệu.
Alexey, cảm ơn vì báo cáo tuyệt vời! Bất kỳ kinh nghiệm nào với việc sử dụng Patroni để bảo vệ mức XNUMX? Đó là, kết hợp với chế độ chờ đồng bộ? Đây là câu hỏi đầu tiên. Và câu hỏi thứ hai. Bạn đã sử dụng các giải pháp khác nhau. Chúng tôi đã sử dụng Repmgr, nhưng không có bộ lọc tự động và hiện chúng tôi đang lên kế hoạch bao gồm bộ lọc tự động. Và chúng tôi coi Patroni là một giải pháp thay thế. Bạn có thể nói gì về lợi thế so với Repmgr?
Câu hỏi đầu tiên là về các bản sao đồng bộ. Không ai sử dụng bản sao đồng bộ ở đây, vì mọi người đều sợ hãi (Về nguyên tắc, một số khách hàng đã sử dụng nó, họ không nhận thấy các vấn đề về hiệu suất - ghi chú của diễn giả). Nhưng chúng tôi đã phát triển một quy tắc cho chính mình rằng phải có ít nhất ba nút trong một cụm sao chép đồng bộ, bởi vì nếu chúng tôi có hai nút và nếu bản chính hoặc bản sao bị lỗi, thì Patroni sẽ chuyển nút này sang chế độ Độc lập để ứng dụng tiếp tục hoạt động. công việc. Trong trường hợp này, có nguy cơ mất dữ liệu.
Về câu hỏi thứ hai, chúng tôi đã sử dụng Repmgr và vẫn sử dụng với một số khách hàng vì lý do lịch sử. Có thể nói gì? Patroni đi kèm với bộ lọc tự động ngay lập tức, Repmgr đi kèm với bộ lọc tự động như một tính năng bổ sung cần được bật. Chúng ta cần chạy trình nền Repmgr trên mỗi nút và sau đó chúng ta có thể định cấu hình trình lọc tự động.
Repmgr kiểm tra xem các nút Postgres có còn hoạt động không. Các quy trình Repmgr kiểm tra sự tồn tại của nhau, đây không phải là cách tiếp cận hiệu quả. có thể xảy ra các trường hợp cô lập mạng phức tạp, trong đó một cụm Repmgr lớn có thể tách thành nhiều cụm nhỏ hơn và tiếp tục hoạt động. Tôi đã không theo dõi Repmgr trong một thời gian dài, có thể nó đã được sửa ... hoặc có thể không. Nhưng việc loại bỏ thông tin về trạng thái của cụm trong DCS, như Stolon, Patroni thực hiện, là lựa chọn khả thi nhất.
Alexey, tôi có một câu hỏi, có thể là một câu hỏi ngớ ngẩn hơn. Trong một trong những ví dụ đầu tiên, bạn đã chuyển DCS từ máy cục bộ sang máy chủ từ xa. Chúng tôi hiểu rằng mạng là một thứ có đặc điểm riêng, nó tự tồn tại. Và điều gì sẽ xảy ra nếu vì lý do nào đó cụm DCS không khả dụng? Tôi sẽ không nói lý do, có thể có rất nhiều lý do: từ bàn tay quanh co của các nhà mạng đến các vấn đề thực sự.
Tôi không nói toạc ra, nhưng cụm DCS cũng phải là chuyển đổi dự phòng, tức là số nút là số lẻ để đáp ứng đủ đại biểu. Điều gì xảy ra nếu cụm DCS không khả dụng hoặc không thể đáp ứng số đại biểu cần thiết, tức là một số loại mạng bị chia tách hoặc lỗi nút? Trong trường hợp này, cụm Patroni chuyển sang chế độ chỉ đọc. Cụm Patroni không thể xác định trạng thái của cụm và phải làm gì. Nó không thể liên lạc với DCS và lưu trữ trạng thái cụm mới ở đó, vì vậy toàn bộ cụm chuyển sang chế độ chỉ đọc. Và đợi sự can thiệp thủ công từ người vận hành hoặc chờ DCS khôi phục.
Nói một cách đại khái, DCS trở thành một dịch vụ quan trọng đối với chúng tôi như chính cơ sở?
Vâng vâng. Trong rất nhiều công ty hiện đại, Service Discovery là một phần không thể thiếu của cơ sở hạ tầng. Nó đang được triển khai ngay cả trước khi có cơ sở dữ liệu trong cơ sở hạ tầng. Nói một cách tương đối, cơ sở hạ tầng đã được khởi chạy, triển khai ở DC và chúng tôi ngay lập tức có Khám phá dịch vụ. Nếu là Consul thì có thể build DNS trên đó. Nếu đây là Etcd, thì có thể có một phần từ cụm Kubernetes, trong đó mọi thứ khác sẽ được triển khai. Đối với tôi, có vẻ như Service Discovery đã là một phần không thể thiếu của cơ sở hạ tầng hiện đại. Và họ nghĩ về nó sớm hơn nhiều so với về cơ sở dữ liệu.
Cảm ơn bạn!
Nguồn: www.habr.com