Trong vài tháng trước, tôi đã làm việc để nâng cấp trực tuyến cho các cơ sở dữ liệu rất lớn như một phần của dự án AXLE và tôi muốn chia sẻ suy nghĩ của mình về chủ đề này và những tiến bộ mà chúng tôi đã đạt được gần đây.
Trước khi tham gia 2ndQuadrant, tôi đã từng làm việc trong Skype nơi doanh nghiệp không cho phép mở cửa sổ bảo trì cho cơ sở dữ liệu của chúng tôi. Điều này có nghĩa là không có thời gian chết được phép triển khai, nâng cấp, v.v. Loại quy tắc đó khiến bạn thay đổi cách bạn làm mọi việc. Hầu hết các thay đổi là nhỏ, bạn không thực hiện bất kỳ khóa nặng nào, bạn có các bản sao để cho phép sửa lỗi nhanh chóng. Nhưng trong khi bạn có thể làm cho các bản phát hành của mình nhỏ và không bị chặn, điều gì sẽ xảy ra khi bạn cần thực hiện nâng cấp phiên bản lớn của cơ sở dữ liệu PostgreSQL?
Bạn có thể ở trong một tình huống khác, vì hầu hết các công ty đều có cửa sổ nâng cấp, và vì vậy bạn có thể đủ thời gian ngừng hoạt động trong quá trình nâng cấp. Tuy nhiên, điều này mang lại hai vấn đề. Đối với một, không công ty nào thực sự thích thời gian ngừng hoạt động ngay cả khi chúng được phép. Và quan trọng hơn một khi cơ sở dữ liệu của bạn phát triển vượt quá kích thước gigabyte thành phạm vi terabyte hoặc hàng trăm terabyte, thời gian ngừng hoạt động có thể mất vài ngày hoặc thậm chí vài tuần và không ai có thể dừng hoạt động của chúng lâu như vậy. Kết quả là nhiều công ty thường bỏ qua những nâng cấp quan trọng, khiến những nâng cấp tiếp theo thực sự thậm chí còn đau đớn hơn. Và các nhà phát triển đang thiếu các tính năng mới, cải tiến hiệu suất. Họ (các công ty) đôi khi thậm chí có nguy cơ chạy một phiên bản PostgreSQL không còn được hỗ trợ và có các vấn đề về bảo mật hoặc hỏng dữ liệu đã biết. Trong các đoạn sau, tôi sẽ nói một chút về công việc của mình trong việc làm cho việc nâng cấp ít tốn thời gian hơn và do đó ít đau đớn hơn và hy vọng sẽ thường xuyên hơn.
Trước tiên, hãy để tôi bắt đầu với một chút lịch sử. Trước PostgreSQL 9.0, cách duy nhất để thực hiện nâng cấp phiên bản chính là chạy pg_dump và khôi phục kết xuất thành một phiên bản chạy phiên bản PostgreSQL mới hơn. Phương pháp này yêu cầu cấu trúc và tất cả dữ liệu phải được đọc từ cơ sở dữ liệu và được ghi vào một tệp. Sau đó, đọc từ tệp và chèn vào cơ sở dữ liệu mới, các chỉ mục phải được xây dựng lại, v.v.
Như bạn có thể tưởng tượng, quá trình này có thể mất khá nhiều thời gian. Cải thiện hiệu suất đã được thực hiện trong 8.4 cho pg_restore với tùy chọn -j được thêm vào nơi bạn có thể chỉ định số lượng công việc song song sẽ được chạy. Điều này giúp bạn có thể khôi phục một số bảng (chỉ mục, v.v.) song song, làm cho quá trình khôi phục nhanh hơn đối với kết xuất định dạng tùy chỉnh. Phiên bản 9.3 đã thêm tùy chọn tương tự cho pg_dump, cải thiện hiệu suất hơn nữa. Nhưng do khối lượng dữ liệu đang phát triển nhanh như thế nào, bản thân việc song song hóa không đủ để tạo ra bất kỳ lợi ích nghiêm trọng nào trong thời gian cần thiết để nâng cấp.
Sau đó, trong PostgreSQL 9.0, một tiện ích có tên là pg_upgrade đã xuất hiện. Pg_upgrade chỉ kết xuất các cấu trúc và khôi phục chúng vào cụm mới. Nhưng nó sao chép các tệp dữ liệu khi chúng ở trên đĩa, nhanh hơn nhiều so với việc kết xuất chúng sang định dạng logic và sau đó chèn lại. Điều này đủ tốt cho các cơ sở dữ liệu nhỏ vì nó có nghĩa là thời gian ngừng hoạt động trong khoảng vài phút hoặc vài giờ, thời gian có thể chấp nhận được đối với nhiều tình huống. Ngoài ra còn có chế độ liên kết chỉ tạo các liên kết cứng (điểm nối trên Windows) giúp quá trình này nhanh hơn. Nhưng theo quan điểm cá nhân của tôi, quá nguy hiểm nếu chạy thiết lập như vậy trên máy chủ sản xuất chính. Tôi sẽ giải thích ngắn gọn lý do tại sao. Nếu có sự cố xảy ra, khi bạn khởi động máy chủ mới được nâng cấp bằng chế độ liên kết, bạn đột nhiên không có cơ sở dữ liệu sản xuất và phải sửa lỗi, hoặc tệ hơn, bạn phải khôi phục từ bản sao lưu. Điều đó có nghĩa là bạn không những không nâng cấp được mà còn gây thêm thời gian chết! Chúc bạn may mắn nhận được sự chấp thuận vào lần sau.
Giờ đây, nhiều người không có đủ thời gian ngừng hoạt động để nâng cấp sử dụng các giải pháp sao chép dựa trên trình kích hoạt như Slony hoặc Londiste để thực hiện nâng cấp. Đây là một giải pháp tốt vì bạn có thể sao chép dữ liệu của mình trong khi máy chủ gốc đang chạy và sau đó chuyển đổi với thời gian chết tối thiểu. Tuy nhiên, trong thực tế có một số vấn đề. Một trong số đó là các giải pháp dựa trên trình kích hoạt thường khó thiết lập, đặc biệt nếu bạn chỉ làm điều đó vài năm một lần và chỉ để thực hiện nâng cấp. Cũng dễ dàng bỏ sót một bảng hoặc thêm các bảng không đúng thứ tự và do đó không nhận được bản sao đầy đủ. Tôi đã chứng kiến điều này trong thực tế và những người thực hiện nâng cấp đang làm việc với sao chép dựa trên trình kích hoạt hàng ngày . Một vấn đề khác là các giải pháp dựa trên trình kích hoạt thêm tải đáng kể vào cơ sở dữ liệu nguồn, đôi khi khiến cho việc nâng cấp không thể thực hiện được do máy chủ cơ sở dữ liệu trở nên quá tải khi bản sao được kích hoạt. Và cuối cùng nhưng thường không kém phần quan trọng, có thể mất rất nhiều thời gian để bản sao dựa trên trình kích hoạt thực sự di chuyển dữ liệu sang máy chủ mới. Vào dịp cuối cùng tôi tham gia vào một dự án nâng cấp, giải pháp dựa trên trình kích hoạt đã mất khoảng một tháng để sao chép cơ sở dữ liệu và bắt kịp các thay đổi. Có, một tháng.
Với PostgreSQL 9.4, tính năng giải mã logic mang lại một khởi đầu mới cho việc thiết kế một giải pháp nâng cấp trực tuyến mới và tốt hơn. Những gì chúng tôi đã làm, như một phần của dự án AXLE, là tạo ra một công cụ kết hợp giải mã logic với các kỹ thuật được mô tả ở trên. Giải pháp giải quyết hầu hết các vấn đề của các cách tiếp cận trước đây. Phần mở rộng PostgreSQL Uni-Directional Replication (viết tắt là UDR) thực hiện sao chép logic bằng cách sử dụng giải mã logic của bản ghi ghi trước (WAL). Nhờ đó, tác động lên máy chủ chính gần như ngang bằng với sao chép luồng vật lý, do đó, tải bổ sung do nâng cấp liên tục là tối thiểu trên hệ thống đang chạy. Ngoài ra, nó cung cấp các công cụ để khởi tạo các nút mới, cả sử dụng sao lưu vật lý và logic. Bạn thậm chí có thể chuyển chế độ chờ vật lý hiện có sang chế độ chờ UDR. Và bởi vì nó là một hệ thống sao chép hợp lý, có thể thiết kế nó theo cách hỗ trợ sao chép nhiều phiên bản.
Tất cả điều này có nghĩa là bây giờ chúng ta có thể sử dụng UDR kết hợp với pg_upgrade để nâng cấp trực tuyến phiên bản PostgreSQL chính với thời gian chết tối thiểu, trong khoảng thời gian ngắn và ít ảnh hưởng đến hệ thống đang chạy.
Ví dụ về cách hiển thị trong thực tế:
- Thực hiện pg_basebackup phiên bản hiện có.
- Thiết lập bản sao UDR giữa bản sao gốc và bản sao được tạo bằng basebackup.
- Pg_upgrade phiên bản mới.
- Cho phép UDR phát lại những thay đổi đã xảy ra trong thời gian chờ đợi.
- Chuyển lưu lượng sang phiên bản mới.
Để biết cách thực hiện với các hướng dẫn chi tiết hơn, hãy xem hướng dẫn Nâng cấp Trực tuyến UDR trên PostgreSQL wiki. Các nguồn UDR có sẵn trong kho lưu trữ 2ndquadrant_bdr trên máy chủ git PostgreSQL (bdr-plugin / nhánh tiếp theo).
Cuối cùng, vì UDR không chỉ là một công cụ nâng cấp trực tuyến mà còn là một giải pháp sao chép, nên nó có thể được sử dụng cho nhu cầu sao chép thông thường của bạn, thay vì sao chép trực tuyến vật lý. Hơn nữa, nó cung cấp một số lợi thế như khả năng tạo các bảng tạm thời, sao chép từ nhiều cơ sở dữ liệu OLTP vào một cơ sở dữ liệu kho dữ liệu lớn hoặc chỉ sao chép một phần của cơ sở dữ liệu.
Tôi hy vọng rằng nỗ lực này sẽ có nghĩa là việc cân nhắc thời gian ngừng hoạt động không còn là vấn đề khi nâng cấp từ PostgreSQL 9.4 trở lên lên phiên bản chính mới.
Nghiên cứu dẫn đến những kết quả này đã nhận được tài trợ từ Chương trình khung thứ bảy của Liên minh Châu Âu (FP7 / 2007-2013) theo thỏa thuận viện trợ không hoàn lại số 318633.
