Bruce Momjian'ın 2020 tarihli "Postgres Kilit Yöneticisinin Kilidini Açma" konuşmasının metni.
(Not: Slaytlardaki tüm SQL sorgularına bu bağlantıdan ulaşabilirsiniz: )
Merhaba! Tekrar Rusya'da olmak harika. Geçen yıl gelemediğim için üzgünüm ama bu yıl Ivan'la büyük planlarımız var. Umarım daha sık burada olurum. Rusya'ya gelmeyi seviyorum. Tyumen, Tver'i ziyaret edeceğim. Bu şehirleri ziyaret edebileceğim için çok mutluyum.
Benim adım Bruce Momjian. EnterpriseDB'de çalışıyorum ve 23 yılı aşkın süredir Postgres ile çalışıyorum. ABD'nin Philadelphia şehrinde yaşıyorum. Yılın yaklaşık 90 günü seyahat ediyorum. Ve 40'a yakın konferansa katılıyorum. Benim Şimdi size göstereceğim slaytları içeren. Bu nedenle konferanstan sonra bunları kişisel web sitemden indirebilirsiniz. Ayrıca yaklaşık 30 sunum içermektedir. Ayrıca videolar ve 500'den fazla çok sayıda blog girişi var. Bu oldukça bilgilendirici bir kaynak. Ve eğer bu materyalle ilgileniyorsanız, sizi onu kullanmaya davet ediyorum.
Postgres'le çalışmaya başlamadan önce öğretmendim, profesördüm. Ve şimdi size söylemek üzere olduğum şeyi söyleyebileceğim için çok mutluyum. Bu benim en ilginç sunumlarımdan biri. Ve bu sunum 110 slayttan oluşuyor. Basit şeylerle konuşmaya başlayacağız ve sonunda rapor giderek daha karmaşık hale gelecek, oldukça karmaşık hale gelecektir.
Bu oldukça hoş olmayan bir konuşma. Engelleme en popüler konu değildir. Bunun bir yerlerde kaybolmasını istiyoruz. Dişçiye gitmek gibi bir şey bu.
- Kilitleme, veritabanlarında çalışan ve aynı anda birden fazla işlemin çalıştığı birçok kişi için bir sorundur. Engellemeye ihtiyaçları var. Yani bugün size engelleme konusunda temel bilgiler vereceğim.
- İşlem kimlikleri. Bu sunumun oldukça sıkıcı bir kısmı ama anlaşılması gerekiyor.
- Daha sonra engelleme türlerinden bahsedeceğiz. Bu oldukça mekanik bir parça.
- Aşağıda bazı engelleme örnekleri vereceğiz. Ve anlaşılması oldukça zor olacak.
Engelleme konusunu konuşalım.
Terminolojimiz oldukça karmaşık. Kaçınız bu pasajın nereden geldiğini biliyor? İki insan. Bu Colossal Cave Adventure adlı bir oyundan. Sanırım 80'lerde metin tabanlı bir bilgisayar oyunuydu. Orada bir mağaraya, bir labirente girmek zorundaydınız ve metin değişti, ancak içerik her seferinde hemen hemen aynıydı. Bu oyunu böyle hatırlıyorum.
Ve burada Oracle'dan bize gelen kilitlerin adını görüyoruz. Onları kullanıyoruz.
Burada kafamı karıştıran terimleri görüyoruz. Örneğin, GÜNCELLEME ECXLUSIVE'I PAYLAŞIN. Sonraki RAW ECXLUSIVE'I PAYLAŞIN. Doğrusunu söylemek gerekirse bu isimler çok net değil. Onları daha ayrıntılı olarak ele almaya çalışacağız. Bazıları ayırmak anlamına gelen “paylaşmak” kelimesini içeriyor. Bazıları “özel” kelimesini içeriyor. Bazıları bu kelimelerin her ikisini de içerir. Bu kilitlerin nasıl çalıştığıyla başlamak istiyorum.
Ve “erişim” kelimesi de çok önemlidir. Ve "satır" kelimeleri bir dizedir. Yani erişim dağıtımı, satır dağıtımı.
Postgres'te anlaşılması gereken ve maalesef konuşmamda değinemeyeceğim bir diğer konu da MVCC'dir. Bu konuyla ilgili web sitemde ayrı bir sunumum var. Ve eğer bu sunumun zor olduğunu düşünüyorsanız, MVCC muhtemelen benim en zorumdur. Eğer ilgileniyorsanız, web sitesinde izleyebilirsiniz. Videoyu izleyebilirsiniz.
Anlamamız gereken bir diğer şey ise işlem kimlikleridir. Birçok işlem benzersiz tanımlayıcılar olmadan çalışamaz. Ve burada bir işlemin ne olduğuna dair bir açıklamamız var. Postgres'in iki işlem numaralandırma sistemi vardır. Bunun pek hoş bir çözüm olmadığını biliyorum.
Ayrıca slaytların anlaşılmasının oldukça zor olacağını unutmayın, dolayısıyla kırmızıyla vurgulanan kısımlara dikkat etmeniz gerekiyor.
Görelim. İşlem numarası kırmızı renkle vurgulanmıştır. SELECT pg_back işlevi burada gösterilmektedir. İşlemimi ve işlem kimliğini döndürür.
Bir şey daha, eğer bu sunumu beğendiyseniz ve veritabanınızda çalıştırmak istiyorsanız pembe renkli bu bağlantıya gidip bu sunumun SQL'ini indirebilirsiniz. Ve bunu PSQL'inizde çalıştırabilirsiniz ve sunumun tamamı anında ekranınızda olacaktır. İçerisinde çiçek olmayacak ama en azından görebiliyoruz.
Bu durumda işlem kimliğini görüyoruz. Bu ona atadığımız numara. Postgres'te sanal işlem kimliği adı verilen başka bir işlem kimliği türü daha vardır.
Ve bunu anlamalıyız. Bu çok önemli yoksa Postgres'te kilitlemeyi anlayamayacağız.
Sanal işlem kimliği, kalıcı değerler içermeyen bir işlem kimliğidir. Örneğin, bir SELECT komutunu çalıştırırsam büyük olasılıkla veritabanını değiştirmeyeceğim, hiçbir şeyi kilitlemeyeceğim. Yani basit bir SELECT çalıştırdığımızda bu işleme kalıcı bir kimlik vermiyoruz. Orada ona sadece sanal kimlik veriyoruz.
Bu da Postgres performansını artırır, temizleme yeteneklerini geliştirir, böylece sanal işlem kimliği iki sayıdan oluşur. Eğik çizgiden önceki ilk sayı arka uç kimliğidir. Ve sağda sadece bir sayaç görüyoruz.
Bu nedenle, bir istek çalıştırdığımda arka uç kimliğinin 2 olduğunu söylüyor.
Ve eğer bu tür bir dizi işlemi çalıştırırsam, her sorgu çalıştırdığımda sayacın arttığını görürüz. Örneğin, 2/10, 2/11, 2/12 vb. sorgusunu çalıştırdığımda.
Burada iki sütun olduğunu unutmayın. Solda sanal işlem kimliğini görüyoruz – 2/12. Sağ tarafta ise kalıcı bir işlem kimliğimiz var. Ve bu alan boş. Ve bu işlem veritabanını değiştirmez. Bu yüzden ona kalıcı bir işlem kimliği vermiyorum.
Analiz komutunu ((ANALYZE)) çalıştırdığımda aynı sorgu bana kalıcı bir işlem kimliği veriyor. Bakın bu bizim için nasıl değişti. Daha önce bu kimliğe sahip değildim ama artık sahibim.
İşte başka bir talep, başka bir işlem. Sanal işlem sayısı 2/13'tür. Kalıcı bir işlem kimliği istersem, sorguyu çalıştırdığımda onu alacağım.
Yani bir kez daha. Bir sanal işlem kimliğimiz ve kalıcı bir işlem kimliğimiz var. Postgres davranışını anlamak için bu noktayı anlamanız yeterli.
Üçüncü bölüme geçiyoruz. Burada Postgres'teki farklı kilit türlerini inceleyeceğiz. Pek ilginç değil. Son bölüm çok daha ilginç olacak. Ancak temel şeyleri dikkate almalıyız çünkü aksi takdirde bundan sonra ne olacağını anlayamayacağız.
Bu bölümü inceleyeceğiz, her kilit türüne bakacağız. Size bunların nasıl kurulduğuna ve nasıl çalıştığına dair örnekler göstereceğim. Postgres'te kilitlemenin nasıl çalıştığını görmek için kullanabileceğiniz bazı sorgular göstereceğim.
Bir sorgu oluşturmak ve Postgres'te neler olduğunu görmek için sorguyu sistem görünümünde yayınlamamız gerekir. Bu durumda pg_lock kırmızı renkle vurgulanır. Pg_lock, Postgres'te şu anda hangi kilitlerin kullanıldığını bize bildiren bir sistem tablosudur.
Ancak pg_lock'u tek başına size göstermek benim için çok zor çünkü oldukça karmaşık. Böylece pg_locks'u gösteren bir görünüm oluşturdum. Ayrıca benim için daha iyi anlamamı sağlayacak bazı işler de yapıyor. Yani kilitlerimi, kendi oturumumu vb. hariç tutar. Bu sadece standart SQL'dir ve size neler olduğunu daha iyi göstermenize olanak tanır.
Diğer bir sorun da bu görünümün çok geniş olması, bu yüzden ikinci bir tane oluşturmam gerekiyor - lockview2.
Ve bana tablodan daha fazla sütun gösteriyor. Ve bana sütunların geri kalanını gösteren bir tane daha. Bu oldukça karmaşık, bu yüzden mümkün olduğu kadar basit bir şekilde sunmaya çalıştım.
Böylece Lockdemo adında bir tablo oluşturduk. Ve orada bir çizgi oluşturduk. Bu bizim örnek tablomuz. Ve size kilit örneklerini göstermek için bölümler oluşturacağız.
Yani bir satır, bir sütun. İlk kilit tipine ERİŞİM PAYLAŞIMI denir. Bu en az kısıtlayıcı engellemedir. Bu, pratik olarak diğer kilitlerle çakışmadığı anlamına gelir.
Açıkça bir kilit tanımlamak istiyorsak “tabloyu kilitle” komutunu çalıştırıyoruz. Ve açıkça engellenecektir, yani ACCESS SHARE modunda kilit tablosunu başlatıyoruz. Ve eğer PSQL'i arka planda çalıştırırsam, ilk oturumumdan ikinci oturuma bu şekilde başlarım. Yani burada ne yapacağım? Başka bir oturuma gidip "bana bu isteğin kilit görünümünü göster" diyorum. Ve burada bu tabloda AccessShareLock var. Ben de tam olarak bunu talep ettim. Ve bloğun atandığını söylüyor. Çok basit.
Ayrıca ikinci sütuna bakarsak orada hiçbir şey yok. Onlar boş.
Ve "SELECT" komutunu çalıştırırsam, bu AccessShareLock'u istemenin örtülü (açık) yoludur. Böylece tablomu serbest bırakıp sorguyu çalıştırıyorum ve sorgu birden fazla satır döndürüyor. Ve satırlardan birinde AccessShareLock'u görüyoruz. Böylece SELECT, tablodaki AccessShareLock'u çağırır. Ve neredeyse hiçbir şeyle çelişmiyor çünkü düşük seviyeli bir kilit.
Bir SELECT çalıştırırsam ve üç farklı tablom varsa ne olur? Daha önce yalnızca bir tablo çalıştırıyordum, şimdi üç tablo çalıştırıyorum: pg_class, pg_namespace ve pg_attribute.
Ve şimdi sorguya baktığımda üç tabloda 9 adet AccessShareLocks görüyorum. Neden? Üç tablo mavi renkle vurgulanmıştır: pg_attribute, pg_class, pg_namespace. Ancak bu tablolar aracılığıyla tanımlanan tüm dizinlerin de AccessShareLock'a sahip olduğunu da görebilirsiniz.
Ve bu, pratik olarak başkalarıyla çelişmeyen bir kilittir. Ve yaptığı tek şey, biz onu seçerken tabloyu sıfırlamamızı engellemektir. Mantıklı. Yani bir tabloyu seçersek o anda kayboluyor o zaman bu yanlıştır yani AccessShare, bize "Ben çalışırken bu masayı düşürmeyin" diyen düşük seviyeli bir kilittir.. Aslında yaptığı tek şey bu.
ROW PAYLAŞIMI - Bu kilit biraz farklı.
Bir örnek verelim. Her satırı ayrı ayrı kilitlemek için ROW PAYLAŞIM yöntemini SEÇİN. Böylece biz izlerken kimse onları silemez veya değiştiremez.
Peki PAYLAŞIM KİLİDİ ne işe yarar? SELECT için işlem kimliğinin 681 olduğunu görüyoruz. Ve bu ilginç. Burada ne oldu? Numarayı ilk kez “Kilit” alanında görüyoruz. İşlem kimliğini alıyoruz ve özel modda engellediğini söylüyor. Tek yaptığı, teknik olarak masanın bir yerinde kilitli bir satırım olduğunu söylüyor. Ama tam olarak nerede olduğunu söylemiyor. Buna biraz sonra daha ayrıntılı olarak bakacağız.
Burada kilidin bizim tarafımızdan kullanıldığını söylüyoruz.
Yani özel bir kilit açıkça onun özel olduğunu belirtir. Ayrıca bu tablodaki bir satırı silerseniz, görebileceğiniz gibi, bu olur.
SHARE EXCLUSIVE daha uzun bir kilittir.
Bu, kullanılacak (ANALYZE) analizör komutudur.
PAYLAŞIM KİLİDİ – paylaşım modunda açıkça kilitleyebilirsiniz.
Ayrıca benzersiz bir dizin oluşturabilirsiniz. Ve orada onların bir parçası olan PAYLAŞIM KİLİDİ'ni görebilirsiniz. Ve masayı kilitler ve üzerine bir PAYLAŞIM KİLİDİ koyar.
Varsayılan olarak, bir tablodaki PAYLAŞIM KİLİDİ, diğer kişilerin tabloyu okuyabileceği ancak hiç kimsenin tabloyu değiştiremeyeceği anlamına gelir. Benzersiz bir dizin oluşturduğunuzda olan da tam olarak budur.
Eş zamanlı benzersiz bir dizin oluşturursam farklı bir kilitleme türüne sahip olurum çünkü hatırladığınız gibi eşzamanlı dizinleri kullanmak kilitleme gereksinimini azaltır. Ve eğer normal bir kilit, normal bir indeks kullanırsam, o zaman tablo indeksi oluşturulurken bu indekse yazmayı engellemiş olurum. Eşzamanlı bir dizin kullanırsam farklı türde bir kilitleme kullanmam gerekir.
PAYLAŞIM SATIR ÖZEL - yine açıkça (açıkça) ayarlanabilir.
Veya bir kural oluşturabiliriz, yani kullanılacağı belirli bir durumu alabiliriz.
ÖZEL kilitleme, hiç kimsenin masayı değiştiremeyeceği anlamına gelir.
Burada farklı kilit türlerini görüyoruz.
Örneğin ACCESS EXCLUSIVE bir engelleme komutudur. Örneğin, eğer yaparsanız CLUSTER table, o zaman bu, kimsenin oraya yazamayacağı anlamına gelecektir. Ve sadece tabloyu değil aynı zamanda indeksleri de kilitler.
Bu, ACCESS EXCLUSIVE engellemesinin ikinci sayfasıdır ve tabloda tam olarak neyi engellediğini görüyoruz. Oldukça ilginç olan tek tek masa sıralarını kilitler.
Vermek istediğim temel bilgiler bu kadardı. Kilitlerden, işlem kimliklerinden, sanal işlem kimliklerinden, kalıcı işlem kimliklerinden bahsettik.
Şimdi bazı engelleme örnekleri üzerinden geçeceğiz. Bu en ilginç kısım. Çok ilginç vakalara bakacağız. Ve bu sunumdaki amacım, Postgres'in belirli şeyleri engellemeye çalışırken gerçekte ne yaptığını size daha iyi anlamanızı sağlamaktır. Parçaları engelleme konusunda çok iyi olduğunu düşünüyorum.
Bazı spesifik örneklere bakalım.
Tablolarla ve tablodaki bir satırla başlayacağız. Bir şey eklediğimde tabloda ExclusiveLock, İşlem Kimliği ve ExclusiveLock görüntüleniyor.
İki satır daha eklersem ne olur? Ve artık masamızın üç satırı var. Ve bir satır ekledim ve bunu çıktı olarak aldım. Ve iki satır daha eklersem bunun nesi tuhaf olur? Burada bir tuhaflık var çünkü bu tabloya üç satır ekledim ama kilit tablosunda hala iki satırım var. Ve bu aslında Postgres'in temel davranışıdır.
Birçok kişi, bir veritabanında 100 satırı kilitlerseniz 100 kilit girişi oluşturmanız gerekeceğini düşünür. Aynı anda 1 satırı engellersem, bu tür 000 sorguya ihtiyacım olacak. Ve eğer bloke etmek için bir milyona veya bir milyara ihtiyacım varsa. Ama eğer bunu yaparsak pek işe yaramayacaktır. Her satır için engelleme girişleri oluşturan bir sistem kullandıysanız, bunun karmaşık olduğunu görebilirsiniz. Çünkü taşabilecek bir kilit tablosunu hemen tanımlamanız gerekiyor ama Postgres bunu yapmıyor.
Ve bu slaytta gerçekten önemli olan şey, MVCC'nin içinde çalışan ve bireysel satırları kilitleyen başka bir sistemin olduğunu açıkça göstermesidir. Yani milyarlarca satırı kilitlediğinizde Postgres bir milyar ayrı kilitleme komutu oluşturmaz. Ve bunun üretkenlik üzerinde çok iyi bir etkisi var.
Peki ya bir güncelleme? Şimdi satırı güncelliyorum ve iki farklı işlemi aynı anda gerçekleştirdiğini görüyorsunuz. Aynı zamanda tabloyu da kilitledi ama aynı zamanda dizini de kilitledi. Ve bu tabloda benzersiz kısıtlamalar olduğundan dizini kilitlemesi gerekiyordu. Kimsenin bunu değiştirmediğinden emin olmak istiyoruz, bu yüzden onu engelliyoruz.
İki satırı güncellemek istersem ne olur? Onun da aynı şekilde davrandığını görüyoruz. İki kat daha fazla güncelleme yapıyoruz, ancak tam olarak aynı sayıda kilit satırı yapıyoruz.
Postgres'in bunu nasıl yaptığını merak ediyorsanız, Postgres'in değiştirdiği bu satırları dahili olarak nasıl işaretlediğini öğrenmek için MVCC hakkındaki konuşmalarımı dinlemeniz gerekecek. Ve Postgres'in bunu yapmanın bir yolu var, ancak bunu masa kilitleme seviyesinde yapmıyor, daha düşük ve daha verimli bir seviyede yapıyor.
Bir şeyi silmek istersem ne olur? Örneğin bir satırı silersem ve hala iki engelleme girişim varsa ve hepsini silmek istesem bile bunlar hala oradadır.
Ve örneğin, 1 satır eklemek ve ardından 000 satırı silmek veya eklemek istiyorum, ardından eklediğim veya değiştirdiğim satırlar buraya kaydedilmiyor. Serinin kendi içinde daha düşük bir seviyede yazılırlar. MVCC konuşmasında da bunu detaylı olarak anlattım. Ancak kilitleri analiz ederken, tablo düzeyinde kilitleme yaptığınızdan ve satırların burada nasıl kaydedildiğini görmediğinizden emin olmak çok önemlidir.
Açık engellemeye ne dersiniz?
Yenile'yi tıklarsam iki satırım kilitli olur. Ve eğer hepsini seçersem ve "her yerde güncelle"yi tıklarsam, o zaman hâlâ iki engelleme kaydım olur.
Her satır için ayrı kayıt oluşturmuyoruz. Çünkü o zaman üretkenlik düşer, çok fazla olabilir. Ve kendimizi hoş olmayan bir durumun içinde bulabiliriz.
Ve aynı şey, eğer paylaşırsak, hepsini 30 kez yapabiliriz.
Tablomuzu geri yüklüyoruz, her şeyi siliyoruz ve ardından tekrar bir satır ekliyoruz.
Postgres'te gördüğünüz çok iyi bilinen ve istenen bir diğer davranış ise güncelleme veya seçim yapabilmenizdir. Ve bunu aynı anda yapabilirsiniz. Ve seç güncellemeyi engellemez ve aynı şey ters yönde de olur. Okuyucuya yazarı engellememesini söylüyoruz, yazar da okuyucuyu engellemedi.
Size bunun bir örneğini göstereceğim. Şimdi bir seçim yapacağım. Daha sonra INSERT işlemini gerçekleştireceğiz. Ve sonra - 694'ü görebilirsiniz. Bu eklemeyi gerçekleştiren işlemin kimliğini görebilirsiniz. Ve bu şekilde çalışır.
Ve şimdi arka uç kimliğime bakarsam, şu anda 695 olduğunu görüyorum.
Ve masamda 695'in göründüğünü görebiliyorum.
Ve eğer burayı bu şekilde güncellersem, o zaman farklı bir durum elde ederim. Bu durumda, 695 özel bir kilittir ve güncelleme aynı davranışa sahiptir, ancak aralarında herhangi bir çakışma yoktur ki bu oldukça sıra dışıdır.
Üst kısımda ShareLock, altta ise ExclusiveLock olduğunu görebilirsiniz. Ve her iki işlem de işe yaradı.
Bunun nasıl olduğunu anlamak için MVCC'deki konuşmamı dinlemeniz gerekiyor. Ancak bu, bunu aynı anda yapabileceğinizi, yani aynı anda hem SEÇİM hem de GÜNCELLEME yapabileceğinizi gösteren bir örnektir.
Resetleyip bir işlem daha yapalım.
Aynı satırda iki güncellemeyi aynı anda çalıştırmayı denerseniz engellenir. Ve unutmayın, okur yazarı engellemez, yazar da okuyucuyu engellemez ama bir yazar diğer yazarı engeller dedim. Yani iki kişinin aynı anda aynı satırı güncellemesini sağlayamayız. Bir tanesi bitene kadar beklemeniz gerekiyor.
Bunu göstermek için Lockdemo tablosuna bakacağım. Ve bir satıra bakacağız. İşlem başına 698.
Bunu 2'ye güncelledik. 699 ilk güncellemedir. Başarılı oldu veya bekleyen bir işlemde ve onaylamamızı veya iptal etmemizi bekliyor.
Ama başka bir şeye bakın; 2/51 bizim ilk işlemimiz, ilk seansımız. 3/112 üstten gelen ve bu değeri 3'e çıkaran ikinci istek. Ve dikkat ederseniz en üstteki kendini kilitledi, yani 699. Ancak 3/112 kilidi vermedi. Lock_mode sütunu ne beklediğini söylüyor. 699 bekleniyor. Ve 699'un nerede olduğuna bakarsanız daha yüksek olduğunu görürsünüz. Peki ilk oturumda ne yapıldı? Kendi işlem kimliğine özel bir kilit oluşturdu. Postgres bunu böyle yapıyor. Kendi işlem kimliğini engeller. Birisinin onaylamasını veya iptal etmesini beklemek istiyorsanız, bekleyen bir işlem varken beklemeniz gerekir. İşte bu yüzden garip bir çizgi görebiliyoruz.
Tekrar bakalım. Sol tarafta işleme kimliğimizi görüyoruz. İkinci sütunda sanal işlem kimliğimizi, üçüncü sütunda ise lock_type'ı görüyoruz. Bu ne anlama gelir? Esasen söylediği şey, işlem kimliğini engellediğidir. Ancak alttaki tüm satırların ilişki söylediğine dikkat edin. Ve böylece masanın üzerinde iki tür kilit var. Bir ilişki kilidi var. Ve sonra, kendi başınıza bloke ettiğiniz işlem kimliği engelleme var, bu tam olarak ilk satırda veya en altta olan, işlem kimliğinin olduğu yerde, 699'un işlemini bitirmesini beklediğimiz yer.
Bakalım burada ne olacak. Ve burada iki şey aynı anda oluyor. İlk satırda kendi kendini kilitleyen bir işlem kimliği kilidine bakıyorsunuz. Ve insanları bekletmek için kendini engelliyor.
6. satıra bakarsanız ilk satırla aynı giriştir. Bu nedenle 699 numaralı işlem engellendi. 700 ayrıca kendiliğinden kilitlenir. Daha sonra alt satırda 699'un çalışmasını bitirmesini beklediğimizi göreceksiniz.
Ve lock_type'da sayıları görüyorsunuz.
0/10 olduğunu görebilirsiniz. Bu da sayfa numarası ve aynı zamanda bu satırın uzaklığıdır.
Ve güncelleme yaptığımızda 0/11 olduğunu görüyorsunuz.
Ama gerçekte 0/10 çünkü bu operasyon için bir bekleme var. Onaylanmasını beklediğim serinin bu olduğunu görme fırsatımız var.
Onayladığımızda ve taahhüt tuşuna bastığımızda ve güncelleme bittiğinde tekrar elde ettiğimiz şey budur. İşlem 700 tek kilittir, commit edildiği için başkasını beklemez. Sadece işlemin tamamlanmasını bekler. 699 bittiğinde artık hiçbir şey beklemiyoruz. Ve şimdi işlem 700 her şeyin yolunda olduğunu, izin verilen tüm masalarda ihtiyaç duyduğu tüm kilitlere sahip olduğunu söylüyor.
Ve tüm bunları daha da karmaşık hale getirmek için, bu sefer bize hiyerarşi sağlayacak başka bir görünüm yaratıyoruz. Bu isteği anlamanızı beklemiyorum. Ancak bu bize neler olup bittiğine dair daha net bir görüş verecektir.
Bu, başka bir bölümü de olan özyinelemeli bir görünümdür. Ve sonra her şeyi yeniden bir araya getiriyor. Bunu kullanalım.
Peki ya üç eşzamanlı güncelleme yaparsak ve satırın artık üç olduğunu söylersek. Ve 3'ü 4'e değiştireceğiz.
Ve burada 4'ü görüyoruz. Ve işlem ID'si 702.
Sonra 4'ü 5'e, 5'i 6'ya, 6'yı da 7'ye çevireceğim. Ve bu işlemin bitmesini bekleyecek birkaç kişiyi sıraya koyacağım.
Ve her şey netleşiyor. İlk satır nedir? Bu 702'dir. Bu, başlangıçta bu değeri ayarlayan işlem kimliğidir. Verildi sütunumda ne yazıyor? işaretlerim var f. Bunlar, işlem ID 5'nin bitmesini beklediğimiz için (6, 7, 702) onaylanamayan güncellemelerimdir. Orada işlem kimliği engellememiz var. Bu da 5 adet işlemsel kimlik kilidiyle sonuçlanır.
Ve 704'e, 705'e bakarsanız henüz orada hiçbir şey yazılmamış çünkü henüz ne olup bittiğini bilmiyorlar. Ne olup bittiğine dair hiçbir fikirleri olmadığını yazıyorlar. Ve sadece uyuyacaklar çünkü birisinin bitirmesini ve sıra değiştirme fırsatı olduğunda uyanmasını bekliyorlar.
Görünüşe göre bu. Hepsinin 12. sırayı bekledikleri belli.
Burada şunu gördük. İşte 0/12.
Yani ilk işlem onaylandıktan sonra hiyerarşinin nasıl çalıştığını burada görebilirsiniz. Ve şimdi her şey netleşiyor. Hepsi temiz oluyor. Ve aslında hala bekliyorlar.
İşte neler oluyor. 702 taahhüt ediyor. Ve şimdi 703 bu satır kilidini alıyor ve ardından 704, 703'ün taahhüt etmesini beklemeye başlıyor. Ve 705 de bunu bekliyor. Ve tüm bunlar bittiğinde kendilerini temizlerler. Herkesin sıraya girdiğini de belirtmek isterim. Ve bu, trafik sıkışıklığında herkesin ilk arabayı beklediği duruma çok benzer. İlk araba duruyor ve herkes uzun bir sıraya giriyor. Daha sonra hareket eder, ardından bir sonraki araba ileri doğru ilerleyebilir ve bloğunu alabilir, vb.
Ve eğer bu size yeterince karmaşık gelmediyse, o zaman şimdi sizinle çıkmazlar hakkında konuşacağız. Hanginizin onlarla karşılaştığını bilmiyorum. Bu, veritabanı sistemlerinde oldukça yaygın bir sorundur. Ancak kilitlenmeler, bir oturumun başka bir oturumun bir şey yapmasını beklediği zamandır. Ve şu anda başka bir seans bir şeyler yapmak için ilk seansı bekliyor.
Ve örneğin, Ivan "Bana bir şey ver" derse ve ben de "Hayır, onu yalnızca bana başka bir şey verirsen veririm" dersem. O da “Hayır, sen bana vermezsen ben de sana vermem” diyor. Ve çıkmaz bir duruma düşeriz. Ivan'ın bunu yapmayacağından eminim, ancak bir şey almak isteyen iki kişimizin, diğer kişi onlara istediğini verene kadar onu vermeye hazır olmadıklarının anlamını anlıyorsunuz. Ve hiçbir çözüm yok.
Ve esasen veritabanınızın bunu algılaması gerekiyor. Daha sonra oturumlardan birini silmeniz veya kapatmanız gerekir, aksi takdirde sonsuza kadar orada kalacaklar. Ve bunu veritabanlarında görüyoruz, işletim sistemlerinde görüyoruz. Ve paralel süreçlerin olduğu her yerde bu gerçekleşebilir.
Ve şimdi iki kilitlenme kuracağız. 50 ve 80'i koyacağız. İlk satıra 50'den 50'ye güncelleme yapacağım. 710 işlem numarasını alacağım.
Daha sonra 80'i 81'e, 50'yi de 51'e değiştireceğim.
Ve işte böyle görünecek. Ve böylece 710'un bir satırı engellendi ve 711 onay bekliyor. Güncelleme yaptığımızda bunu gördük. 710 serimizin sahibidir. Ve 711, 710'un işlemi tamamlamasını bekler.
Hatta kilitlenmelerin hangi satırda meydana geldiğini bile söylüyor. İşte iş burada tuhaflaşmaya başlıyor.
Şimdi 80'i 80'e güncelliyoruz.
Ve çıkmazların başladığı yer burasıdır. 710, 711'den cevap bekliyor, 711 de 710'u bekliyor. Ve bunun sonu pek iyi olmayacak. Ve bundan çıkış yolu yok. Ve birbirlerinden bir yanıt bekleyecekler.
Ve her şeyi geciktirmeye başlayacak. Ve biz bunu istemiyoruz.
Ve Postgres'in bunun ne zaman olduğunu fark etmenin yolları var. Ve bu olduğunda, bu hatayı alıyorsunuz. Buradan da şunu açıkça görüyoruz ki falanca süreç başka bir süreçten yani 711 süreci tarafından engellenen bir SHARE LOCK bekliyor. Ve o işlem falanca işlem ID'sine PAYLAŞIM KİLİDİ verilmesini bekliyordu ve falanca işlem tarafından bloke edildi. Dolayısıyla burada bir kilitlenme durumu var.
Üç yönlü kilitlenmeler var mı? Bu mümkün mü? Evet.
Bu sayıları bir tabloya giriyoruz. 40'ı 40'a değiştiriyoruz, engelleme yapıyoruz.
60'ı 61'e, 80'i 81'e değiştiriyoruz.
Sonra 80'i değiştiriyoruz ve sonra bum!
Ve 714 şimdi 715'i bekliyor. 716'cı da 715'inciyi bekliyor. Ve bu konuda hiçbir şey yapılamaz.
Burada artık iki kişi yok, burada zaten üç kişi var. Ben senden bir şey istiyorum, bu üçüncü bir kişiden bir şey istiyor, üçüncü kişi de benden bir şey istiyor. Ve sonunda üçlü bir bekleyişle karşı karşıya kalırız çünkü hepimiz diğer kişinin yapması gerekeni tamamlamasını bekleriz.
Ve Postgres bunun hangi satırda gerçekleştiğini biliyor. Ve böylece size üç girişin birbirini engellemesiyle ilgili bir sorununuz olduğunu gösteren aşağıdaki mesajı verecektir. Ve burada hiçbir kısıtlama yok. Bu, 20 girişin birbirini bloke ettiği durum olabilir.
Bir sonraki sorun serileştirilebilir.
Özel serileştirilebilir kilit varsa.
Ve 719'a dönüyoruz. Çıktısı oldukça normal.
Ve işlemi serileştirilebilir hale getirmek için tıklayabilirsiniz.
Artık farklı türde bir SA kilidine sahip olduğunuzun farkına varırsınız; bu, serileştirilebilir anlamına gelir.
Ve böylece SARieadLock adında yeni bir kilit tipimiz var, bu bir seri kilittir ve serilere girmenizi sağlar.
Ayrıca benzersiz dizinler de ekleyebilirsiniz.
Bu tabloda benzersiz dizinlerimiz var.
Yani buraya 2 sayısını koyarsam 2 olur. Ama en tepeye başka bir 2 koyarım. Ve 721'in özel bir kilidi olduğunu görebilirsiniz. Ancak şimdi 722, 721'in işlemini tamamlamasını bekliyor çünkü 2'e ne olacağını bilene kadar 721'yi ekleyemez.
Ve eğer alt işlem yaparsak.
Burada 723 var.
Ve eğer noktayı kaydedip güncellersek, yeni bir işlem kimliği elde ederiz. Bu da bilmeniz gereken başka bir davranış modelidir. Bunu döndürürsek işlem kimliği kaybolur. 724 yaprak. Ama şimdi 725'imiz var.
Peki burada ne yapmaya çalışıyorum? Size bulabileceğiniz alışılmadık kilit örneklerini göstermeye çalışıyorum: ister serileştirilebilir kilitler, ister SAVEPOINT olsun, bunlar kilit tablosunda görünecek farklı kilit türleridir.
Bu, pg_advisory_lock'a sahip açık (açık) kilitlerin oluşturulmasıdır.
Ve engelleme türünün tavsiye niteliğinde listelendiğini görüyorsunuz. Burada da kırmızıyla "tavsiye" yazıyor. Ve pg_advisory_unlock ile aynı anda bu şekilde engelleyebilirsiniz.
Ve sonuç olarak size akıllara durgunluk veren bir şey daha göstermek istiyorum. Başka bir görünüm oluşturacağım. Ancak pg_locks tablosunu pg_stat_activity tablosuyla birleştireceğim. Peki bunu neden yapmak istiyorum? Çünkü bu, tüm mevcut oturumlara bakıp tam olarak ne tür kilitleri beklediklerini görmeme olanak tanıyacak. Kilit tablosuyla sorgu tablosunu bir araya getirdiğimizde bu oldukça ilginç oluyor.
Ve burada pg_stat_view'i oluşturuyoruz.
Ve satırı tek tek güncelliyoruz. Ve burada 724'ü görüyoruz. Sonra sıramızı üçe güncelliyoruz. Peki şimdi burada ne görüyorsun? Bunlar isteklerdir, yani sol sütunda listelenen isteklerin tam listesini görürsünüz. Ve sağ tarafta tıkanıklıkları ve bunların yarattıklarını görebilirsiniz. Ve her seferinde her oturuma dönüp katılmanız gerekip gerekmediğini görmek zorunda kalmamanız için bu sizin için daha net olabilir. Bunu bizim için yapıyorlar.
Çok kullanışlı olan bir diğer özellik ise pg_blocking_pids. Muhtemelen onu hiç duymamışsınızdır. O ne yapıyor? Bu oturum 11740'a hangi belirli işlem kimliklerini beklediğini söylememize olanak tanır. Ve 11740'ın 724'ü beklediğini görüyorsunuz. Ve 724 en üstte. Ve 11306 işlem kimliğinizdir. Temel olarak, bu işlev kilit tablonuzdan geçer. Biraz karmaşık olduğunu biliyorum ama anlamayı başarıyorsun. Temel olarak bu işlev, bu kilit tablosundan geçer ve bu işlem kimliğinin, beklediği kilitlerin nerede verildiğini bulmaya çalışır. Ayrıca kilidi bekleyen sürecin hangi süreç kimliğine sahip olduğunu bulmaya çalışır. Böylece bu işlevi çalıştırabilirsiniz pg_blocking_pids.
Ve bu çok faydalı olabilir. Bunu yalnızca 9.6 sürümünde ekledik, yani bu özellik yalnızca 5 yaşında ama çok ama çok kullanışlı. Aynı durum ikinci istek için de geçerlidir. Tam olarak görmemiz gerekeni gösteriyor.
Seninle konuşmak istediğim şey buydu. Ve beklediğim gibi çok fazla slayt olduğu için tüm zamanımızı harcadık. Ve slaytlar indirilmeye hazır. Burada olduğunuz için size teşekkür etmek istiyorum. Konferansın geri kalanından keyif alacağınıza eminim, çok teşekkür ederim!
Sorular:
Örneğin, satırları güncellemeye çalışıyorum ve ikinci oturum tablonun tamamını silmeye çalışıyorsa. Anladığım kadarıyla niyet kilidi gibi bir şey olması lazım. Postgres'te böyle bir şey var mı?
En başa dönelim. Herhangi bir şey yaptığınızda, örneğin bir SELECT yaptığınızda, bir AccessShareLock verdiğimizi hatırlarsınız. Bu da masanın düşmesini engeller. Yani, örneğin bir tablodaki bir satırı güncellemek veya bir satırı silmek istiyorsanız, bu durumda AccessShareLock'u tüm tablonun üzerinde ve satırın üzerinde tuttuğunuz için birisi aynı anda tablonun tamamını silemez. Ve işiniz bittiğinde onu silebilir. Ama orada bir şeyi doğrudan değiştirdiğinizde bunu yapamayacaklar.
Hadi bir daha yapalım. Silme örneğine geçelim. Ve tüm masanın üzerindeki sırada özel bir kilidin nasıl olduğunu görüyorsunuz.
Bu, kilide özel gibi görünecek, değil mi?
Evet öyle görünüyor. Neden bahsettiğini anlıyorum. Eğer bir SELECT yaparsam, o zaman bir ShareExclusive'im olur ve sonra onu Row Exclusive yaparsam, bu bir sorun olur mu diyorsunuz? Ancak şaşırtıcı bir şekilde bu bir sorun teşkil etmiyor. Bu kilit derecesini arttırmak gibi görünüyor ama aslında silinmeyi önleyen bir kilidim var. Ve şimdi bu kilidi daha güçlü hale getirdiğimde yine de silinmeyi engelliyor. Yani yukarı çıkacak gibi değilim. Yani daha düşük seviyedeyken de olmasını engelledi, yani seviyesini yükselttiğimde yine de tablonun silinmesini engelliyor.
Neden bahsettiğini anlıyorum. Burada daha güçlü bir kilit açmak için bir kilitten vazgeçmeye çalıştığınız bir kilit yükseltme durumu yok. Burada sadece bu önlemeyi genel anlamda artırıyor, böylece herhangi bir çatışmaya neden olmuyor. Ama bu iyi bir soru. Bunu sorduğunuz için çok teşekkür ederim!
Çok sayıda oturumumuz, çok sayıda kullanıcımız olduğunda kilitlenme durumuyla karşılaşmamak için ne yapmamız gerekiyor?
Postgres kilitlenme durumlarını otomatik olarak fark eder. Ve oturumlardan birini otomatik olarak silecektir. Ölü engellemeyi önlemenin tek yolu insanları aynı sırayla engellemektir. Yani uygulamanıza baktığınızda çoğu zaman kilitlenmelerin sebebini görüyorsunuz... İki farklı şeyi engellemek istediğimi düşünelim. Bir uygulama tablo 1'i kilitler, başka bir uygulama 2'yi ve ardından tablo 1'i kilitler. Kilitlenmeleri önlemenin en kolay yolu uygulamanıza bakmak ve kilitlemenin tüm uygulamalarda aynı sırada gerçekleştiğinden emin olmaya çalışmaktır. Ve bu genellikle sorunların %80'ini ortadan kaldırır çünkü bu uygulamaları her türden insan yazmaktadır. Ve bunları aynı sırayla engellerseniz kilitlenme durumuyla karşılaşmazsınız.
Performansınız için çok teşekkür ederiz! Vakum doluluğundan bahsettiniz ve eğer doğru anladıysam vakum dolusu ayrı depodaki kayıtların sırasını bozuyor, dolayısıyla mevcut kayıtları değiştirmeden tutuyorlar. Vakum dolu neden özel kilit erişimini alıyor ve neden yazma işlemleriyle çakışıyor?
Bu iyi bir soru. Sebebi ise vakumun masayı tam almasıdır. Ve aslında tablonun yeni bir versiyonunu yaratıyoruz. Ve masa yeni olacak. Bunun tablonun tamamen yeni bir versiyonu olacağı ortaya çıktı. Sorun şu ki, bunu yaptığımızda insanların okumasını istemiyoruz çünkü onların yeni tabloyu görmelerine ihtiyacımız var. Bu da önceki soruyla bağlantılı. Eğer aynı anda okuyabilseydik, onu taşıyıp insanları yeni bir masaya yönlendiremezdik. Herkesin bu tabloyu okumayı bitirmesini beklememiz gerekir ve dolayısıyla bu aslında kilitlere özel bir durumdur.
Sadece baştan kilitlediğimizi söylüyoruz çünkü biliyoruz ki en sonunda herkesi yeni kopyaya taşımak için özel bir kilide ihtiyacımız olacak. Yani bunu potansiyel olarak çözebiliriz. Ve bunu eş zamanlı indeksleme ile bu şekilde yapıyoruz. Ancak bunu yapmak çok daha zordur. Ve bu, özel kilitle ilgili önceki sorunuzla büyük ölçüde ilgilidir.
Postgres'e kilitleme zaman aşımı eklemek mümkün mü? Oracle'da örneğin "güncellemeyi seç" yazıp güncellemeden önce 50 saniye bekleyebilirim. Uygulama açısından iyiydi. Ancak Postgres'te ya bunu hemen yapıp hiç beklememem gerekiyor ya da bir süre beklemem gerekiyor.
Evet, kilitlerinizde, kilitlerinizde bir zaman aşımı seçebilirsiniz. Ayrıca, kilidi hemen alamadığınız takdirde, hiçbir şekilde olmaz komutunu da verebilirsiniz. Bu nedenle, ya bir kilitleme zaman aşımı ya da bunu yapmanıza izin verecek başka bir şey. Bu sözdizimsel düzeyde yapılmaz. Bu, sunucuda bir değişken olarak yapılır. Bazen bu kullanılamaz.
75. slaytı açabilir misiniz?
Evet.
Ve sorum şu. Neden her iki güncelleme işlemi de 703 bekliyor?
Ve bu harika bir soru. Bu arada Postgres'in bunu neden yaptığını anlamıyorum. Ancak 703 yaratıldığında 702'yi bekliyordu. Ve 704 ve 705 ortaya çıktığında ne beklediklerini bilmiyorlar gibi görünüyor çünkü henüz orada hiçbir şey yok. Ve Postgres bunu şu şekilde yapıyor: Kilit alamadığınızda, "Seni işlemenin ne anlamı var?" diye yazıyor çünkü zaten birini bekliyorsunuz. Yani onun havada kalmasına izin vereceğiz, o onu hiç güncellemeyecek. Peki burada ne oldu? 702 işlemi tamamlayıp 703 kilidini alır almaz sistem geri döndü. Ve şimdi bekleyen iki kişimiz olduğunu söyledi. Daha sonra bunları birlikte güncelleyelim. Ve her ikisinin de beklediğini belirtelim.
Postgres'in bunu neden yaptığını bilmiyorum. Ama f… diye bir sorun var. Bana öyle geliyor ki bu Rusça'da bir terim değil. Bu, kaleyi bekleyen 20 yetkili olsa bile herkesin bir kaleyi beklediği zamandır. Ve birden hepsi aynı anda uyanır. Ve herkes tepki vermeye çalışıyor. Ama sistem öyle yapıyor ki herkes 703'ü bekliyor. Çünkü hepsi bekliyor, biz de hemen hepsini sıraya koyacağız. Ve bundan sonra oluşturulan başka bir yeni istek ortaya çıkarsa, örneğin 707, o zaman tekrar boşluk olacaktır.
Ve bana öyle geliyor ki bu aşamada 702'nin 703'ü beklediğini ve bundan sonra gelenlerin bu alana hiçbir girişi olmayacağını söyleyebilmemiz için yapılıyor bu. Ancak ilk garson ayrılır ayrılmaz, güncellemeden önce o anda bekleyenlerin hepsi aynı jetonu alır. Ve bence bu, düzgün bir şekilde sıralanmaları için sırayla işleyebilmemiz için yapıldığını düşünüyorum.
Buna her zaman oldukça tuhaf bir fenomen olarak baktım. Çünkü burada örneğin onları hiç listelemiyoruz. Ama bana öyle geliyor ki, her yeni kilit verdiğimizde, bekleme sürecindeki herkese bakıyoruz. Daha sonra hepsini sıralıyoruz. Ve sonra gelen herhangi bir yeni kişi ancak bir sonraki kişinin işlemi bitince kuyruğa girer. Çok iyi bir soru. Sorunuz için çok teşekkür ederiz!
Bana öyle geliyor ki 705'in 704'ü beklemesi çok daha mantıklı.
Ancak buradaki sorun şudur. Teknik olarak birini veya diğerini uyandırabilirsiniz. Ve böylece birini ya da diğerini uyandıracağız. Peki sistemde ne oluyor? En üstteki 703'ün kendi işlem kimliğini nasıl engellediğini görebilirsiniz. Postgres bu şekilde çalışır. Ve 703 kendi işlem kimliği tarafından engelleniyor, yani birisi beklemek isterse 703'ü bekleyecektir. Ve özünde 703 tamamlanır. Ve ancak tamamlandıktan sonra süreçlerden biri uyanır. Ve bu sürecin tam olarak ne olacağını bilmiyoruz. Daha sonra her şeyi yavaş yavaş işliyoruz. Ancak hangi sürecin önce uyandığı belli değil çünkü bu süreçlerden herhangi biri olabilir. Esasen, artık bu süreçlerden herhangi birini uyandırabileceğimizi söyleyen bir zamanlayıcımız vardı. Rastgele birini seçiyoruz. Yani her ikisinin de not edilmesi gerekiyor çünkü ikisini de uyandırabiliriz.
Ve sorun şu ki, CP-sonsuzluğuna sahibiz. Ve bu nedenle, daha sonra uyanmamız oldukça muhtemeldir. Ve örneğin, daha sonrakini uyandırırsak, bloğu yeni alan kişiyi bekleyeceğiz, böylece tam olarak kimin ilk önce uyanacağını belirleyemiyoruz. Biz sadece böyle bir durum yaratırız ve sistem onları rastgele bir sırayla uyandırır.
Var . Bakın bunlar da ilginç ve faydalı. Konu elbette son derece karmaşık. Çok teşekkür ederim Bruce!
Kaynak: habr.com
