(ts) Yandex.Görseller
Tüm karakterler hayal ürünüdür, markalar sahiplerine aittir, benzerlikler rastgeledir ve genel olarak bu benim “sübjektif değer yargımdır, lütfen kapıyı kırmayın…”.
Bilgi sistemlerini mantıksal olarak bir veritabanına bir DBMS'den diğerine aktarma konusunda önemli bir deneyime sahibiz. 1236 Kasım 16.11.2016 tarih ve XNUMX sayılı hükümet kararnamesi bağlamında bu genellikle Oracle'dan Postgresql'e bir aktarımdır. Süreci mümkün olduğunca verimli ve ağrısız bir şekilde nasıl organize edebileceğinizi ayrı ayrı anlatabiliriz; bugün küme kullanmanın özelliklerinden ve prosedürler ve işlevler açısından karmaşık mantığa sahip, yüksek yüklü dağıtık sistemler oluştururken ne gibi sorunlarla karşılaşılabileceğinden bahsedeceğiz.
Spoiler – evet, kapak, RAC ve pg multimaster çok farklı çözümlerdir.
Diyelim ki tüm mantığı zaten plsql'den pgsql'ye aktardınız. Regresyon testleriniz de oldukça iyi, şimdi tabii ki ölçeklendirmeyi düşünüyorsunuz, çünkü... Yük testleri, özellikle projeye orijinal olarak dahil edilen donanımlarda, o çok farklı DBMS için sizi pek mutlu etmiyor. Diyelim ki yerli satıcı "Postgres Professional"dan "multimaster" adlı bir seçeneğe sahip, yalnızca "Postgres Pro Enterprise"ın "maksimum" sürümünde mevcut olan bir çözüm buldunuz ve açıklamaya göre - bu neye çok benziyor ihtiyacın var ve ilk yüzeysel çalışmayla birlikte şu düşünce aklıma gelecek: “Ah! RAC yerine bu kadar! Ve hatta anavatanımızda teknik bir boru hattı olsa bile!”
Ancak sevinmek için acele etmeyin ve ayrıca bu nüansları neden bilmeniz gerektiğini açıklayacağız, çünkü... Ürün belgelerini iyice okuduktan sonra bile bunları tahmin etmek zordur. DBMS sürümlerini doğrudan üretim sahasında sıklıkla güncellemeye hazır olup olmadığınızı değerlendirin, çünkü Bazı kusurlar endüstriyel kullanıma uygun değildir ve test sırasında tespit edilmesi zordur.
Üreticinin web sitesindeki "multimaster" - "sınırlamalar" bölümünü dikkatlice okuyarak başlayın.
Karşılaşabileceğiniz ilk şey, sözde işlemlerin nasıl yürüdüğünün özellikleridir. "iki fazlı" mod ve bazen prosedürünüzün tüm mantığını yeniden yazmak dışında bunu düzeltmenin bir yolu yoktur. İşte basit bir örnek:
create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
update test1
set id1 =
case id1
when 1
then 2
else id1 - sign(2 - 1)
end
where id1 between 1 and 2;Bir hata oluşur:
ОШИБКА: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.Daha sonra 10.5, 10.6 sürümlerinde çıkmaz kilitle uzun süre mücadele edebilirsiniz ve kümenin tüm özünü öldüren bilinen tek çözüm, kümeden "sorunlu" tabloları kaldırmaktır, yani. make_table_local yapın, ancak bu en azından çalışmasına izin verecek ve işlem taahhütleri için bekleme beklemeleri nedeniyle her şeyi beklemeye almayacaktır. Veya 11.2 sürümüne bir güncelleme yükleyin; bu yardımcı olabilir, ancak belki de olmayabilir, kontrol etmeyi unutmayın.
Bazı versiyonlarda daha da gizemli bir kilit elde edebilirsiniz:
username= mtm и backend_type = background workerVe bu durumda yalnızca DBMS sürümünü 11.2 ve üstüne güncellemek size yardımcı olacaktır, belki de yardımcı olmayacaktır.
Dizinlerle yapılan bazı işlemler hatalara yol açabilir; bu da sorunun Çift Yönlü Çoğaltma'da olduğunu açıkça gösterir; MTM günlüklerinde doğrudan BDR'yi göreceksiniz. Gerçekten 2. Çeyrek mi? Hayır... multimaster aldık, bu sadece bir tesadüf, teknolojinin adı.
[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 “Çoklu yönetici uzantısı, veri çoğaltmayı tamamen otomatik bir şekilde gerçekleştirir” güvencelerine rağmen geçici tablolar kullanıyorsanız. Kümedeki herhangi bir düğümde aynı anda yazma işlemlerini gerçekleştirebilir ve geçici tablolarla çalışabilirsiniz."
O zaman aslında çoğaltmanın prosedürde kullanılan tüm tablolarda çalışmadığını göreceksiniz, eğer kod geçici bir tablonun oluşturulmasını içeriyorsa ve multimaster.remote_functions'ı kullanmak bile yardımcı olmazsa, mantığınızı güncellemeniz veya yeniden yazmanız gerekecektir. prosedür. Postgres Pro Enterprise v 10.5'te multimaster ve pg_pathman adlı iki uzantıyı aynı anda kullanmanız gerekiyorsa, bunu şu basit örnekle kontrol edin:
CREATE TABLE measurement (
city_id int not null,
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);
CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);DBMS düğümlerindeki günlüklerde aşağıdaki hatalar görünmeye başlar:
…
PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА: find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction (6919) local xid=7017 to coordinator 1
Bu hataların ne olduğunu teknik destekte öğrenebilirsiniz, satın almanız boşuna değildir.
Ne yapalım? Sağ! "Postgres Pro Enterprise" v 11.2'ye yükseltme
Ayrı olarak, çoğaltılmış bir veritabanının nesnesi olan dizinin küme boyunca uçtan uca bir değere sahip olmadığını, her dizinin her düğüm için yerel olduğunu ve benzersiz kısıtlamalara sahip alanlarınız varsa ve diziyi kullandığınızı bilmeniz gerekir, o zaman yalnızca kümedeki düğüm numarasına eşdeğer bir artış yapabilirsiniz çünkü Kümede mümkün olduğu kadar çok düğüm, dizi ve int beklediğinizden daha hızlı büyüyecektir. Üründeki sıra ile çalışmayı kolaylaştırmak için, tüm düğümlerdeki her sıra için gerekli artışları yapacak olan alter_sequences işlevini bile bulacaksınız, ancak işlevin tüm sürümlerde çalışmayacağına hazırlıklı olun. Tabii ki, github'daki kodu temel alarak veya doğrudan DBMS'de kendiniz düzelterek kendiniz yazabilirsiniz. Bu durumda seribigserial türündeki alanlar daha doğru çalışacaktır ancak bunları kullanmak için büyük olasılıkla prosedürlerinizin ve işlevlerinizin kodunu yeniden yazmanız gerekecektir. Belki birileri monotonic_sequences fonksiyonunu faydalı bulacaktır.
Postgres Pro Enterprise'ın 11.2 sürümünden önce, çoğaltma yalnızca benzersiz birincil anahtarlar varsa çalışır; geliştirme sırasında bunu dikkate alın.
Ayrı olarak, npgsql'nin küme çözümünde nasıl çalıştığına dair özelliklere değinmek istiyorum; bu sorunlar tek bir düğümde ortaya çıkmaz, ancak bir multimaster'da oldukça mevcuttur.
Bazı sürümlerde bir hatayla karşılaşabilirsiniz:
Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Ne yapılabilir? Sadece bazı versiyonları kullanmamanız gerekiyor. Bunları bilmeniz gerekiyor çünkü... Hata birden fazla sürümde karşımıza çıkıyor ve ilk düzeltmesinden sonra bile daha sonra karşılaşabilirsiniz. Ayrıca buna hazırlıklı olmanız gerekir ve üretici tarafından düzeltilen tüm tanımlanmış DBMS hatalarını ayrı regresyon testleriyle kapsamak daha iyidir. Yani güvenin ama doğrulayın.
Uygulama npgsql kullanıyor ve hepsinin aynı olduğunu düşünerek düğümler arasında geçiş yapıyorsa bir hata alabilirsiniz:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...Bağlama devam ettiği için bu hata ortaya çıkacak
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) tüm bağlantılar için uygulama başlangıcında kompozit türler. Sonuç olarak, bir düğümden bir tanımlayıcı alıyoruz ve başka bir düğümden istekte bulunurken eşleşmiyor, bunun sonucunda bir hata döndürülüyor, yani. Bazı uygulamalarda, uygulama tarafında ek yeniden yazmalar olmadan (bunu yapmayı başarırsanız) bir kümedeki bileşik türlerle şeffaf bir şekilde çalışmak mümkün olmayacaktır.
Hepimizin bildiği gibi, çalışma sırasında teşhis ve operasyonel önlemler için kümenin durumunun genel bir değerlendirmesi çok önemlidir; üründe hayatınızı kolaylaştıracak bazı işlevler bulabilirsiniz, ancak bazen bunlar, olduğundan tamamen farklı bir şey verebilir. siz ve hatta üreticinin kendisi onlardan bekliyorsunuz.
Örneğin:
select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")Peki multimaster işleminin açıklamasına göre AllNodes=2 sayısına karşılık gelmesi gerektiği halde LiveNodes alanı neden her yerde 3 sayısını içeriyor? Cevap: DBMS sürümünü güncellemeniz gerekiyor.
Ve tüm düğümlerin günlüklerini toplamaya hazır olun çünkü... genellikle "hata başka bir düğümün günlüğündedir" ifadesini görürsünüz. Teknik destek, tanımladığınız tüm kusurları kabul edecek ve bir sonraki sürümün hazır olduğu konusunda sizi bilgilendirecektir; bu sürümün bazen hizmet durdurulmuşken, bazen de uzun bir süre (DBMS'nizin boyutuna bağlı olarak) kurulması gerekecek. Operasyonel sorunların satıcıyı büyük ölçüde rahatsız edeceğini ve tespit edilen kusurlar nedeniyle güncellemenin satıcı temsilcilerinin katılımıyla gerçekleştirileceğini veya daha doğrusu satıcı temsilcilerini dahil etmenize bile gerek kalmayacağını ummamalısınız. sonunda üretimde yedekleme olmadan parçalara ayrılmış bir kümeyle karşılaşabilirsiniz.
Aslında ticari bir ürünün lisansında üretici dürüstçe uyarıyor: "Bu yazılım "olduğu gibi" sağlanmaktadır ve Postgres Professional Limited Company'nin bakım, destek, güncelleme, uzantı veya değişiklik sağlama yükümlülüğü yoktur."
Hangi üründen bahsettiğimizi henüz tahmin etmediyseniz tüm bu deneyim, Postgres Pro Enterprise veritabanının bir yıl boyunca çalışması sonucunda elde edildi. Kendi sonucunu çıkarabilirsiniz, mantarlar o kadar nemli ki büyüyor.
Ancak zamanında yapılırsa ve ortaya çıkan sorunlar derhal ortadan kaldırılırsa bu o kadar da kötü olmazdı.
Ancak bu tam olarak gerçekleşmez. Görünüşe göre üreticinin tespit edilen hataları derhal ortadan kaldırmak için yeterli kaynağı yok.
Ankete sadece kayıtlı kullanıcılar katılabilir. Lütfen.
Yabancı/tescilli bir DBMS'den ücretsiz/yerli bir DBMS'ye geçiş konusunda deneyiminiz var mı?
21,3%Evet, olumlu10
10,6%Evet, negatif5
21,3%Hayır, DBMS değiştirilmedi10
4,3%DBMS değiştirildi ancak hiçbir şey değişmedi2
42,6%Sonuçları görüntüle20
47 kullanıcı oy kullandı. 12 kişi çekimser kaldı.
Kaynak: habr.com
