Tôi khuyên bạn nên đọc bản ghi báo cáo từ đầu năm 2016 của Andrey Salnikov “Các lỗi điển hình trong các ứng dụng dẫn đến sự phình to trong postgresql”
Trong báo cáo này, tôi sẽ phân tích các lỗi chính trong ứng dụng phát sinh ở giai đoạn thiết kế và viết mã ứng dụng. Và tôi sẽ chỉ xử lý những lỗi dẫn đến sự phình to trong Postgresql. Theo quy định, đây là sự khởi đầu cho sự kết thúc hiệu suất của toàn bộ hệ thống của bạn, mặc dù ban đầu không có điều kiện tiên quyết nào cho việc này.
Rất vui được chào đón mọi người! Báo cáo này không mang tính kỹ thuật như báo cáo trước của đồng nghiệp của tôi. Báo cáo này chủ yếu nhắm đến các nhà phát triển hệ thống phụ trợ vì chúng tôi có số lượng khách hàng khá lớn. Và tất cả họ đều mắc những sai lầm giống nhau. Tôi sẽ kể cho bạn nghe về họ. Tôi sẽ giải thích những sai lầm tai hại và tồi tệ này sẽ dẫn tới điều gì.
Tại sao mắc phải sai lầm? Chúng được thực hiện vì hai lý do: một cách ngẫu nhiên, có thể nó sẽ thành công và do thiếu hiểu biết về một số cơ chế xảy ra ở cấp độ giữa cơ sở dữ liệu và ứng dụng, cũng như trong chính cơ sở dữ liệu đó.
Tôi sẽ cho bạn ba ví dụ với những hình ảnh khủng khiếp về mức độ tồi tệ của mọi việc. Tôi sẽ kể ngắn gọn cho bạn về cơ chế xảy ra ở đó. Và cách giải quyết chúng, khi nào chúng xảy ra và sử dụng những phương pháp phòng ngừa nào để ngăn ngừa sai sót. Tôi sẽ cho bạn biết về các công cụ phụ trợ và cung cấp các liên kết hữu ích.
Tôi đã sử dụng cơ sở dữ liệu thử nghiệm nơi tôi có hai bảng. Một tấm ghi tài khoản khách hàng, tấm kia ghi giao dịch trên những tài khoản này. Và với tần suất nhất định, chúng tôi cập nhật số dư trên các tài khoản này.
Dữ liệu ban đầu của tấm: khá nhỏ, 2 MB. Thời gian phản hồi cho cơ sở dữ liệu và đặc biệt cho biển hiệu cũng rất tốt. Và tải khá tốt - 2 thao tác mỗi giây theo bảng.
Và thông qua báo cáo này tôi sẽ cho bạn xem biểu đồ để bạn có thể hiểu rõ điều gì đang xảy ra. Sẽ luôn có 2 slide có đồ thị. Trang trình bày đầu tiên là những gì diễn ra chung trên máy chủ.
Và trong tình huống này, chúng ta thấy rằng chúng ta thực sự có một dấu hiệu nhỏ. Chỉ số này nhỏ ở mức 2 MB. Đây là biểu đồ đầu tiên bên trái.
Thời gian phản hồi trung bình trên máy chủ cũng ổn định và ngắn. Đây là biểu đồ trên cùng bên phải.
Biểu đồ phía dưới bên trái hiển thị các giao dịch dài nhất. Chúng tôi thấy rằng các giao dịch được hoàn thành nhanh chóng. Và máy hút bụi tự động vẫn chưa hoạt động ở đây vì đây chỉ là thử nghiệm ban đầu. Nó sẽ tiếp tục hoạt động và sẽ hữu ích cho chúng tôi.
Slide thứ hai sẽ luôn được dành riêng cho tấm đang được kiểm tra. Trong tình huống này, chúng tôi liên tục cập nhật số dư tài khoản của khách hàng. Và chúng tôi thấy rằng thời gian phản hồi trung bình cho một thao tác cập nhật là khá tốt, chưa đến một phần nghìn giây. Chúng tôi thấy rằng tài nguyên bộ xử lý (đây là biểu đồ phía trên bên phải) cũng được tiêu thụ đồng đều và khá ít.
Biểu đồ phía dưới bên phải hiển thị lượng bộ nhớ ổ đĩa và hoạt động mà chúng tôi trải qua để tìm kiếm dòng mong muốn trước khi cập nhật nó. Và số phép tính theo dấu là 2 phép tính mỗi giây, như tôi đã nói lúc đầu.
Và bây giờ chúng ta gặp phải một bi kịch. Vì lý do nào đó có một giao dịch bị lãng quên từ lâu. Những lý do thường là tầm thường:
- Một trong những điều phổ biến nhất là chúng tôi bắt đầu truy cập dịch vụ bên ngoài trong mã ứng dụng. Và dịch vụ này không trả lời chúng tôi. Nghĩa là, chúng tôi đã mở một giao dịch, thực hiện thay đổi trong cơ sở dữ liệu và chuyển từ ứng dụng sang đọc thư hoặc đến một dịch vụ khác trong cơ sở hạ tầng của chúng tôi và vì lý do nào đó mà nó không phản hồi cho chúng tôi. Và phiên của chúng tôi bị kẹt trong tình trạng không biết khi nào mới được giải quyết.
- Tình huống thứ hai là khi một ngoại lệ xảy ra trong mã của chúng ta vì lý do nào đó. Và trong trường hợp ngoại lệ, chúng tôi không xử lý việc đóng giao dịch. Và chúng tôi đã kết thúc một phiên treo cổ với một giao dịch mở.
- Và trường hợp cuối cùng cũng là một trường hợp khá phổ biến. Đây là mã chất lượng thấp. Một số khung mở một giao dịch. Nó bị treo và bạn có thể không biết trong ứng dụng rằng mình đang bị treo.
Những điều như vậy dẫn đến đâu?
Đến mức các bảng và chỉ mục của chúng tôi bắt đầu phình to lên đáng kể. Đây chính xác là hiệu ứng sưng lên tương tự. Đối với cơ sở dữ liệu, điều này có nghĩa là thời gian phản hồi của cơ sở dữ liệu sẽ tăng rất mạnh và tải trên máy chủ cơ sở dữ liệu sẽ tăng lên. Và kết quả là ứng dụng của chúng ta sẽ bị ảnh hưởng. Bởi vì nếu bạn dành 10 mili giây cho mã của mình cho một yêu cầu tới cơ sở dữ liệu, 10 mili giây cho logic, thì hàm của bạn sẽ mất 20 mili giây để hoàn thành. Và bây giờ hoàn cảnh của bạn sẽ hoàn toàn đáng buồn.
Và hãy xem điều gì sẽ xảy ra. Biểu đồ phía dưới bên trái cho thấy chúng ta có một giao dịch dài. Và nếu chúng ta nhìn vào biểu đồ phía trên bên trái, chúng ta sẽ thấy rằng kích thước bảng của chúng ta đột ngột tăng từ hai megabyte lên 300 megabyte. Đồng thời, lượng dữ liệu trong bảng không thay đổi, tức là ở đó có một lượng rác khá lớn.
Tình hình chung về thời gian phản hồi trung bình của máy chủ cũng đã thay đổi theo nhiều mức độ. Nghĩa là, tất cả các yêu cầu trên máy chủ bắt đầu giảm hoàn toàn. Đồng thời, các quy trình Postgres nội bộ đã được triển khai dưới dạng autovacuum, đang cố gắng làm điều gì đó và tiêu tốn tài nguyên.
Chuyện gì đang xảy ra với dấu hiệu của chúng ta vậy? Giống nhau. Thời gian phản hồi trung bình của chúng tôi theo dấu hiệu đã tăng lên nhiều bậc. Cụ thể về mức tiêu thụ tài nguyên, chúng tôi thấy rằng tải cho bộ xử lý đã tăng lên rất nhiều. Đây là biểu đồ trên cùng bên phải. Và nó đã tăng lên vì bộ xử lý phải sắp xếp một loạt dòng vô dụng để tìm kiếm dòng cần thiết. Đây là biểu đồ phía dưới bên phải. Và kết quả là số lượng cuộc gọi mỗi giây của chúng tôi bắt đầu giảm rất đáng kể do cơ sở dữ liệu không có thời gian để xử lý cùng số lượng yêu cầu.
Chúng ta cần phải quay trở lại với cuộc sống. Chúng tôi lên mạng và phát hiện ra rằng các giao dịch kéo dài sẽ dẫn đến nhiều vấn đề. Chúng tôi tìm và hủy giao dịch này. Và mọi thứ đang trở nên bình thường đối với chúng tôi. Mọi thứ đều hoạt động như bình thường.
Chúng tôi đã bình tĩnh lại, nhưng sau một thời gian, chúng tôi bắt đầu nhận thấy rằng ứng dụng không hoạt động giống như trước khi xảy ra trường hợp khẩn cấp. Yêu cầu vẫn được xử lý chậm hơn và chậm hơn đáng kể. Cụ thể là chậm hơn một lần rưỡi đến hai lần trong ví dụ của tôi. Tải trên máy chủ cũng cao hơn so với trước khi xảy ra tai nạn.
Và câu hỏi: "Điều gì đang xảy ra với căn cứ vào lúc này?" Và tình huống sau đây xảy ra với căn cứ. Trên biểu đồ giao dịch bạn có thể thấy nó đã dừng lại và thực sự không có giao dịch dài hạn nào cả. Nhưng kích thước của biển báo đã tăng lên đáng kể trong vụ tai nạn. Và kể từ đó chúng không hề giảm đi. Thời gian trung bình trên cơ sở đã ổn định. Và câu trả lời dường như đang đến một cách thỏa đáng với tốc độ mà chúng ta có thể chấp nhận được. Máy hút bụi tự động hoạt động tích cực hơn và bắt đầu làm gì đó với biển báo vì nó cần sàng lọc nhiều dữ liệu hơn.
Cụ thể, theo bảng kiểm tra với các tài khoản, nơi chúng tôi thay đổi số dư: thời gian phản hồi cho một yêu cầu dường như đã trở lại bình thường. Nhưng thực tế nó cao hơn gấp rưỡi.
Và từ tải trên bộ xử lý, chúng ta thấy rằng tải trên bộ xử lý chưa trở về giá trị yêu cầu trước khi xảy ra sự cố. Và lý do nằm chính xác ở biểu đồ phía dưới bên phải. Có thể thấy rằng một lượng bộ nhớ nhất định đang được tìm kiếm ở đó. Tức là, để tìm được dòng cần thiết, chúng ta sẽ lãng phí tài nguyên của máy chủ cơ sở dữ liệu trong khi sắp xếp những dữ liệu vô dụng. Số lượng giao dịch mỗi giây đã ổn định.
Nói chung là ổn, nhưng tình hình còn tệ hơn trước. Xóa sự xuống cấp của cơ sở dữ liệu do ứng dụng của chúng tôi hoạt động với cơ sở dữ liệu này.
Và để hiểu điều gì đang diễn ra ở đó, nếu bạn chưa xem báo cáo trước, bây giờ chúng ta hãy xem một chút lý thuyết. Lý thuyết về quá trình nội bộ Tại sao phải dùng máy hút bụi ô tô và nó có tác dụng gì?
Nghĩa đen ngắn gọn cho dễ hiểu. Tại một thời điểm nào đó chúng ta có một cái bàn. Chúng tôi có các hàng trong bảng. Những dòng này có thể đang hoạt động, còn sống và là những gì chúng ta cần bây giờ. Chúng được đánh dấu bằng màu xanh lá cây trong hình. Và có những thời hạn đã được giải quyết, đã được cập nhật và các mục mới đã xuất hiện trên đó. Và chúng được đánh dấu là chúng không còn được cơ sở dữ liệu quan tâm nữa. Nhưng chúng nằm trong bảng do tính năng Postgres.
Tại sao bạn cần máy hút bụi ô tô? Autovacuum tại một thời điểm nào đó xuất hiện, truy cập vào cơ sở dữ liệu và hỏi nó: “Xin vui lòng cho tôi id của giao dịch cũ nhất hiện đang mở trong cơ sở dữ liệu.” Cơ sở dữ liệu trả về id này. Và máy hút bụi tự động, dựa vào nó, sẽ sắp xếp theo các dòng trong bảng. Và nếu anh ta thấy rằng một số dòng đã bị thay đổi bởi các giao dịch cũ hơn nhiều thì anh ta có quyền đánh dấu chúng là những dòng mà chúng ta có thể sử dụng lại trong tương lai bằng cách ghi dữ liệu mới vào đó. Đây là một quá trình nền.
Tại thời điểm này, chúng tôi tiếp tục làm việc với cơ sở dữ liệu và tiếp tục thực hiện một số thay đổi đối với bảng. Và trên những dòng này, những dòng mà chúng ta có thể sử dụng lại, chúng ta viết dữ liệu mới. Và do đó, chúng ta có một chu kỳ, tức là lúc nào một số dòng cũ chết xuất hiện ở đó, thay vì chúng, chúng ta viết ra những dòng mới mà chúng ta cần. Và đây là trạng thái bình thường để PostgreSQL hoạt động.
Điều gì đã xảy ra trong vụ tai nạn? Làm thế nào quá trình này xảy ra ở đó?
Chúng tôi có một biển báo ở tình trạng nào đó, một số đang hoạt động, một số đã chết. Máy hút bụi ô tô đã về. Anh ấy hỏi cơ sở dữ liệu giao dịch lâu đời nhất của chúng tôi là gì và id của nó là gì. Tôi đã nhận được id này, có thể cách đây nhiều giờ, có thể là mười phút trước. Nó phụ thuộc vào mức độ tải của bạn đối với cơ sở dữ liệu của bạn. Và anh ấy đã đi tìm những dòng mà anh ấy có thể đánh dấu là đã được sử dụng lại. Và tôi không tìm thấy những dòng như vậy trong bảng của chúng tôi.
Nhưng lúc này chúng ta vẫn tiếp tục làm việc với cái bàn. Chúng tôi làm điều gì đó trong đó, cập nhật nó, thay đổi dữ liệu. Cơ sở dữ liệu nên làm gì vào lúc này? Cô ấy không có lựa chọn nào khác ngoài việc thêm dòng mới vào cuối bảng hiện có. Và do đó kích thước bảng của chúng tôi bắt đầu tăng lên.
Trong thực tế, chúng ta cần những đường màu xanh lá cây để hoạt động. Nhưng trong quá trình giải quyết vấn đề như vậy, hóa ra tỷ lệ đường màu xanh lá cây trên toàn bộ bảng là cực kỳ thấp.
Và khi chúng ta thực hiện một truy vấn, cơ sở dữ liệu phải đi qua tất cả các dòng: cả màu đỏ và màu xanh lá cây, để tìm ra dòng mong muốn. Và tác động của việc làm đầy một bảng với những dữ liệu vô dụng được gọi là “sự phình to”, điều này cũng ngốn hết dung lượng ổ đĩa của chúng ta. Hãy nhớ rằng, nó là 2 MB, nó đã trở thành 300 MB? Bây giờ hãy đổi megabyte thành gigabyte và bạn sẽ nhanh chóng mất tất cả tài nguyên đĩa của mình.
Những hậu quả nào có thể xảy ra với chúng ta?
- Trong ví dụ của tôi, bảng và chỉ mục đã tăng 150 lần. Một số khách hàng của chúng tôi đã gặp phải nhiều trường hợp nghiêm trọng hơn khi họ bắt đầu hết dung lượng ổ đĩa.
- Kích thước của các bảng sẽ không bao giờ giảm. Autovacuum trong một số trường hợp có thể cắt bỏ phần đuôi bàn nếu chỉ có các đường chết. Nhưng vì có sự quay liên tục nên một dòng màu xanh lá cây có thể cố định ở cuối và không được cập nhật, trong khi tất cả những dòng khác sẽ được ghi ở đâu đó ở đầu đĩa. Nhưng đây khó có thể xảy ra đến mức bản thân bảng của bạn sẽ thu nhỏ kích thước, vì vậy bạn không nên hy vọng vào điều đó.
- Cơ sở dữ liệu cần phải sắp xếp cả đống dòng vô dụng. Và chúng ta lãng phí tài nguyên ổ đĩa, lãng phí tài nguyên bộ xử lý và điện năng.
- Và điều này ảnh hưởng trực tiếp đến ứng dụng của chúng tôi, bởi vì nếu lúc đầu chúng tôi dành 10 mili giây cho yêu cầu, 10 mili giây cho mã của chúng tôi, thì trong thời gian xảy ra sự cố, chúng tôi bắt đầu dành một giây cho yêu cầu và 10 mili giây cho mã, tức là một đơn đặt hàng mức độ hiệu suất ứng dụng giảm. Và khi sự cố được giải quyết, chúng tôi bắt đầu dành 20 mili giây cho một yêu cầu, 10 mili giây cho một mã. Điều này có nghĩa là chúng tôi vẫn giảm năng suất gấp rưỡi. Và tất cả chỉ vì một giao dịch bị đóng băng, có lẽ là do lỗi của chúng tôi.
- Và câu hỏi: “Làm thế nào chúng ta có thể lấy lại mọi thứ?” để mọi thứ với chúng ta đều ổn và các yêu cầu được gửi đến nhanh chóng như trước khi xảy ra tai nạn.
Vì mục đích này, có một chu trình công việc nhất định được thực hiện.
Đầu tiên chúng ta cần tìm những bảng có vấn đề bị cồng kềnh. Chúng tôi hiểu rằng ở một số bảng, bản ghi hoạt động tích cực hơn, ở những bảng khác thì hoạt động kém hơn. Và để làm điều này, chúng tôi sử dụng phần mở rộng . Bằng cách cài đặt tiện ích mở rộng này, bạn có thể viết các truy vấn giúp bạn tìm các bảng khá cồng kềnh.
Khi bạn đã tìm thấy các bảng này, bạn cần nén chúng. Hiện đã có công cụ cho việc này. Trong công ty của chúng tôi, chúng tôi sử dụng ba công cụ. Đầu tiên là VACUUM FULL được tích hợp sẵn. Anh ta tàn nhẫn, khắc nghiệt và tàn nhẫn, nhưng đôi khi anh ta rất hữu ích. и - Đây là những tiện ích của bên thứ ba để nén bảng. Và họ xử lý cơ sở dữ liệu cẩn thận hơn.
Chúng được sử dụng tùy thuộc vào những gì thuận tiện hơn cho bạn. Nhưng tôi sẽ nói với bạn về điều này vào cuối. Điều chính là có ba công cụ. Có rất nhiều để lựa chọn.
Sau khi đã sửa chữa mọi thứ và đảm bảo rằng mọi thứ đều ổn, chúng ta phải biết cách ngăn chặn tình trạng này trong tương lai:
- Nó có thể được ngăn chặn khá dễ dàng. Bạn cần theo dõi thời lượng của các phiên trên máy chủ Master. Các phiên đặc biệt nguy hiểm khi không hoạt động ở trạng thái giao dịch. Đây là những người vừa mở giao dịch, làm gì đó rồi bỏ đi, hoặc đơn giản là treo máy, nhập nhầm mã.
- Và đối với bạn, với tư cách là nhà phát triển, điều quan trọng là phải kiểm tra mã của mình khi những tình huống này phát sinh. Nó không khó để làm. Đây sẽ là một kiểm tra hữu ích. Bạn sẽ tránh được rất nhiều vấn đề “trẻ con” liên quan đến các giao dịch kéo dài.
Trong các biểu đồ này, tôi muốn cho bạn thấy dấu hiệu và hành vi của cơ sở dữ liệu đã thay đổi như thế nào sau khi tôi xem qua dấu hiệu VACUUM FULL trong trường hợp này. Đây không phải là sản xuất cho tôi.
Kích thước bảng ngay lập tức trở lại trạng thái hoạt động bình thường ở mức vài megabyte. Điều này không ảnh hưởng nhiều đến thời gian phản hồi trung bình của máy chủ.
Nhưng đặc biệt đối với dấu hiệu thử nghiệm của chúng tôi, nơi chúng tôi cập nhật số dư tài khoản, chúng tôi thấy rằng thời gian phản hồi trung bình cho yêu cầu cập nhật dữ liệu trong dấu hiệu đã giảm xuống mức trước khi khẩn cấp. Tài nguyên mà bộ xử lý tiêu thụ để hoàn thành yêu cầu này cũng giảm xuống mức trước sự cố. Và biểu đồ phía dưới bên phải cho thấy rằng bây giờ chúng ta tìm thấy chính xác dòng mà chúng ta cần ngay lập tức mà không cần phải đi qua hàng đống dòng chết đã có trước khi bảng được nén. Và thời gian yêu cầu trung bình vẫn ở mức tương đương. Nhưng đúng hơn là ở đây tôi gặp phải một lỗi trong phần cứng của mình.
Đây là nơi câu chuyện đầu tiên kết thúc. Nó là phổ biến nhất. Và điều đó xảy ra với tất cả mọi người, bất kể kinh nghiệm của khách hàng và trình độ của các lập trình viên như thế nào. Sớm hay muộn điều này cũng xảy ra.
Câu chuyện thứ hai, trong đó chúng tôi phân phối tải và tối ưu hóa tài nguyên máy chủ
- Chúng tôi đã trưởng thành và trở thành những chàng trai nghiêm túc. Và chúng tôi hiểu rằng chúng tôi có một bản sao và sẽ rất tốt nếu chúng tôi cân bằng tải: viết thư cho Master và đọc từ bản sao. Và thông thường tình huống này phát sinh khi chúng ta muốn chuẩn bị một số báo cáo hoặc ETL. Và doanh nghiệp rất vui mừng về điều này. Anh ấy thực sự muốn có nhiều loại báo cáo với nhiều phân tích phức tạp.
- Báo cáo mất nhiều giờ vì các phân tích phức tạp không thể được tính bằng mili giây. Chúng tôi, giống như những người dũng cảm, viết mã. Trong ứng dụng chèn, chúng tôi tạo bản ghi trên Bản gốc và thực hiện các báo cáo trên bản sao.
- Phân phối tải.
- Mọi thứ hoạt động hoàn hảo. Rất lớn.
Và tình trạng này trông như thế nào? Cụ thể trên các biểu đồ này, tôi cũng đã thêm thời lượng giao dịch từ bản sao cho thời lượng giao dịch. Tất cả các biểu đồ khác chỉ đề cập đến máy chủ Master.
Đến thời điểm này, bảng báo cáo của tôi đã phát triển. Có nhiều hơn trong số họ. Chúng tôi thấy rằng thời gian phản hồi trung bình của máy chủ ổn định. Chúng tôi thấy rằng trên bản sao, chúng tôi có một giao dịch kéo dài trong 2 giờ. Chúng tôi thấy hoạt động yên tĩnh của máy hút bụi tự động, xử lý các dòng thời gian chết. Và mọi thứ đều ổn với chúng tôi.
Cụ thể theo tấm đã kiểm tra, chúng tôi tiếp tục cập nhật số dư tài khoản tại đó. Và chúng tôi cũng có thời gian phản hồi ổn định cho các yêu cầu, mức tiêu thụ tài nguyên ổn định. Mọi thứ đều ổn với chúng tôi.
Mọi thứ đều ổn cho đến thời điểm các báo cáo này bắt đầu phản hồi do xung đột với quá trình sao chép. Và họ bắn trả đều đặn.
Chúng tôi lên mạng và bắt đầu đọc lý do tại sao điều này lại xảy ra. Và chúng tôi tìm thấy một giải pháp.
Giải pháp đầu tiên là tăng độ trễ sao chép. Chúng tôi biết rằng báo cáo của chúng tôi chạy trong 3 giờ. Chúng tôi đặt độ trễ sao chép thành 3 giờ. Chúng tôi đang triển khai mọi thứ nhưng vẫn tiếp tục gặp sự cố với các báo cáo đôi khi bị hủy.
Chúng tôi muốn mọi thứ phải hoàn hảo. Chúng tôi leo xa hơn. Và chúng tôi đã tìm thấy một cài đặt thú vị trên Internet - hot_standby_feedback. Hãy bật nó lên. Hot_standby_feedback cho phép chúng tôi giữ lại chế độ tự động hút chân không trên Master. Như vậy, chúng ta hoàn toàn loại bỏ được xung đột về sao chép. Và mọi thứ đều hoạt động tốt với chúng tôi với các báo cáo.
Và chuyện gì đang xảy ra với máy chủ Master vào lúc này? Và chúng tôi đang gặp rắc rối hoàn toàn với máy chủ Master. Bây giờ chúng ta đang nhìn thấy các biểu đồ khi tôi bật cả hai cài đặt này. Và chúng tôi thấy rằng phiên trên bản sao của chúng tôi bằng cách nào đó đã bắt đầu ảnh hưởng đến tình hình trên máy chủ Master. Cô ấy thực sự có tác dụng vì cô ấy đã tạm dừng quá trình tự động hút bụi, thao tác này sẽ xóa bỏ các ranh giới chết. Kích thước bàn của chúng tôi lại tăng vọt. Thời gian thực hiện truy vấn trung bình trên toàn bộ cơ sở dữ liệu cũng tăng vọt. Máy hút chân không tự động thắt chặt lại một chút.
Cụ thể, từ đĩa của chúng tôi, chúng tôi thấy rằng bản cập nhật dữ liệu trên đó cũng tăng vọt. Mức tiêu thụ CPU cũng tăng lên rất nhiều. Một lần nữa chúng ta lại phải trải qua một số lượng lớn các đường chết, vô dụng. Và thời gian phản hồi cho dấu hiệu này cũng như số lượng giao dịch đã giảm xuống.
Mọi chuyện sẽ như thế nào nếu chúng ta không biết tôi đã nói về điều gì trước đây?
- Chúng tôi bắt đầu tìm kiếm vấn đề. Nếu chúng tôi gặp vấn đề ở phần đầu tiên, chúng tôi biết rằng điều này có thể là do giao dịch kéo dài và tìm đến Master. Chúng ta có vấn đề với Master. Xúc xích anh ấy. Nó nóng lên, Tải trung bình của nó là khoảng một trăm.
- Yêu cầu ở đó rất chậm nhưng chúng tôi không thấy bất kỳ giao dịch nào kéo dài ở đó. Và chúng tôi không hiểu vấn đề là gì. Chúng tôi không hiểu phải tìm ở đâu.
- Chúng tôi kiểm tra thiết bị máy chủ. Có lẽ cuộc đột kích của chúng tôi đã thất bại. Có thể thẻ nhớ của chúng ta đã bị cháy. Vâng, bất cứ điều gì có thể xảy ra. Nhưng không, máy chủ còn mới, mọi thứ đều hoạt động tốt.
- Mọi người đều đang chạy: quản trị viên, nhà phát triển và giám đốc. Không có gì giúp được.
- Và đến một lúc nào đó mọi thứ đột nhiên bắt đầu tự điều chỉnh.
Tại thời điểm này, yêu cầu trên bản sao của chúng tôi đã được xử lý và để lại. Chúng tôi đã nhận được báo cáo. Làm ăn vẫn vui vẻ. Như bạn có thể thấy, dấu hiệu của chúng tôi đã phát triển trở lại và sẽ không co lại. Trên biểu đồ có các phiên, tôi để lại một phần của giao dịch dài này từ một bản sao để bạn có thể ước tính khoảng thời gian cần thiết cho đến khi tình hình ổn định.
Phiên kết thúc. Và chỉ sau một thời gian, máy chủ ít nhiều có trật tự. Và thời gian phản hồi trung bình cho các yêu cầu trên máy chủ Master trở lại bình thường. Bởi vì cuối cùng, máy hút bụi tự động cũng có cơ hội dọn sạch và đánh dấu những đường chết này. Và anh bắt đầu làm công việc của mình. Và anh ấy làm điều đó nhanh như thế nào thì chúng ta sẽ sắp xếp trật tự nhanh như vậy.
Theo máy tính bảng được thử nghiệm, nơi chúng tôi cập nhật số dư tài khoản, chúng tôi thấy hình ảnh giống hệt nhau. Thời gian cập nhật tài khoản trung bình cũng đang dần bình thường hóa. Các tài nguyên mà bộ xử lý tiêu thụ cũng giảm. Và số lượng giao dịch mỗi giây trở lại bình thường. Nhưng một lần nữa chúng ta lại trở lại bình thường, không giống như trước khi xảy ra tai nạn.
Trong mọi trường hợp, chúng tôi nhận được sự giảm hiệu suất, như trong trường hợp đầu tiên, từ một đến rưỡi đến hai lần, và đôi khi nhiều hơn.
Có vẻ như chúng tôi đã làm đúng mọi việc. Phân phối tải. Thiết bị không ở trạng thái nhàn rỗi. Chúng tôi đã phân chia các yêu cầu theo suy nghĩ của mình, nhưng mọi thứ vẫn diễn ra tồi tệ.
- Không bật hot_standby_feedback? Có, không nên bật nó mà không có lý do đặc biệt chính đáng. Bởi vì sự thay đổi này ảnh hưởng trực tiếp đến máy chủ Master và làm đình chỉ hoạt động của autovacuum ở đó. Bằng cách kích hoạt nó trên một số bản sao và quên nó đi, bạn có thể giết chết Master và gặp những vấn đề lớn với ứng dụng.
- Tăng max_standby_streaming_delay? Vâng, đối với các báo cáo thì điều này là đúng. Nếu bạn có một báo cáo kéo dài ba giờ và bạn không muốn nó bị hỏng do xung đột sao chép, thì bạn chỉ cần tăng độ trễ. Báo cáo dài hạn không bao giờ yêu cầu dữ liệu đã có trong cơ sở dữ liệu ngay bây giờ. Nếu bạn có nó trong ba giờ, thì bạn đang chạy nó trong một khoảng thời gian dữ liệu cũ. Và đối với bạn, dù có sự chậm trễ ba giờ hay chậm trễ sáu giờ sẽ không tạo ra bất kỳ sự khác biệt nào, nhưng bạn sẽ nhận được báo cáo một cách nhất quán và sẽ không gặp vấn đề gì với việc chúng bị giảm.
- Đương nhiên, bạn cần kiểm soát các phiên dài trên bản sao, đặc biệt nếu bạn quyết định bật hot_standby_feedback trên bản sao. Bởi vì bất cứ điều gì có thể xảy ra. Chúng tôi đã đưa bản sao này cho nhà phát triển để anh ấy có thể kiểm tra các yêu cầu. Anh ấy đã viết một yêu cầu điên rồ. Anh ấy phóng nó và đi uống trà, và chúng tôi đã gặp được Master đã thành lập. Hoặc có thể chúng ta đã đặt sai ứng dụng vào đó. Các tình huống rất đa dạng. Các phiên trên bản sao phải được theo dõi cẩn thận như trên Master.
- Và nếu bạn có các truy vấn nhanh và dài về các bản sao thì trong trường hợp này tốt hơn là nên chia chúng ra để phân bổ tải. Đây là liên kết đến streaming_delay. Đối với những bản sao nhanh, hãy có một bản sao với độ trễ sao chép nhỏ. Đối với các yêu cầu báo cáo kéo dài, hãy có một bản sao có thể bị trễ 6 giờ hoặc một ngày. Đây là một tình huống hoàn toàn bình thường.
Chúng tôi loại bỏ hậu quả theo cách tương tự:
- Chúng tôi tìm thấy những cái bàn cồng kềnh.
- Và chúng tôi nén nó bằng công cụ thuận tiện nhất phù hợp với chúng tôi.
Câu chuyện thứ hai kết thúc ở đây. Hãy chuyển sang câu chuyện thứ ba.
Cũng khá phổ biến đối với chúng tôi khi chúng tôi thực hiện di chuyển.
- Bất kỳ sản phẩm phần mềm nào cũng đang phát triển. Các yêu cầu cho nó đang thay đổi. Trong mọi trường hợp, chúng tôi muốn phát triển. Và điều đó xảy ra là chúng tôi cần cập nhật dữ liệu trong bảng, cụ thể là chạy bản cập nhật về quá trình di chuyển của chúng tôi cho chức năng mới mà chúng tôi đang giới thiệu như một phần trong quá trình phát triển của mình.
- Định dạng dữ liệu cũ không thỏa đáng. Giả sử bây giờ chúng ta chuyển sang bảng thứ hai, nơi tôi thực hiện các giao dịch trên các tài khoản này. Và giả sử chúng được tính bằng đồng rúp, và chúng tôi quyết định tăng độ chính xác và thực hiện bằng đồng kopecks. Và để làm được điều này, chúng ta cần thực hiện cập nhật: nhân trường có số tiền giao dịch với một trăm.
- Trong thế giới ngày nay, chúng ta sử dụng các công cụ kiểm soát phiên bản cơ sở dữ liệu tự động. Hãy cùng nói nào . Chúng tôi đăng ký di chuyển của chúng tôi ở đó. Chúng tôi thử nghiệm nó trên cơ sở thử nghiệm của chúng tôi. Mọi thứ đều ổn. Quá trình cập nhật đang được thực hiện. Nó chặn hoạt động trong một thời gian, nhưng chúng tôi nhận được dữ liệu cập nhật. Và chúng tôi có thể khởi chạy chức năng mới về điều này. Mọi thứ đã được thử nghiệm và kiểm tra. Mọi thứ đã được xác nhận.
- Chúng tôi đã thực hiện công việc theo kế hoạch và tiến hành di chuyển.
Đây là quá trình di chuyển với bản cập nhật được trình bày trước mặt bạn. Vì đây là những giao dịch tài khoản của tôi nên đĩa có dung lượng 15 GB. Và vì chúng tôi cập nhật từng dòng nên chúng tôi đã tăng gấp đôi kích thước của bảng sau khi cập nhật vì chúng tôi viết lại từng dòng.
Trong quá trình di chuyển, chúng tôi không thể làm bất cứ điều gì với tấm này vì tất cả các yêu cầu đối với nó đều được xếp hàng đợi và đợi cho đến khi bản cập nhật này hoàn tất. Nhưng ở đây tôi muốn bạn chú ý đến những con số nằm trên trục tung. Nghĩa là, chúng ta có thời gian yêu cầu trung bình trước khi di chuyển là khoảng 5 mili giây và tải bộ xử lý, số thao tác khối để đọc bộ nhớ đĩa nhỏ hơn 7,5.
Chúng tôi đã tiến hành di chuyển và lại gặp sự cố.
Quá trình di chuyển đã thành công, nhưng:
- Chức năng cũ bây giờ mất nhiều thời gian hơn để hoàn thành.
- Chiếc bàn lại tăng kích thước.
- Tải trên máy chủ lại trở nên lớn hơn trước.
- Và tất nhiên, chúng tôi vẫn đang mày mò tìm kiếm chức năng hoạt động tốt, chúng tôi đã cải thiện nó một chút.
Và đây lại là chứng đầy hơi, một lần nữa hủy hoại cuộc sống của chúng ta.
Ở đây tôi chứng minh rằng bảng, giống như hai trường hợp trước, sẽ không trở về kích thước trước đó. Tải máy chủ trung bình có vẻ là đủ.
Và nếu lật sang bảng có tài khoản, chúng ta sẽ thấy thời gian yêu cầu trung bình đối với bảng này đã tăng gấp đôi. Tải trên bộ xử lý và số dòng được sắp xếp trong bộ nhớ đã tăng lên trên 7,5 nhưng thấp hơn. Và nó đã tăng 2 lần trong trường hợp bộ xử lý, 1,5 lần trong trường hợp hoạt động khối, tức là chúng tôi bị suy giảm hiệu suất máy chủ. Và kết quả là - hiệu suất ứng dụng của chúng tôi bị suy giảm. Đồng thời, số lượng cuộc gọi vẫn ở mức tương tự.
Và điều chính ở đây là hiểu cách thực hiện việc di chuyển như vậy một cách chính xác. Và họ cần phải được thực hiện. Chúng tôi thực hiện việc di chuyển này khá nhất quán.
- Những cuộc di cư lớn như vậy không tự động diễn ra. Họ phải luôn trong tầm kiểm soát.
- Cần có sự giám sát của người có hiểu biết. Nếu bạn có DBA trong nhóm của mình thì hãy để DBA làm việc đó. Đó là công việc của anh ấy. Nếu không thì hãy để người có kinh nghiệm nhất, người biết cách làm việc với cơ sở dữ liệu làm việc đó.
- Lược đồ cơ sở dữ liệu mới, ngay cả khi chúng tôi cập nhật một cột, chúng tôi luôn chuẩn bị theo từng giai đoạn, tức là trước khi triển khai phiên bản mới của ứng dụng:
- Các trường mới được thêm vào trong đó chúng tôi sẽ ghi lại dữ liệu cập nhật.
- Chúng tôi chuyển dữ liệu từ trường cũ sang trường mới theo từng phần nhỏ. Tại sao chúng ta lại làm việc này? Thứ nhất, chúng tôi luôn kiểm soát quá trình của quá trình này. Chúng tôi biết rằng chúng tôi đã chuyển rất nhiều lô và chúng tôi còn rất nhiều lô.
- Và tác dụng tích cực thứ hai là giữa mỗi đợt như vậy chúng ta đóng giao dịch, mở một đợt mới, điều này cho phép máy hút chân không tự động hoạt động theo đĩa, đánh dấu các điểm chết để tái sử dụng.
- Đối với các dòng sẽ xuất hiện khi ứng dụng đang chạy (chúng tôi vẫn chạy ứng dụng cũ), chúng tôi thêm trình kích hoạt ghi giá trị mới vào các trường mới. Trong trường hợp của chúng tôi, đây là phép nhân với một trăm giá trị cũ.
- Nếu chúng tôi hoàn toàn kiên quyết và muốn có cùng một trường, thì sau khi hoàn thành tất cả quá trình di chuyển và trước khi tung ra phiên bản mới của ứng dụng, chúng tôi chỉ cần đổi tên các trường. Những cái cũ được đặt một số tên được phát minh, và những lĩnh vực mới được đổi tên thành những cái cũ.
- Và chỉ sau đó chúng tôi mới tung ra phiên bản mới của ứng dụng.
Đồng thời, chúng tôi sẽ không bị cồng kềnh và không bị ảnh hưởng về hiệu suất.
Đây là nơi câu chuyện thứ ba kết thúc.
Và bây giờ chi tiết hơn một chút về các công cụ mà tôi đã đề cập trong câu chuyện đầu tiên.
Trước khi tìm kiếm bloat, bạn phải cài đặt tiện ích mở rộng .
Để bạn không cần phải đưa ra các truy vấn, chúng tôi đã viết những truy vấn này trong công việc của mình. Bạn có thể sử dụng chúng. Có hai yêu cầu ở đây.
- Cách đầu tiên mất khá nhiều thời gian để hoạt động, nhưng nó sẽ hiển thị cho bạn các giá trị phình to chính xác từ bảng.
- Cách thứ hai có tác dụng nhanh hơn và rất hiệu quả khi bạn cần đánh giá nhanh xem có chướng bụng hay không theo bảng. Và bạn cũng nên hiểu rằng sự phình to luôn hiện diện trong bảng Postgres. Đây là một tính năng của mô hình MVCC của nó.
- Và độ phồng 20% là bình thường đối với các bảng trong hầu hết các trường hợp. Tức là bạn không nên lo lắng và nén bảng này.
Chúng tôi đã tìm ra cách xác định các bảng chứa đầy dữ liệu vô dụng.
Bây giờ về cách khắc phục tình trạng đầy hơi:
- Nếu chúng ta có một chiếc máy tính bảng nhỏ và ổ đĩa tốt, tức là trên một chiếc máy tính bảng có dung lượng lên tới gigabyte, thì hoàn toàn có thể sử dụng VACUUM FULL. Anh ta sẽ lấy một chiếc khóa độc quyền của bạn trên bàn trong vài giây và được thôi, nhưng anh ta sẽ làm mọi thứ một cách nhanh chóng và khắc nghiệt. VACUUM FULL làm gì? Nó lấy một khóa độc quyền trên bảng và viết lại các hàng trực tiếp từ các bảng cũ sang bảng mới. Và cuối cùng anh ấy thay thế chúng. Nó xóa các tập tin cũ và thay thế những tập tin cũ bằng những tập tin mới. Nhưng trong suốt thời gian làm việc, nó cần một chiếc khóa độc quyền trên bàn. Điều này có nghĩa là bạn không thể làm bất cứ điều gì với bảng này: không được ghi vào nó, cũng không được đọc vào nó, cũng không được sửa đổi nó. Và VACUUM FULL yêu cầu thêm dung lượng ổ đĩa để ghi dữ liệu.
- Công cụ tiếp theo . Về nguyên tắc, nó rất giống với VACUUM FULL, vì nó cũng ghi lại dữ liệu từ tệp cũ sang tệp mới và thay thế chúng trong bảng. Nhưng đồng thời, nó không có một khóa độc quyền trên bàn khi bắt đầu công việc mà chỉ sử dụng nó vào thời điểm nó đã có sẵn dữ liệu để thay thế các tệp. Yêu cầu về tài nguyên đĩa của nó tương tự như VACUUM FULL. Bạn cần thêm dung lượng ổ đĩa và điều này đôi khi rất quan trọng nếu bạn có bảng terabyte. Và nó khá ngốn bộ xử lý vì nó hoạt động tích cực với I/O.
- Tiện ích thứ ba là . Nó cẩn thận hơn với các nguồn tài nguyên vì nó hoạt động theo những nguyên tắc hơi khác một chút. Ý tưởng chính của pgcompacttable là nó di chuyển tất cả các hàng trực tiếp về đầu bảng bằng cách sử dụng các bản cập nhật trong bảng. Và sau đó nó chạy chân không trên bàn này, bởi vì chúng ta biết rằng chúng ta có hàng sống ở đầu và hàng chết ở cuối. Và chân không tự cắt đuôi này, tức là nó không cần thêm nhiều dung lượng ổ đĩa. Đồng thời, nó vẫn có thể bị siết chặt về nguồn lực.
Mọi thứ đều có công cụ.
Nếu bạn thấy chủ đề cồng kềnh này thú vị khi tìm hiểu sâu hơn bên trong thì đây là một số liên kết hữu ích:
- - Đây là báo cáo từ đồng nghiệp của tôi. Nó nói chung về nơi không gian của Postgres đi đến trong quá trình hoạt động và cuộc sống của nó. Và có một phần kỹ thuật rất lớn và chi tiết dành cho quản trị viên cơ sở dữ liệu về tình trạng phình to.
- – đây là liên kết đến kho lưu trữ của chúng tôi, nơi chúng tôi lưu trữ nhiều tập lệnh hữu ích để kiểm tra trạng thái của cơ sở dữ liệu. Ở đó bạn có thể tìm thấy các tập lệnh để tìm kiếm sự phình to.
- и liên kết đến các công cụ sẽ giúp bạn thu nhỏ các dấu hiệu.
- – đây là một bài viết từ đồng nghiệp của tôi. Ở đó anh ấy phân tích khá nghiêm túc và kỹ thuật về sự phình to một cách chi tiết ở mức độ gần với quản trị viên.
Tôi đã cố gắng nhiều hơn để thể hiện một câu chuyện kinh dị cho các nhà phát triển, bởi vì họ là khách hàng trực tiếp của cơ sở dữ liệu của chúng tôi và phải hiểu điều gì và hành động nào sẽ dẫn đến. Tôi hy vọng tôi đã thành công. Cám ơn vì sự quan tâm của bạn!
câu hỏi
Cảm ơn vì đã báo cáo! Bạn đã nói về cách bạn có thể xác định vấn đề. Làm thế nào họ có thể được cảnh báo? Đó là, tôi đã gặp phải tình huống các yêu cầu bị treo không chỉ vì chúng truy cập một số dịch vụ bên ngoài. Đây chỉ là một số sự tham gia hoang dã. Có một số yêu cầu nhỏ nhặt, vô hại kéo dài suốt một ngày và sau đó bắt đầu thực hiện một số điều vô nghĩa. Đó là, rất giống với những gì bạn mô tả. Làm thế nào để theo dõi điều này? Ngồi xem liên tục request nào bị kẹt? điều này có thể được ngăn ngừa bằng cách nào?
Trong trường hợp này, đây là nhiệm vụ dành cho quản trị viên của công ty bạn, không nhất thiết dành cho DBA.
Tôi là quản trị viên.
PostgreSQL có chế độ xem được gọi là pg_stat_activity hiển thị các truy vấn lơ lửng. Và bạn có thể thấy nó treo ở đó bao lâu.
Tôi có phải vào xem 5 phút một lần không?
Thiết lập cron và kiểm tra. Nếu bạn có một yêu cầu dài hạn, hãy viết một lá thư và thế là xong. Tức là bạn không cần phải nhìn bằng mắt mà có thể tự động hóa được. Bạn sẽ nhận được một lá thư, bạn phản ứng với nó. Hoặc bạn có thể chụp tự động.
Có bất kỳ lý do rõ ràng tại sao điều này xảy ra?
Tôi đã liệt kê một số. Các ví dụ phức tạp khác. Và có thể có một cuộc trò chuyện trong một thời gian dài.
Cảm ơn vì đã báo cáo! Tôi muốn làm rõ về tiện ích pg_repack. Nếu cô ấy không mở khóa độc quyền thì...
Cô ấy làm một khóa độc quyền.
... thì tôi có thể bị mất dữ liệu. Ứng dụng của tôi có nên ghi lại bất cứ điều gì trong thời gian này không?
Không, nó hoạt động trơn tru với bảng, tức là pg_repack trước tiên sẽ chuyển tất cả các dòng trực tiếp tồn tại. Đương nhiên, một số loại mục vào bảng xảy ra ở đó. Anh ấy vừa ném cái đuôi ngựa này ra.
Đó là, cuối cùng anh ấy thực sự làm điều đó?
Cuối cùng, anh ta lấy một khóa độc quyền để trao đổi các tập tin này.
Liệu nó có nhanh hơn VACUUM FULL không?
VACUUM FULL, ngay khi khởi động, ngay lập tức lấy một khóa độc quyền. Và cho đến khi anh làm được mọi việc, anh sẽ không để cô đi. Và pg_repack chỉ có một khóa độc quyền tại thời điểm thay thế tệp. Lúc này bạn sẽ không viết vào đó nhưng dữ liệu sẽ không bị mất, mọi thứ sẽ ổn.
Xin chào! Bạn đã nói về hoạt động của máy hút bụi ô tô. Có một biểu đồ với các ô ghi màu đỏ, vàng và xanh lục. Đó là những cái màu vàng - anh ấy đánh dấu chúng là đã xóa. Và kết quả là, một cái gì đó mới có thể được viết vào chúng?
Đúng. Postgres không xóa dòng. Anh ấy có một đặc điểm như vậy. Nếu chúng tôi cập nhật một dòng, chúng tôi sẽ đánh dấu dòng cũ là đã xóa. Id của giao dịch đã thay đổi dòng này xuất hiện ở đó và chúng tôi viết một dòng mới. Và chúng tôi có những phiên có khả năng đọc được chúng. Đến một lúc nào đó họ trở nên khá già. Và bản chất của cách thức hoạt động của máy hút bụi tự động là nó đi qua những dòng này và đánh dấu chúng là không cần thiết. Và bạn có thể ghi đè lên dữ liệu ở đó.
Tôi hiểu. Nhưng đó không phải là nội dung câu hỏi. Tôi chưa hoàn thành. Giả sử chúng ta có một cái bàn. Nó có các trường có kích thước thay đổi. Và nếu tôi cố gắng chèn một cái gì đó mới, nó có thể không vừa với ô cũ.
Không, trong mọi trường hợp, toàn bộ dòng được cập nhật ở đó. Postgres có hai mô hình lưu trữ dữ liệu. Nó chọn từ kiểu dữ liệu. Có dữ liệu được lưu trữ trực tiếp trong bảng và cũng có dữ liệu tos. Đây là lượng lớn dữ liệu: văn bản, json. Chúng được lưu trữ trong các tấm riêng biệt. Và theo những chiếc máy tính bảng này, câu chuyện tương tự về tình trạng đầy hơi cũng xảy ra, tức là mọi thứ đều giống nhau. Chúng chỉ được liệt kê riêng biệt.
Cảm ơn vì đã báo cáo! Có thể chấp nhận sử dụng truy vấn hết thời gian chờ của câu lệnh để giới hạn thời lượng không?
Rất chấp nhận được. Chúng tôi sử dụng điều này ở khắp mọi nơi. Và vì chúng tôi không có dịch vụ riêng nên chúng tôi cung cấp hỗ trợ từ xa nên chúng tôi có khá nhiều khách hàng. Và mọi người hoàn toàn hài lòng với điều này. Nghĩa là, chúng tôi có các công việc định kỳ để kiểm tra. Thời lượng của các buổi học chỉ được thỏa thuận đơn giản với khách hàng, trước đó chúng tôi không đồng ý. Có thể là một phút, có thể là 10 phút. Nó phụ thuộc vào tải trọng trên đế và mục đích của nó. Nhưng tất cả chúng ta đều sử dụng pg_stat_activity.
Cảm ơn vì đã báo cáo! Tôi đang cố gắng áp dụng báo cáo của bạn vào đơn đăng ký của tôi. Và có vẻ như chúng ta bắt đầu giao dịch ở mọi nơi và hoàn thành giao dịch đó một cách rõ ràng ở mọi nơi. Nếu có một số ngoại lệ thì việc khôi phục vẫn xảy ra. Và rồi tôi bắt đầu suy nghĩ. Rốt cuộc, giao dịch có thể không bắt đầu một cách rõ ràng. Đây có lẽ là một gợi ý cho cô gái. Nếu tôi chỉ cập nhật một bản ghi, giao dịch có bắt đầu trong PostgreSQL và chỉ hoàn tất khi kết nối bị ngắt không?
Nếu bây giờ bạn đang nói về cấp độ ứng dụng thì điều đó phụ thuộc vào trình điều khiển mà bạn đang sử dụng, vào ORM đang được sử dụng. Có rất nhiều cài đặt ở đó. Nếu bạn đã bật cam kết tự động thì giao dịch sẽ bắt đầu ở đó và đóng ngay lập tức.
Tức là nó đóng ngay sau khi cập nhật?
Nó phụ thuộc vào các cài đặt. Tôi đặt tên cho một cài đặt. Đây là tự động cam kết. Nó khá phổ biến. Nếu nó được kích hoạt thì giao dịch đã được mở và đóng. Trừ khi bạn nói rõ ràng là “bắt đầu giao dịch” và “kết thúc giao dịch”, mà chỉ đưa ra một yêu cầu vào phiên.
Xin chào! Cảm ơn vì đã báo cáo! Hãy tưởng tượng rằng chúng ta có một cơ sở dữ liệu ngày càng phình to và sau đó hết dung lượng trên máy chủ. Có công cụ nào để khắc phục tình trạng này không?
Không gian trên máy chủ cần được theo dõi đúng cách.
Ví dụ: DBA đi uống trà, ở khu nghỉ dưỡng, v.v.
Khi một hệ thống tập tin được tạo ra, ít nhất một loại không gian dự phòng nào đó sẽ được tạo ra ở nơi dữ liệu không được ghi.
Điều gì sẽ xảy ra nếu nó hoàn toàn dưới 0?
Ở đó, nó được gọi là không gian dành riêng, tức là nó có thể được giải phóng và tùy thuộc vào mức độ lớn của nó được tạo, bạn sẽ có được không gian trống. Theo mặc định tôi không biết có bao nhiêu. Và trong một trường hợp khác, hãy phân phối đĩa để bạn có chỗ thực hiện thao tác tái tạo. Bạn có thể xóa một số bảng mà bạn được đảm bảo là không cần thiết.
Có công cụ nào khác không?
Nó luôn được làm thủ công. Và tại địa phương, điều gì là tốt nhất nên làm ở đó trở nên rõ ràng, bởi vì một số dữ liệu là quan trọng và một số là không quan trọng. Và đối với mỗi cơ sở dữ liệu và ứng dụng hoạt động với nó, điều đó phụ thuộc vào hoạt động kinh doanh. Nó luôn được quyết định ở địa phương.
Cảm ơn vì đã báo cáo! Tôi có hai câu hỏi. Đầu tiên, bạn trình chiếu các trang trình bày cho thấy rằng khi giao dịch bị kẹt, cả kích thước vùng bảng và kích thước chỉ mục đều tăng lên. Và hơn nữa trong báo cáo còn có một loạt tiện ích đi kèm với máy tính bảng. Còn chỉ số thì sao?
Họ cũng đóng gói chúng.
Nhưng chân không không ảnh hưởng đến chỉ số?
Một số hoạt động với một chỉ mục. Ví dụ: pg_rapack, pgcompacttable. Chân không tạo lại các chỉ mục và ảnh hưởng đến chúng. Với VACUUM FULL, ý tưởng là ghi đè lên mọi thứ, tức là nó hoạt động với tất cả mọi người.
Và câu hỏi thứ hai. Tôi không hiểu tại sao các báo cáo về bản sao lại phụ thuộc nhiều vào chính bản sao đó. Đối với tôi, dường như các báo cáo được đọc và sao chép là viết.
Điều gì gây ra xung đột sao chép? Chúng ta có một Bậc thầy về những quá trình diễn ra. Chúng tôi đang tiến hành hút bụi ô tô. Máy hút bụi tự động thực sự làm được những gì? Anh ấy đang cắt bỏ một số dòng cũ. Nếu tại thời điểm này, chúng tôi có yêu cầu về bản sao đọc những dòng cũ này và trên Master xảy ra tình huống máy hút bụi tự động đánh dấu những dòng này là có thể để ghi đè, thì chúng tôi sẽ ghi đè chúng. Và chúng ta nhận được một gói dữ liệu, khi cần viết lại những dòng mà yêu cầu cần trên bản sao thì quá trình sao chép sẽ chờ khoảng thời gian chờ mà bạn đã cấu hình. Và sau đó PostgreSQL sẽ quyết định điều gì quan trọng hơn với nó. Và đối với anh ta, việc sao chép quan trọng hơn yêu cầu và anh ta sẽ thực hiện yêu cầu để thực hiện những thay đổi này trên bản sao.
Andrey, tôi có một câu hỏi. Những biểu đồ tuyệt vời mà bạn đã trình bày trong buổi thuyết trình, đây có phải là kết quả công việc của một loại tiện ích nào đó của bạn không? Các đồ thị được tạo ra như thế nào?
Đây là một dịch vụ .
Đây có phải là một sản phẩm thương mại?
Đúng. Đây là một sản phẩm thương mại.
Nguồn: www.habr.com