Lỗi sao lưu nóng PostgreSQL 9.1: hệ thống cơ sở dữ liệu đang khởi động


16

Tôi đã làm việc trên một bản sao lưu nóng cho Postgres 9.1 trong một thời gian và đã gặp phải một vấn đề nhất quán. Sau khi khởi động lại Postgres trên máy chủ nô lệ, tệp nhật ký pgstartup và tệp nhật ký hàng ngày trong thư mục pg_log đọc không có lỗi. Tuy nhiên, khi tôi cố gắng nhập vào cơ sở dữ liệu bằng lệnh psql, tôi gặp lỗi:

FATAL: hệ thống cơ sở dữ liệu đang khởi động.

Tệp recovery.conf cũng không chuyển sang recovery.done. Tôi đã nghiên cứu rộng rãi lỗi này và luôn tìm thấy cùng một phản hồi: cơ sở dữ liệu chưa được tắt hoàn toàn trước khi tôi cố gắng khởi động lại Postgres. Cách duy nhất tôi đã khởi động lại Postgres là thông qua các lệnh service postgresql-9.1 restarthoặc /etc/init.d/postgresql-9.1 restart. Sau khi tôi nhận được lỗi này, tôi giết tất cả các quy trình và một lần nữa thử khởi động lại cơ sở dữ liệu và vẫn nhận được lỗi tương tự. Tôi không biết phải đi đâu từ đây và cách khắc phục vấn đề này. Dưới đây là quy trình chính xác mà tôi đã thực hiện để hoàn thành bản sao lưu nóng.

Cấu hình máy chủ chính:

pg_hba.conf, đã thêm dòng:

lưu trữ nhân rộng postgres IPAddressOfSlaveServer tin tưởng

postgresql.conf:

wal_level = hot_standby
max_wal_senders = 5
nghe_address = '*'
cổng = 5432
max_wal_senders = 5
wal_keep_segments = 32

Cấu hình máy chủ nô lệ:

postgresql.conf:

hot_standby = trên

recovery.conf:

chế độ chờ_mode = bật
chính_conninfo = máy chủ = IPAddressOfMasterServer
cổng = 5432
người dùng = postgres
restore_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "% p"'

Sau khi cấu hình cả hai máy chủ

Tôi thay đổi người dùng postgres trên máy chủ chính và chạy các lệnh:

psql -c "Chọn pg_start_backup ('nhãn', true);";
rsync -a -v -e ssh /var/lib/pgsql/9.1/data nô lệ: /var/lib/pgsql/9.1/data \
        --exclude postmaster.pid
pssql -c "chọn pg_stop_backup ();";

Sau khi đồng bộ hóa cơ sở dữ liệu với máy chủ nô lệ

Tôi khởi động lại máy chủ nô lệ và khởi động không thất bại. Các pgstartup.log đọc:

Sự thành công. Bây giờ bạn có thể khởi động máy chủ cơ sở dữ liệu bằng cách sử dụng:

    /usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data
hoặc là
    /usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l logfile bắt đầu

tệp nhật ký ngày hiện tại, postgresql-Thu.log, đọc:

Nhật ký: tắt
Nhật ký: Hệ thống cơ sở dữ liệu bị tắt
Nhật ký: hệ thống cơ sở dữ liệu đã ngừng hoạt động trong phục hồi 2012-4-10
Nhật ký: vào chế độ chờ
Nhật ký: tệp nhật ký được khôi phục "logFileName" từ kho lưu trữ
Nhật ký: trạng thái phục hồi nhất quán đạt 0 / BF0000B0
Đăng nhập: làm lại bắt đầu từ 0 / BF000020
Nhật ký: tệp nhật ký được khôi phục "logFileName" từ kho lưu trữ
Nhật ký: pageaddr bất ngờ 0/85000000 trong tệp nhật ký 0, phân đoạn 192, bù 0
Nhật ký: pageaddr bất ngờ 0/85000000 trong tệp nhật ký 0, phân đoạn 192, bù 0
Nhật ký: sao chép phát trực tuyến kết nối thành công với chính

Tôi đã nghiên cứu pageaddr bất ngờ và từ kho lưu trữ của postgres, tôi hiểu rằng nó khá bình thường và là một trong những cách dự kiến ​​để phát hiện end-of-WAL.

Bất kỳ lời khuyên sẽ được đánh giá rất cao.

Câu trả lời:


11

Thông báo "Hệ thống cơ sở dữ liệu đang khởi động." không chỉ ra lỗi. Lý do nó ở cấp độ FATAL là vì vậy nó sẽ luôn đưa nó vào nhật ký, bất kể cài đặt của log_min_messages:

http://www.postgresql.org/docs/9.1/interactive/r nb-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN

Sau rsync, bạn có thực sự chạy những gì bạn thể hiện không?:

pssql -c "chọn pg_stop_backup ();";

Vì theo tôi biết, không có gì có thể pgsqlthực thi được, điều đó sẽ khiến bản sao lưu không được hoàn thành và nô lệ sẽ không bao giờ thoát khỏi chế độ phục hồi. Mặt khác, có thể bạn thực sự đã chạy psql, bởi vì nếu không thì tôi không thấy nô lệ đã ghi lại những thông điệp thành công như thế nào:

