Giới thiệu về giao dịch ID ID


9

Bây giờ, tôi đã đọc tài liệu về "Gói giao dịch ID", nhưng có một điều mà tôi thực sự không hiểu, tài liệu này là url sau http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # VACUUM-CHO-VIẾT

23.1.4. Ngăn chặn các lỗi giao dịch ID

Ngữ nghĩa giao dịch MVCC của PostgreQuery phụ thuộc vào việc có thể so sánh các số ID giao dịch (XID): phiên bản hàng với XID chèn lớn hơn XID của giao dịch hiện tại là "trong tương lai" và không thể hiển thị cho giao dịch hiện tại. Nhưng vì ID giao dịch có kích thước giới hạn (32 bit), một cụm hoạt động trong một thời gian dài (hơn 4 tỷ giao dịch) sẽ bị ảnh hưởng bởi ID giao dịch: bộ đếm XID bao quanh bằng 0 và tất cả các giao dịch đột ngột nằm trong quá khứ dường như là trong tương lai - có nghĩa là đầu ra của họ trở nên vô hình. Trong ngắn hạn, mất dữ liệu thảm khốc. (Trên thực tế dữ liệu vẫn còn, nhưng đó là sự thoải mái lạnh lẽo nếu bạn không thể truy cập được.) Để tránh điều này, cần phải hút sạch mọi bảng trong mỗi cơ sở dữ liệu ít nhất hai tỷ giao dịch một lần.

Tôi không hiểu các tuyên bố "sẽ bị ảnh hưởng bởi ID giao dịch: bộ đếm XID kết thúc bằng 0 và tất cả các giao dịch đột ngột trong quá khứ dường như là trong tương lai - điều đó có nghĩa là đầu ra của chúng trở nên vô hình"

Ai đó có thể giải thích điều này? Tại sao sau khi cơ sở dữ liệu bị ảnh hưởng ID giao dịch, các giao dịch trong quá khứ sẽ xuất hiện trong tương lai? Nói tóm lại, tôi muốn biết liệu PostgreSQL sẽ trong tình huống "mất dữ liệu" sau khi hoàn tất ID giao dịch bằng cách tự động

Đối với quan điểm cá nhân của tôi, chúng tôi có thể nhận được ID giao dịch hiện tại bằng cách sử dụng hàm txid_cản () có đầu ra là 64 bit và sẽ không bị chu kỳ. bởi hàm txid_cản (). Ngoại trừ việc bạn sẽ sử dụng ID giao dịch đặt lại pg_resetxlog sau khi tắt máy chủ PostgreQuery. Tôi có đúng không Cảm ơn


Tôi nghĩ rằng chỉnh sửa mới nhất của bạn có lẽ nên là một câu hỏi mới nếu có thể
Jack nói hãy thử topanswers.xyz

Câu trả lời:


9

Tại sao sau khi cơ sở dữ liệu bị ảnh hưởng ID giao dịch, các giao dịch trong quá khứ sẽ xuất hiện trong tương lai?

Họ không. Văn bản được trích dẫn chỉ giải thích lý do tại sao postgres cần sử dụng modulo 2 31 arithmatic (có nghĩa là các giao dịch có thể bao quanh chừng nào các giao dịch cũ bị 'đóng băng' sớm):

XID thông thường được so sánh bằng cách sử dụng số học modulo-2 ^ 31. Điều này có nghĩa là với mỗi XID bình thường, có hai tỷ XID "cũ hơn" và hai tỷ "mới hơn"

để được cụ thể:

các phiên bản hàng cũ phải được chỉ định lại XID FrozenXID trước khi chúng đạt đến mốc hai tỷ giao dịch cũ

hoặc bọc XID xung quanh sẽ khiến mọi thứ bị phá vỡ. Để ngăn chặn điều đó, postgres sẽ bắt đầu phát ra các cảnh báo, và cuối cùng đóng cửa và từ chối bắt đầu giao dịch mới nếu cần thiết:

Nếu vì một lý do nào đó, autovacuum không xóa các XID cũ khỏi bảng, hệ thống sẽ bắt đầu phát ra các thông báo cảnh báo như thế này khi các XID cũ nhất của cơ sở dữ liệu đạt mười triệu giao dịch từ điểm kết thúc:

WARNING:  database "mydb" must be vacuumed within 177009986 transactions 
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb". 

. bị bỏ qua, hệ thống sẽ ngừng hoạt động và từ chối bắt đầu bất kỳ giao dịch mới nào khi chỉ còn ít hơn 1 triệu giao dịch cho đến khi hoàn tất

Nói cách khác, "các giao dịch trong quá khứ dường như là trong tương lai" và "mất dữ liệu" hoàn toàn là lý thuyết và sẽ không được gây ra bởi sự bao bọc ID giao dịch trong thực tế.



5

Khối bạn dán dường như trả lời câu hỏi. Tất cả phụ thuộc vào logic được sử dụng để ẩn các giao dịch 'tương lai'.

Bộ đếm ID giao dịch (XID) được giới hạn ở 32 bit và nếu nó đạt đến số tiếp theo, thay vì thay thế giao dịch tối đa cũ, nó sẽ bắt đầu mới ở mức 0.

Chà, bây giờ là 0, vì vậy PostgreSQL đang ẩn tất cả các giao dịch> 0 khỏi nó. Vì vậy, mặc dù Giao dịch # 2.147.483.633 đã xảy ra cách đây 20 giây, PostgreSQL cho rằng điều đó sẽ không xảy ra đối với 2.147.483.633 giao dịch khác.


1
Các tài liệu đã được sửa vào tháng 12 năm 2013. Các XID được tính toán bằng modulo-2 ^ 31.
eradman
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.