Đã đến lúc.
Khoảng một năm trước, chúng tôi đã xuất bản PostgreSQL 10 với hỗ trợ sao chép logic nguyên bản. Một trong những cách sử dụng của sao chép hợp lý là cho phép nâng cấp thời gian ngừng hoạt động thấp hoặc không có giữa các phiên bản chính của PostgreSQL. Cho đến nay, PostgreSQL 10 là bản phát hành PostgreSQL duy nhất có bản sao logic nguyên bản, vì vậy không có nhiều cơ hội để nâng cấp theo cách này. (Bản sao lôgic cũng có thể được sử dụng để di chuyển dữ liệu giữa các phiên bản trên các hệ điều hành hoặc kiến trúc CPU khác nhau hoặc với các cài đặt cấu hình cấp thấp khác nhau như kích thước khối hoặc ngôn ngữ - nếu bạn muốn.) Bây giờ PostgreSQL 11 đã gần đến, sẽ có thêm lý do để sử dụng chức năng này.
Đầu tiên chúng ta hãy so sánh ba cách chính để nâng cấp cài đặt PostgreSQL:
- pg_dump và khôi phục
- pg_upgrade
- sao chép hợp lý
Chúng ta có thể so sánh các phương pháp này về độ mạnh mẽ, tốc độ, thời gian ngừng hoạt động bắt buộc và các hạn chế (và hơn thế nữa, nhưng chúng ta phải dừng lại ở đâu đó cho bài viết này).
pg_dump và khôi phục được cho là phương pháp mạnh mẽ nhất vì nó là phương pháp được thử nghiệm nhiều nhất và đã được sử dụng trong nhiều thập kỷ. Nó cũng có rất ít hạn chế về những gì nó có thể xử lý. Có thể xây dựng cơ sở dữ liệu không thể kết xuất và khôi phục, chủ yếu liên quan đến các mối quan hệ phụ thuộc đối tượng cụ thể, nhưng những cơ sở này rất hiếm và thường liên quan đến các phương pháp không được khuyến khích.
Tất nhiên, vấn đề với phương pháp kết xuất và khôi phục là nó đòi hỏi thời gian chết trong toàn bộ thời gian chạy các hoạt động kết xuất và khôi phục. Mặc dù cơ sở dữ liệu nguồn vẫn có thể đọc và ghi được trong khi quá trình chạy, bất kỳ cập nhật nào đối với cơ sở dữ liệu nguồn sau khi bắt đầu kết xuất sẽ bị mất.
pg_upgrade cải thiện quy trình pg_dump bằng cách di chuyển trực tiếp các tệp dữ liệu mà không cần phải kết xuất chúng thành dạng văn bản logic. Lưu ý rằng pg_upgrade vẫn sử dụng pg_dump bên trong để sao chép lược đồ, nhưng không sử dụng dữ liệu. Khi pg_upgrade còn mới, tính mạnh mẽ của nó đã bị đặt câu hỏi và nó đã nâng cấp một số cơ sở dữ liệu không chính xác. Nhưng pg_upgrade hiện đã khá trưởng thành và được thử nghiệm tốt, vì vậy người ta không cần phải ngần ngại về việc sử dụng nó vì lý do đó nữa. Trong khi pg_upgrade chạy, hệ thống cơ sở dữ liệu không hoạt động. Nhưng người ta có thể lựa chọn pg_upgrade chạy trong bao lâu. Trong chế độ sao chép mặc định, tổng thời gian chạy bao gồm thời gian để kết xuất và khôi phục giản đồ (thường rất nhanh, trừ khi một có hàng nghìn bảng hoặc các đối tượng khác) cộng với thời gian sao chép các tệp dữ liệu, điều này phụ thuộc vào cơ sở dữ liệu lớn như thế nào (và hệ thống I / O, hệ thống tệp, v.v.).
Trong chế độ liên kết tùy chọn, các tệp dữ liệu thay vào đó được liên kết cứng với thư mục dữ liệu mới, do đó thời gian chỉ đơn thuần là thời gian để thực hiện một thao tác nhân ngắn trên mỗi tệp thay vì sao chép từng byte. Hạn chế là nếu có bất kỳ vấn đề gì xảy ra với quá trình nâng cấp hoặc bạn cần quay lại cài đặt cũ, thì thao tác này sẽ phá hủy cơ sở dữ liệu cũ của bạn. (Tôi đang làm việc trên một giải pháp tốt nhất của cả hai thế giới cho PostgreSQL 12 bằng cách sử dụng các liên kết lại hoặc hoạt động sao chép tệp trên các hệ thống tệp được hỗ trợ.)
Bản sao lôgic là tính năng mới nhất trong số các bản sao ở đây, vì vậy có thể sẽ mất một thời gian để tìm ra các điểm gấp khúc. Nếu bạn không có thời gian để khám phá và điều tra, đây có thể không phải là cách để thực hiện ngay bây giờ. (Tất nhiên, mọi người đã sử dụng các giải pháp sao chép logic không phải cốt lõi khác như Slony, Londiste và pglogical để nâng cấp PostgreSQL trong nhiều năm, vì vậy có rất nhiều kinh nghiệm về các nguyên tắc, nếu không phải là các chi tiết cụ thể.)
Ưu điểm của việc sử dụng bản sao hợp lý để nâng cấp là ứng dụng có thể tiếp tục chạy so với phiên bản cũ trong khi quá trình đồng bộ hóa dữ liệu diễn ra. Chỉ cần có một sự cố nhỏ trong khi các kết nối máy khách được chuyển sang. Vì vậy, mặc dù quá trình nâng cấp bằng cách sử dụng sao chép hợp lý có thể bắt đầu chậm hơn so với việc sử dụng pg_upgrade ở chế độ sao chép (và chắc chắn chậm hơn so với sử dụng chế độ liên kết cứng), điều đó không quan trọng lắm vì thời gian ngừng hoạt động thực tế có thể ngắn hơn nhiều.
Lưu ý rằng sao chép hợp lý hiện không sao chép các thay đổi giản đồ. Trong quy trình nâng cấp được đề xuất này, lược đồ vẫn được sao chép qua pg_dump, nhưng các thay đổi lược đồ tiếp theo sẽ không được chuyển sang. Nâng cấp bằng cách nhân bản hợp lý cũng có một vài hạn chế khác. Một số hoạt động không bị sao chép lôgic nắm bắt:các đối tượng lớn, TRUNCATE, thay đổi trình tự. Chúng ta sẽ thảo luận về các giải pháp thay thế cho những vấn đề này sau.
Nếu bạn có bất kỳ lỗi vật lý nào (và nếu không, tại sao bạn lại không?), Thì cũng có một số khác biệt cần xem xét giữa các phương pháp. Với một trong hai phương pháp, bạn cần phải xây dựng các standby vật lý mới cho phiên bản được nâng cấp. Với kết xuất và khôi phục cũng như với sao chép hợp lý, chúng có thể được đặt trước khi bắt đầu nâng cấp để chế độ chờ sẽ gần như sẵn sàng sau khi quá trình đồng bộ ban đầu khôi phục hoặc sao chép hợp lý hoàn tất, tùy thuộc vào độ trễ sao chép.
Với pg_upgrade, các standby mới phải được tạo sau khi quá trình nâng cấp của chính hoàn tất. (Tài liệu pg_upgrade mô tả chi tiết hơn về điều này.) Nếu bạn dựa vào các chân đế vật lý để có tính khả dụng cao, thì các chân đế phải được đặt ở vị trí trước khi bạn chuyển sang phiên bản mới, vì vậy việc thiết lập các chân đế có thể ảnh hưởng đến tính toán thời gian tổng thể của bạn.
Nhưng quay lại sao chép hợp lý. Đây là cách có thể thực hiện việc nâng cấp với bản sao hợp lý:
0. Phiên bản cũ phải được chuẩn bị để sao chép hợp lý. Điều này yêu cầu một số cài đặt cấu hình như được mô tả trong http://www.postgresql.org/docs/10/static/logical-replication-config.html (chủ yếu là wal_level = logical . Nếu hóa ra bạn cần thực hiện những thay đổi đó, chúng sẽ yêu cầu khởi động lại máy chủ. Vì vậy, hãy kiểm tra kỹ điều này trước thời hạn. Cũng kiểm tra xem pg_hba.conf trên phiên bản cũ được thiết lập để chấp nhận các kết nối từ phiên bản mới. (Thay đổi điều đó chỉ yêu cầu tải lại.)
1. Cài đặt phiên bản PostgreSQL mới. Bạn cần ít nhất gói máy chủ và gói máy khách có chứa pg_dump. Nhiều packagings hiện nay cho phép cài đặt nhiều phiên bản song song với nhau. Nếu bạn đang chạy các máy ảo hoặc phiên bản đám mây, bạn nên cân nhắc cài đặt phiên bản mới trên máy chủ mới.
2. Thiết lập một phiên bản mới, tức là, chạy initdb. Phiên bản mới có thể có các cài đặt khác với phiên bản cũ, chẳng hạn như ngôn ngữ, kích thước phân đoạn WAL hoặc tổng kiểm tra. (Tại sao không sử dụng cơ hội này để bật tổng kiểm tra dữ liệu?)
3. Trước khi bắt đầu phiên bản mới, bạn có thể cần thay đổi một số cài đặt cấu hình. Nếu phiên bản chạy trên cùng một máy chủ với phiên bản cũ, bạn cần đặt một số cổng khác. Ngoài ra, hãy thực hiện bất kỳ thay đổi tùy chỉnh nào bạn đã thực hiện trong postgresql.conf trên phiên bản cũ của bạn, chẳng hạn như cài đặt bộ nhớ, max_connections , v.v. Tương tự, hãy tạo pg_hba.conf cài đặt phù hợp với môi trường của bạn. Bạn thường có thể bắt đầu bằng cách sao chép qua pg_hba.conf tệp từ phiên bản cũ. Nếu bạn muốn sử dụng SSL, hãy thiết lập ngay bây giờ.
4. Khởi động phiên bản mới (trống) và kiểm tra xem nó có hoạt động với bạn không. Nếu bạn thiết lập phiên bản mới trên máy chủ mới, hãy kiểm tra tại thời điểm này để đảm bảo rằng bạn có thể tạo kết nối cơ sở dữ liệu (sử dụng psql) từ máy chủ mới đến phiên bản cơ sở dữ liệu cũ. Chúng tôi sẽ cần điều đó trong các bước tiếp theo.
5. Sao chép các định nghĩa lược đồ với pg_dumpall. (Hoặc bạn có thể làm điều đó với pg_dump cho từng cơ sở dữ liệu riêng biệt, nhưng đừng quên các đối tượng toàn cục như vai trò.)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Bất kỳ thay đổi lược đồ nào sau thời điểm này sẽ không được di chuyển. Bạn sẽ phải tự quản lý chúng. Trong nhiều trường hợp, bạn chỉ có thể áp dụng DDL thay đổi trên cả hai máy chủ, nhưng chạy các lệnh thay đổi cấu trúc bảng trong quá trình nâng cấp có lẽ là một thách thức quá xa.
6. Trong mỗi cơ sở dữ liệu trong phiên bản nguồn, hãy tạo một ấn phẩm chứa tất cả các bảng:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Bản sao lôgic hoạt động riêng biệt trong mỗi cơ sở dữ liệu, vì vậy điều này cần được lặp lại trong mỗi cơ sở dữ liệu. Mặt khác, bạn không phải nâng cấp tất cả cơ sở dữ liệu cùng một lúc, vì vậy bạn có thể thực hiện việc này từng cơ sở dữ liệu một hoặc thậm chí không cần nâng cấp một số cơ sở dữ liệu.
7. Trong mỗi cơ sở dữ liệu trong cá thể đích, hãy tạo một gói đăng ký cho ấn phẩm vừa tạo. Đảm bảo khớp chính xác cơ sở dữ liệu nguồn và cơ sở dữ liệu đích.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Đặt các thông số kết nối sao cho phù hợp.
8. Bây giờ bạn đợi cho đến khi các đăng ký đã sao chép qua dữ liệu ban đầu và đã bắt kịp hoàn toàn với nhà xuất bản. Bạn có thể kiểm tra trạng thái đồng bộ ban đầu của mỗi bảng trong một đăng ký trong danh mục hệ thống pg_subscription_rel (tìm r =sẵn sàng trong cột srsubstate ). Trạng thái tổng thể của bản sao có thể được kiểm tra trong pg_stat_replication ở phía gửi và pg_stat_subscription về phía nhận.
9. Như đã đề cập ở trên, các thay đổi trình tự không được sao chép. Một giải pháp khả thi cho điều này là sao chép các giá trị trình tự bằng cách sử dụng pg_dump. Bạn có thể lấy kết xuất các giá trị trình tự hiện tại bằng cách sử dụng một cái gì đó như sau:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(Điều này giả định rằng tất cả các tên trình tự đều khớp với *_seq và không có bảng nào phù hợp với tên đó. Trong những trường hợp phức tạp hơn, bạn cũng có thể thực hiện lộ trình tạo toàn bộ kết xuất và tách dữ liệu trình tự khỏi mục lục của kết xuất.)
Vì các trình tự có thể tăng lên khi bạn làm điều này, có lẽ nên trộn seq-data.sql tập tin để thêm một chút chùng vào các con số.
Sau đó, khôi phục tệp đó vào cơ sở dữ liệu mới bằng psql.
10. Thời gian chiếu:Chuyển các ứng dụng sang phiên bản mới. Điều này đòi hỏi một số suy nghĩ trước thời gian. Trong trường hợp đơn giản nhất, bạn dừng các chương trình ứng dụng của mình, thay đổi cài đặt kết nối, khởi động lại. Nếu bạn sử dụng proxy kết nối, bạn có thể chuyển đổi kết nối ở đó. Bạn cũng có thể chuyển đổi từng ứng dụng khách một, có lẽ để kiểm tra mọi thứ một chút hoặc giảm tải cho hệ thống mới. Điều này sẽ hoạt động miễn là các ứng dụng vẫn trỏ đến máy chủ cũ và những ứng dụng trỏ đến máy chủ mới không tạo ra các ghi xung đột. (Trong trường hợp đó, bạn sẽ chạy một hệ thống đa quản trị viên, ít nhất là trong một thời gian ngắn, và đó là một thứ tự phức tạp khác.)
11. Khi nâng cấp hoàn tất, bạn có thể hủy thiết lập nhân rộng. Trong mỗi cơ sở dữ liệu trên phiên bản mới, hãy chạy
DROP SUBSCRIPTION s_upgrade;
Nếu bạn đã tắt phiên bản cũ, điều này sẽ không thành công vì nó sẽ không thể kết nối với máy chủ từ xa để loại bỏ vị trí sao chép. Xem trang người đàn ông DROP SUBSCRIPTION để biết cách tiếp tục trong tình huống này.
Bạn cũng có thể loại bỏ các ấn phẩm trên phiên bản nguồn, nhưng điều đó là không cần thiết vì một ấn phẩm không giữ lại bất kỳ tài nguyên nào.
12. Cuối cùng, xóa các phiên bản cũ nếu bạn không cần chúng nữa.
Một số nhận xét bổ sung về cách giải quyết cho những thứ mà bản sao lôgic không hỗ trợ. Nếu bạn đang sử dụng các đối tượng lớn, bạn có thể di chuyển chúng bằng cách sử dụng pg_dump, tất nhiên, miễn là chúng không thay đổi trong quá trình nâng cấp. Đây là một hạn chế đáng kể, vì vậy nếu bạn là người sử dụng nhiều các vật thể lớn, thì phương pháp này có thể không dành cho bạn. Nếu ứng dụng của bạn gặp sự cố TRUNCATE trong quá trình nâng cấp, những hành động đó sẽ không được lặp lại. Có lẽ bạn có thể chỉnh sửa ứng dụng của mình để ngăn ứng dụng làm điều đó trong thời gian nâng cấp hoặc thay vào đó bạn có thể thay thế một DELETE. PostgreSQL 11 sẽ hỗ trợ sao chép TRUNCATE, nhưng điều đó sẽ chỉ hoạt động nếu cả phiên bản nguồn và đích đều là PostgreSQL 11 hoặc mới hơn.
Một số nhận xét kết thúc thực sự áp dụng cho tất cả các cam kết nâng cấp:
- Các ứng dụng và tất cả các chương trình máy khách cơ sở dữ liệu phải được kiểm tra dựa trên phiên bản PostgreSQL chính mới trước khi đưa vào sản xuất.
- Vì vậy, bạn cũng nên kiểm tra quy trình nâng cấp trước khi thực hiện trong môi trường sản xuất.
- Viết mọi thứ ra giấy hoặc tập lệnh tốt hơn và tự động hóa nhiều nhất có thể.
- Đảm bảo thiết lập sao lưu, hệ thống giám sát và mọi công cụ bảo trì và tập lệnh được điều chỉnh thích hợp trong quá trình nâng cấp. Tốt nhất, những điều này phải có sẵn và được xác minh trước khi thực hiện chuyển đổi.
Với ý nghĩ đó, chúc bạn may mắn và hãy chia sẻ kinh nghiệm của bạn.