Nhật ký: trạng thái phục hồi nhất quán đạt 0 / BF0000B0

và:

Nhật ký: sao chép phát trực tuyến kết nối thành công với chính

Bạn đã thử kết nối với nô lệ vào thời điểm này? Chuyện gì đã xảy ra?

Thông báo "Thành công. Bây giờ bạn có thể bắt đầu ..." mà bạn đề cập được tạo bởi initdb, không nên chạy như một phần của việc thiết lập nô lệ; Vì vậy, tôi nghĩ rằng bạn có thể nhầm lẫn về một cái gì đó ở đó. Tôi cũng lo ngại về những tuyên bố rõ ràng mâu thuẫn này:

Cách duy nhất tôi đã khởi động lại Postgres là thông qua các lệnh khởi động lại dịch vụ postgresql-9.1 hoặc /etc/init.d/postgresql-9.1. Sau khi tôi nhận được lỗi này, tôi giết tất cả các quy trình và một lần nữa thử khởi động lại cơ sở dữ liệu ...

Bạn đã cố gắng dừng dịch vụ thông qua tập lệnh dịch vụ? Chuyện gì đã xảy ra? Nó có thể giúp hiểu được các bản ghi nếu bạn có tiền tố với nhiều thông tin hơn. Chúng tôi sử dụng:

log_line_prefix = '[%m] %p %q<%u %d %r> '

Các recovery.confkịch bản trông lẻ. Bạn đang sao chép từ thư mục pg_xlog của chủ, thư mục pg_xlog hoạt động của nô lệ hay thư mục lưu trữ?


8

Tôi cũng có một số vấn đề với điều này, ngoại trừ tôi vào ngày 9.3, không phải 9.1. Dù sao, bản sửa lỗi hóa ra khá tầm thường:

Các postgresql.conftập tin đã được sao chép từ chủ đến nô lệ, và tôi đã để nó không được sửa đổi trên nô lệ. Tôi nghĩ rằng tất cả những gì bạn phải làm là thêm một recovery.conftệp và mọi thứ sẽ hoạt động (nó cũng vậy, nhưng tôi không thể đăng nhập vào máy chủ nô lệ được sao chép, nhưng, nó đã được sao chép).

Tôi đã chỉnh sửa postgresql.conftệp của nô lệ và:

  • bình luận ra archive_mode=on
  • nhận xét ra archivelệnh; và
  • Bình luận hot_standby=on

Điều đó đã làm điều đó: Tôi đã có thể làm cho cơ sở dữ liệu trở thành một máy chủ chỉ đọc sẵn sàng chấp nhận các truy vấn chỉ đọc.

Có một đoạn script được gọi pg_basebackupsẽ tạo thư mục bootstrap cho Slave. Đây là thư mục dữ liệu với cơ sở dữ liệu trong đó. Bạn cần sửa đổi postgresql.conftệp trước khi nó có thể được sử dụng làm nô lệ như được mô tả, một cái gì đó khá đơn giản cho một pg_basebackuptập lệnh.


1
Khi bạn viết "đã nhận xét hot_standby = trên" Tôi cho rằng bạn có nghĩa là "đã xóa # -comment-mark trước đó, để thực sự kích hoạt hot_standby" :) Nếu không ở hot_standby, db sẽ luôn "khởi động" theo thiết kế (nó ấm chờ, sẵn sàng cho chuyển đổi dự phòng, nhưng không truy vấn). Lưu ý rằng, nếu bạn đã tạo kết xuất dự phòng cơ sở mà không có wal_level = hot_standby trên bản gốc và sau đó bật hot_stanby trên nô lệ, bạn sẽ phải kết xuất lại và khởi tạo lại db db cho hot_standby để khởi động và chạy. Nếu không, bạn sẽ nhận được một số lỗi nghiêm trọng.
Frederik Struck-Schøning

hot_standby = on là bắt buộc, nó phải ở đó
Abhilash Mishra

7

Thật thú vị tôi đã giải quyết điều này theo cách ngược lại mà Paul đã làm.

Tôi đã thêm:

hot_standby = on

hoặc, đúng hơn, thay đổi #hot_standby = offở trên. (Đây là sử dụng 9.5)


1

Tôi đã nhận được điều này trong nhật ký:

MSK FATAL:  the database system is starting up

Để sửa lỗi khởi động vô hạn của máy chủ, hãy làm điều này: Dừng dịch vụ (nếu tồn tại), hủy quá trình 'postgres' (thường là nó tồn tại). Chạy cái này trong console:

pg_resetxlog.exe -D ../Data -f

Ussue này xuất hiện vì thư mục xLog có dữ liệu, không được ghi trước khi dịch vụ ngừng hoạt động. Và sau đó khi khởi động dịch vụ, anh cố gắng sửa dữ liệu đó. Đôi khi, nó đóng băng khởi động và không bao giờ kết thúc .. Lệnh khi dọn sạch dữ liệu không trộn này, dịch vụ đó chỉ bắt đầu với dữ liệu cố định. Có thể một số phần của dữ liệu không trộn sẽ bị mất, nhưng máy chủ cơ sở dữ liệu sẽ chạy bình thường và có thể được truy cập bởi các ứng dụ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.