“İşlem Kimliği Wraparound” hakkında

Şimdi, "İşlem Kimliği Wraparound" ile ilgili belgeyi okudum, ama gerçekten anlamadığım bir şey var, belge şu url http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # VAKUM-FOR-sarma

23.1.4. İşlem Kimliği Silme Hatalarını Önleme

PostgreSQL'in MVCC işlem semantiği, işlem kimliği (XID) sayılarını karşılaştırabilmeye bağlıdır: XID eki geçerli işlemin XID'sinden büyük olan bir satır sürümü "gelecekte" dir ve geçerli işlem tarafından görülmemelidir. Ancak işlem kimliklerinin boyutu sınırlı olduğundan (32 bit) uzun süre çalışan bir küme (4 milyardan fazla işlem) işlem kimliği sarmaına maruz kalır: XID sayacı sıfıra sarılır ve geçmiş gelecekte görünmektedir - yani çıktıları görünmez olur. Kısacası, yıkıcı veri kaybı. (Aslında veriler hala oradadır, ancak buna erişemezseniz bu soğuk rahatlıktır.) Bundan kaçınmak için, her veritabanındaki her tabloyu en az iki milyar işlemde bir vakumlamak gerekir.

"İşlem kimliği sarma işlemine maruz kalacaktır: XID sayacı sıfıra dolanıyor ve geçmişte yapılan ani işlemlerin gelecekte görüneceği anlaşılıyor - yani çıktıları görünmez oluyor"

Birisi bunu açıklayabilir mi? Veritabanı işlem kimliği sarmalamasının ardından neden geçmişte gerçekleşen işlemler gelecekte görünecek? Kısacası, PostgreSQL'in autovacuum tarafından işlem kimliği sarmalamasından sonra "veri kaybı" durumunda olup olmayacağını bilmek istiyorum。

Kişisel görünümlerim için, çıkış işleminin 64 bit olduğu ve çevrilmeyeceği txid_current () işlevini kullanarak geçerli işlem kimliğini alabiliriz. txid_current () işlevi tarafından. Bunun dışında PostgreSQL Sunucusunu kapattıktan sonra pg_resetxlog sıfırlama sıfırlama işlem kimliğini kullanacaksınız. Haklı mıyım? Teşekkürler

Veritabanı işlem kimliği sarmalamasının ardından neden geçmişte gerçekleşen işlemler gelecekte görünecek?

Yapmazlar. Alıntılanan metin sadece postgres'in neden modulo 2 ³¹ aritmatik kullanması gerektiğini açıklar (bu, eski işlemler yeterince erken dondurulduğu sürece işlemlerin sarılabileceği anlamına gelir):

Normal XID'ler modulo-2 ^ 31 aritmetiği kullanılarak karşılaştırılır. Bu, her normal XID için "eski" iki milyar XID ve "daha yeni" iki milyar XID olduğu anlamına gelir

spesifik olmak:

eski satır sürümleri, iki milyar işlemlik eski markaya ulaşmadan önce XID FrozenXID'yi yeniden atamalıdır

veya XID'nin etrafına sarılması işlerin bozulmasına neden olur. Bunu önlemek için postgres uyarılar vermeye başlayacak ve sonunda kapanacak ve gerekirse yeni işlemlere başlamayı reddedecektir:

Herhangi bir nedenden dolayı otomatik vakum, eski XID'leri bir tablodan temizleyemezse, veritabanının en eski XID'leri, sarma noktasından on milyon işleme ulaştığında, sistem bu gibi uyarı mesajları vermeye başlar:

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

(Manuel bir VACUUM, ipucu tarafından önerildiği gibi sorunu çözmelidir; ancak VACUUM'un bir süper kullanıcı tarafından gerçekleştirilmesi gerektiğini unutmayın, aksi takdirde sistem kataloglarını işleyemez ve bu nedenle veritabanının datfrozenksidini ilerletemez.) Bu uyarılar varsa yok sayılırsa, sistem kapatılıncaya kadar 1 milyondan az işlem kaldığında yeni işlemleri başlatmayı reddeder.

Diğer bir deyişle, "geçmişte gerçekleşen işlemler gelecekte gibi görünüyor" ve "veri kaybı" tamamen teoriktir ve pratikte işlem kimliği sarmalamasından kaynaklanmayacaktır.

Yapıştırdığınız blok soruyu cevaplıyor gibi görünüyor. Her şey 'gelecekteki' işlemleri gizlemek için kullanılan mantığa bağlıdır.

İşlem kimliği (XID) sayacı 32 bit ile sınırlıdır ve eğer bir sonraki sayıya ulaşırsa, eski maksimum işlemi değiştirmek yerine sıfırdan başlar.

Peki, şimdi sıfır, bu yüzden PostgreSQL> 0'dan tüm işlemleri saklıyor. Dolayısıyla, İşlem # 2,147,483,633 işleminin 20 saniye önce gerçekleşmesine rağmen, PostgreSQL bunun başka bir 2,147,483,633 işlem için olmayacağını düşünüyor.