Sao chép một số bảng từ cơ sở dữ liệu postgres này sang cơ sở dữ liệu khác


9

Tôi đã gặp tình huống sau: Tôi có ba máy chạy cơ sở dữ liệu postgresql. Một máy chứa thông tin tài khoản khách hàng (gọi máy này là C), hai máy còn lại chứa thông tin đăng nhập máy khách (gọi các L1 và L2 này). Lý do cho sự phân chia là để phân tách tải trên nhiều máy (vì vậy một số khách hàng gửi thông tin đăng nhập tới L1, một số đến L2 ... và có thể đôi khi L3, L4, ...).

Khi truy xuất thông tin đăng nhập, về nguyên tắc, tôi muốn có thể THAM GIA giữa các bảng ghi nhật ký trên Ln và các bảng tài khoản khách hàng trên C. Thực tế tôi không thể THAM GIA như thế này (và thậm chí nếu tôi có thể, tôi muốn để tránh tải C).

Suy nghĩ của tôi là sao chép các bảng trên C lên từng L1, L2, ... để tôi có thể thực hiện các phép nối. Theo như các bảng từ C, C là chủ và L1, L2, ... là nô lệ. Nhưng đối với các bảng khác trên L1, L2, ... những máy này là bậc thầy. Nó không chính xác là bản sao chính chủ, và nó không chính xác là chủ nô.

Có thể thuyết phục sao chép (tôi đang chạy 9.1) để thực hiện việc này hay không, nếu không có gói nào khác sẽ thực hiện công việc. Trong giải pháp cuối cùng, tôi có thể viết một số mã đồng bộ hóa định kỳ các bảng (tôi có thể chịu được một số độ trễ), nhưng sẽ rất tuyệt nếu không!

Cảm ơn trước.


1
Có thể sử dụng FDW trên các máy đăng nhập để truy cập C? Mặc dù, điều đó sẽ gây ra một cú đánh hiệu suất trên C. Lượt xem được vật chất hóa có thể làm giảm lượt truy cập hiệu năng, nhưng tôi không chắc chắn làm thế nào PostgreQuery phát hiện các bản cập nhật cho bảng nước ngoài. Nếu nó tự động (mà phần cuối của tài liệu Chế độ xem có vẻ gợi ý), điều này có thể giải quyết hoàn toàn vấn đề của bạn. Đây là 9,3 tính năng, mặc dù. Danh sách gửi thư rất tích cực cũng có thể giúp đỡ.
jpmc26

Câu trả lời:


4

Trên PostgreQuery 9.3, bạn có thể sử dụng postgres_fdwđể truy vấn bảng trong nước trên máy khác.

Trên các phiên bản cũ hơn, dblinkcó thể là một tùy chọn như được đề cập bởi Andrew.

Một tùy chọn khác là sử dụng một công cụ như Londiste hoặc Slony-I để sao chép các bảng bạn muốn. Tôi khuyên bạn nên sử dụng Londiste cho việc này, nó sẽ đơn giản hơn nhiều. Nó tạo ra các kích hoạt trên bảng để phát hiện chèn / cập nhật / xóa và sao chép chúng bằng cách sử dụng máy khách / máy chủ của chính nó và một hệ thống xếp hàng vào cơ sở dữ liệu khác, nơi nó chèn / cập nhật / xóa tương ứng. Tôi sử dụng nó trong sản xuất trên một số trang web của khách hàng và nó hoạt động rất tốt.

Một tùy chọn trong tương lai (hy vọng trong PostgreQuery 9.5) sẽ ghi nhật ký sao chép logic, trích xuất thay đổi logic và sao chép hai chiều, cho phép các cơ sở dữ liệu hoặc bảng riêng lẻ được sao chép ở cấp SQL. Một phần công việc cho việc này đã được cam kết với PostgreQuery 9.4, nhưng không đủ để làm cho nó hữu ích cho những gì bạn muốn làm.


3

Bạn nên sử dụng dblinks và quan điểm cụ thể hóa để đạt được điều này. Cả hai tính năng đều được tích hợp sẵn trong các phiên bản mới nhất của Postgres:

http://www.postgresql.org/docs/9.3/static/rules-m Materializedview.html

http://www.postgresql.org/docs/9.3/static/dblink.html

Về cơ bản, bạn xây dựng một Mview trên mỗi cơ sở dữ liệu L1, L2 ... với dữ liệu được trích xuất từ ​​các bảng trên C, sau đó sử dụng Mview refresh để định kỳ cập nhật Mview thường xuyên theo yêu cầu. Dữ liệu được lưu trữ cục bộ nên việc truy cập nó rất nhanh. Điều này chỉ phù hợp nếu dữ liệu tương đối tĩnh và đôi khi bạn không bận tâm đến cơ sở dữ liệu cục bộ có thông tin lỗi thời. Bạn nên đặt tần số làm mới để quản lý tần số này một cách thích hợp và nếu không chấp nhận được thì bạn chỉ nên sử dụng một liên kết cơ sở dữ liệu và xử lý sự chậm chạp kết quả.

Nếu bạn cần chức năng bổ sung, dự án ảnh chụp nhanh cung cấp các tính năng nâng cao như làm mới nhanh và nhật ký ảnh chụp nhanh:

http://pgfoundry.org/projects/snapshot/

Với điều này, bạn có thể làm mới chỉ cập nhật các hàng cần cập nhật, có thể làm cho chúng cực nhanh cho các bộ dữ liệu lớn, không co giãn, giảm thiểu gián đoạn cho ứng dụng của bạn. Theo mặc định, Mview hoàn toàn bị loại bỏ và được tạo lại trong Postgres, điều này có thể rất tệ cho hiệu suất vì những lý do rõ ràng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.