PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Hướng dẫn của một chuyên gia về sao chép Slony cho PostgreSQL

Slony là gì?

Slony-I (gọi tắt là ‘Slony’ từ đây trở đi) là một hệ thống sao chép của bên thứ ba dành cho PostgreSQL có từ trước phiên bản 8.0, làm cho nó trở thành một trong những tùy chọn cũ hơn để nhân bản. Nó hoạt động như một phương pháp sao chép dựa trên trình kích hoạt, là một giải pháp 'chính cho nhiều nô lệ'.

Slony hoạt động bằng cách cài đặt các trình kích hoạt trên mỗi bảng để sao chép, trên cả bảng chính và bảng phụ, và mỗi khi bảng nhận được CHÈN, CẬP NHẬT hoặc XÓA, nó sẽ ghi lại bản ghi nào được thay đổi và thay đổi đó là gì. Các quy trình bên ngoài, được gọi là 'slon daemon', kết nối với cơ sở dữ liệu như bất kỳ máy khách nào khác và tìm nạp các thay đổi từ nút chính, sau đó phát lại chúng trên tất cả các nút phụ đã đăng ký với máy chủ. Trong một thiết lập sao chép hoạt động tốt, điều này không đồng bộ quá trình sao chép có thể diễn ra ở bất kỳ nơi nào trễ hơn bản gốc từ 1 đến 20 giây.

Theo bài viết này, phiên bản mới nhất của Slony là phiên bản 2.2.6 và hỗ trợ PostgreSQL 8.3 trở lên. Hỗ trợ vẫn tiếp tục cho đến ngày nay với các bản cập nhật nhỏ, tuy nhiên nếu phiên bản tương lai của PostgreSQL thay đổi chức năng cơ bản của các giao dịch, chức năng, trình kích hoạt hoặc các tính năng cốt lõi khác, thì dự án Slony có thể quyết định ngừng cập nhật lớn để hỗ trợ các phương pháp mới mạnh mẽ như vậy.

Linh vật của PostgreSQL là một con voi được gọi là ‘Slonik’, tiếng Nga có nghĩa là “chú voi con”. Vì dự án nhân bản này có nhiều cơ sở dữ liệu PostgreSQL sao chép với nhau, nên từ tiếng Nga có nghĩa là voi (số nhiều) được sử dụng:Slony.

Các khái niệm

  • Cluster:Một bản sao của Slony.
  • Nút:Một cơ sở dữ liệu PostgreSQL cụ thể dưới dạng nút sao chép Slony, hoạt động như một nút chính hoặc nô lệ cho một tập hợp sao chép.
  • Nhóm sao chép:Một nhóm các bảng và / hoặc chuỗi sẽ được sao chép.
  • Người đăng ký:Người đăng ký là một nút được đăng ký vào một nhóm sao chép và nhận các sự kiện sao chép cho tất cả các bảng và chuỗi trong bộ đó từ nút chính.
  • Daemon Slony:Các công nhân chính thực hiện sao chép, một daemon Slony được khởi chạy cho mọi nút trong tập hợp nhân bản và thiết lập các kết nối khác nhau đến nút mà nó quản lý, cũng như nút chính.

Cách sử dụng

Slony được cài đặt bằng nguồn hoặc thông qua các kho lưu trữ PGDG (PostgreSQL Global Development Group) sẵn có cho các bản phân phối linux dựa trên Red Hat và Debian. Các mã nhị phân này phải được cài đặt trên tất cả các máy chủ chứa nút chính hoặc nút phụ trong hệ thống sao chép.

Sau khi cài đặt, một cụm sao chép Slony được thiết lập bằng cách đưa ra một vài lệnh sử dụng nhị phân ‘slonik’. ‘Slonik’ là một lệnh có cú pháp đơn giản nhưng độc đáo của riêng nó để khởi tạo và duy trì một cụm từ slony. Đây là giao diện chính để ban hành các lệnh cho cụm Slony đang chạy có nhiệm vụ sao chép.

Giao diện với Slony có thể được thực hiện bằng cách viết các lệnh slonik tùy chỉnh hoặc biên dịch slony với cờ --with-perltools, cờ cung cấp các tập lệnh ‘altperl’ giúp tạo các tập lệnh slonik cần thiết này.

Tạo một cụm sao chép Slony

‘Cụm sao chép’ là một tập hợp các cơ sở dữ liệu là một phần của quá trình sao chép. Khi tạo một cụm sao chép, một tập lệnh init cần được viết để xác định những điều sau:

  • Tên của cụm Slony mong muốn
  • Thông tin kết nối cho mỗi phần nút của bản sao, mỗi phần có một số nút không thay đổi.
  • Liệt kê tất cả các bảng và chuỗi sẽ được sao chép như một phần của "bộ sao chép".

Bạn có thể tìm thấy tập lệnh mẫu trong tài liệu chính thức của Slony.

Khi được thực thi, slonik sẽ kết nối với tất cả các nút được xác định và tạo lược đồ Slony trên mỗi nút. Khi các trình duyệt Slony được khởi chạy, sau đó chúng sẽ xóa tất cả dữ liệu trong các bảng sao chép trên nô lệ (nếu có) và sao chép tất cả dữ liệu từ chủ sang (các) nô lệ. Kể từ thời điểm đó, các daemon sẽ liên tục sao chép các thay đổi được ghi lại trên trang cái cho tất cả các nô lệ đã đăng ký.

Cấu hình thông minh

Trong khi Slony ban đầu là một hệ thống sao chép Master-to-Multiple-Slave và chủ yếu được sử dụng theo cách đó, có một số tính năng và cách sử dụng thông minh khác làm cho Slony hữu ích hơn một giải pháp sao chép đơn giản. Bản chất có thể tùy chỉnh cao của Slony giúp nó phù hợp với nhiều tình huống khác nhau cho các quản trị viên có thể suy nghĩ thấu đáo.

Sao chép theo tầng

Các nút Slony có thể được thiết lập để sao chép theo tầng xuống một chuỗi các nút khác nhau. Nếu nút chính được biết là có tải cực kỳ nặng, mỗi nút phụ sẽ tăng tải đó lên một chút. Với sao chép theo tầng, một nút phụ duy nhất được kết nối với nút chính có thể được định cấu hình làm 'nút chuyển tiếp', sau đó sẽ chịu trách nhiệm gửi các sự kiện sao chép tới nhiều nô lệ hơn, giữ cho tải trên nút chính ở mức tối thiểu.

Sao chép xếp tầng với Slony

Xử lý dữ liệu trên nút nô lệ

Không giống như PostgreSQL được xây dựng trong bản sao, các nút nô lệ không thực sự là "chỉ đọc", chỉ các bảng đang được sao chép bị khóa dưới dạng "chỉ đọc". Điều này có nghĩa là trên một nút nô lệ, quá trình xử lý dữ liệu có thể diễn ra bằng cách tạo các bảng mới không phải là một phần của quá trình sao chép sang dữ liệu đã xử lý. Một phần của bản sao các bảng cũng có thể có các chỉ mục tùy chỉnh được tạo tùy thuộc vào các mẫu truy cập có thể khác với nô lệ và chính.

Các bảng chỉ đọc trên các nô lệ vẫn có thể có các chức năng dựa trên trình kích hoạt tùy chỉnh được thực thi khi thay đổi dữ liệu, cho phép tùy chỉnh nhiều hơn với dữ liệu.

Xử lý dữ liệu trên nút Slony Slave

Nâng cấp thời gian ngừng hoạt động tối thiểu

Việc nâng cấp các phiên bản chính của PostgreSQL có thể rất tốn thời gian. Tùy thuộc vào kích thước dữ liệu và số lượng bảng, quá trình nâng cấp bao gồm cả quá trình ‘phân tích’ sau nâng cấp có thể mất vài ngày thậm chí. Vì Slony có thể sao chép dữ liệu giữa các cụm PostgreSQL của các phiên bản khác nhau, nên nó có thể được sử dụng để thiết lập sao chép giữa phiên bản cũ hơn với tư cách là chính và phiên bản mới hơn làm nô lệ. Khi quá trình nâng cấp diễn ra, chỉ cần thực hiện 'chuyển đổi', biến nô lệ thành chủ mới và chủ cũ trở thành nô lệ. Khi quá trình nâng cấp được đánh dấu là thành công, hãy ngắt cụm sao chép Slony và đóng cơ sở dữ liệu cũ.

Nâng cấp PostgreSQL với Thời gian ngừng hoạt động tối thiểu bằng Slony

Tính khả dụng cao với việc bảo trì máy chủ thường xuyên

Giống như thời gian chết tối thiểu để nâng cấp, bảo trì máy chủ có thể được thực hiện dễ dàng mà không có thời gian chết bằng cách thực hiện 'chuyển đổi' giữa hai hoặc nhiều nút, cho phép khởi động lại máy chủ với các bản cập nhật / bảo trì khác. Khi nô lệ trực tuyến trở lại, nó sẽ kết nối lại với cụm sao chép và bắt kịp tất cả dữ liệu được sao chép. Người dùng cuối kết nối với cơ sở dữ liệu có thể bị gián đoạn giao dịch trong thời gian dài, nhưng bản thân thời gian chết sẽ là vài giây khi quá trình chuyển đổi xảy ra, thay vì mất nhiều thời gian để khởi động lại / cập nhật máy chủ.

Đăng nhập Vận chuyển

Mặc dù có thể không phải là giải pháp phổ biến, nhưng nô lệ Slony có thể được thiết lập như một nút "log shipping", nơi tất cả dữ liệu mà nó nhận được thông qua quá trình nhân bản có thể được ghi vào các tệp SQL và được chuyển đi. Điều này có thể được sử dụng vì nhiều lý do, chẳng hạn như ghi vào ổ đĩa ngoài và vận chuyển đến cơ sở dữ liệu nô lệ theo cách thủ công chứ không phải qua mạng, được nén và lưu trữ để sao lưu trong tương lai hoặc thậm chí có chương trình bên ngoài phân tích cú pháp tệp SQL và sửa đổi nội dung.

Chia sẻ nhiều dữ liệu cơ sở dữ liệu

Vì bất kỳ số lượng bảng nào có thể được sao chép theo ý muốn, các bộ sao chép Slony có thể được thiết lập để chia sẻ các bảng cụ thể giữa các cơ sở dữ liệu. Mặc dù có thể đạt được quyền truy cập tương tự thông qua Trình gói dữ liệu nước ngoài (đã được cải thiện trong các bản phát hành PostgreSQL gần đây), nhưng tùy thuộc vào cách sử dụng có thể là một giải pháp tốt hơn để sử dụng Slony. Nếu cần một lượng lớn dữ liệu để tìm nạp từ máy chủ này sang máy chủ khác, việc Slony sao chép dữ liệu đó có nghĩa là dữ liệu cần thiết đã tồn tại trên nút yêu cầu, loại bỏ thời gian truyền lâu.

Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

Sao chép bị trì hoãn

Thông thường, việc sao chép được mong muốn càng nhanh càng tốt, nhưng có thể có một số trường hợp trong đó mong muốn có độ trễ. Daemon slon cho nút phụ có thể được định cấu hình bằng lag_interval, nghĩa là nó sẽ không nhận được bất kỳ dữ liệu sao chép nào cho đến khi dữ liệu cũ như được chỉ định. Điều này có thể hữu ích để truy cập nhanh vào dữ liệu bị mất nếu có sự cố, chẳng hạn như nếu một hàng bị xóa, hàng đó sẽ tồn tại trên máy chủ trong 1 giờ để truy xuất nhanh.

Những điều cần biết:

  • Mọi thay đổi DDL đối với các bảng là một phần của quá trình sao chép phải được thực thi bằng lệnh thực thi slonik.
  • Bất kỳ bảng nào được sao chép đều phải có khóa chính hoặc chỉ mục DUY NHẤT không có cột rỗng.
  • Dữ liệu được sao chép từ nút chính sẽ được sao chép sau khi bất kỳ dữ liệu nào có thể đã được tạo về mặt chức năng. Có nghĩa là nếu dữ liệu được tạo bằng cách sử dụng thứ gì đó như 'random ()', thì số kết quả sẽ được lưu trữ và sao chép trên các nô lệ, chứ không phải là 'random ()' được chạy lại trên nô lệ trả về một kết quả khác.
  • Thêm bản sao Slony sẽ làm tăng tải máy chủ một chút. Trong khi được viết hiệu quả, mỗi bảng sẽ có một trình kích hoạt ghi nhật ký từng CHÈN, CẬP NHẬT và XÓA vào một bảng Slony, dự kiến ​​tải máy chủ sẽ tăng khoảng 2-10%, tùy thuộc vào kích thước cơ sở dữ liệu và khối lượng công việc.

Mẹo và Thủ thuật:

  • Daemon của Slony có thể chạy trên bất kỳ máy chủ nào có quyền truy cập vào tất cả các máy chủ khác, tuy nhiên, cấu hình hoạt động cao nhất là để các daemon chạy trên các nút mà chúng đang quản lý. Ví dụ:trình nền chính chạy trên nút chính, trình nền phụ chạy trên nút phụ.
  • Nếu thiết lập một cụm sao chép với một lượng rất lớn dữ liệu, thì quá trình sao chép ban đầu có thể mất khá nhiều thời gian, có nghĩa là tất cả các thay đổi xảy ra từ khi bắt đầu cho đến khi sao chép xong có thể còn lâu hơn để bắt kịp và đồng bộ hóa . Điều này có thể được giải quyết bằng cách thêm một vài bảng cùng một lúc để sao chép (rất tốn thời gian) hoặc bằng cách tạo bản sao thư mục dữ liệu của cơ sở dữ liệu chính cho máy nô lệ, sau đó thực hiện 'bộ đăng ký' với tùy chọn OMIT COPY được đặt thành THÀNH THẬT. Với tùy chọn này, Slony sẽ cho rằng bảng phụ giống 100% với bảng chính và không xóa nó đi và sao chép dữ liệu.
  • Tình huống tốt nhất cho việc này là tạo Chế độ chờ nóng bằng cách sử dụng các công cụ tích hợp sẵn cho PostgreSQL và trong thời gian bảo trì không có kết nối nào sửa đổi dữ liệu, đưa chế độ chờ trực tuyến như một chế độ chính, xác thực dữ liệu phù hợp giữa cả hai, bắt đầu cụm sao chép slony với OMIT COPY =true, và cuối cùng là kích hoạt lại các kết nối máy khách. Quá trình này có thể mất thời gian để thiết lập Chế độ chờ nóng, nhưng quá trình này sẽ không gây ra tác động tiêu cực lớn cho khách hàng.

Cộng đồng và Tài liệu

Cộng đồng dành cho Slony có thể được tìm thấy trong danh sách gửi thư, có tại http://lists.slony.info/mailman/listinfo/slony1-general, cũng bao gồm các kho lưu trữ.

Tài liệu có sẵn trên trang web chính thức, http://slony.info/documentation/, và cung cấp trợ giúp về phân tích nhật ký và đặc tả cú pháp để giao tiếp với slony.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL Giữa mệnh đề với các cột chuỗi

  2. Tổng quan về Biên dịch Just-in-Time (JIT) cho PostgreSQL

  3. Spring Batch - Không thể tạo bảng siêu dữ liệu trên Postgres và tải dữ liệu thực tế vào mysql

  4. Chú thích ngủ đông cho kiểu nối tiếp PostgreSQL

  5. Postgres thiếu lỗi nhập mệnh đề FROM trên truy vấn với mệnh đề WITH