Aracılığıyla paylaş

PostgreSQL için Azure Veritabanı'a sorunsuz geçiş için en iyi yöntemler

Bu makalede karşılaşılan yaygın tuzaklar ve PostgreSQL için Azure Veritabanı sorunsuz ve başarılı bir geçiş sağlamak için en iyi yöntemler açıklanmaktadır.

Ön geçiş doğrulaması

Geçiş işleminin ilk adımı olarak, geçiş gerçekleştirmeden önce geçiş öncesi doğrulamasını çalıştırın. Geçiş Kurulumu sayfasında Doğrula ve Doğrula ve taşı seçeneklerini kullanabilirsiniz. Premigration validation, önceden tanımlanmış bir kural kümesinde kapsamlı denetimler gerçekleştirir. Amaç, olası sorunları belirlemek ve düzeltilebilir eylemler için eyleme dönüştürülebilir içgörüler sağlamaktır. Başarılı duruma gelene kadar ön geçiş doğrulamayı çalıştırmaya devam edin. Daha fazla bilgi edinmek için bkz . Ön geçiş doğrulamaları.

Hedef esnek sunucu yapılandırması

Verilerin ilk temel kopyası sırasında hedefte birden çok insert deyimi yürütülür ve bu da önceden yazma günlükleri (WAL) oluşturur. Bu WAL'ler arşivlenene kadar günlükler hedefte depolama alanı ve veritabanının gerektirdiği depolama alanını kullanır.

Sayıyı hesaplamak için kaynak örnekte oturum açın ve geçirilecek tüm veritabanları için şu komutu çalıştırın:

SELECT pg_size_pretty( pg_database_size('dbname') );

Esnek sunucuda, önceki komutun çıktısı başına kullanılandan 1,25 kat veya %25 daha fazla depolama alanına eşdeğer yeterli depolama alanı ayırmanızı öneririz. Depolama Otomatik Büyütme özelliğini de kullanabilirsiniz.

Önemli

Depolama boyutu el ile yapılandırmada veya Depolama Otomatik Büyütme'de azaltılamaz. Depolama yapılandırma spektrumundaki her adımın boyutu iki katına çıkdığından, gerekli depolamayı önceden tahmin etmek akıllıca olur.

PostgreSQL için esnek bir Azure Veritabanı sunucusu oluşturma hızlı başlangıcı, başlamak için mükemmel bir başlangıç noktasıdır. Her sunucu yapılandırması hakkında daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı esnek sunucusunda işlem ve depolama seçenekleri.

Önemli

Esnek sunucu oluşturulduktan sonra, geçişi başlatmadan önce esnek sunucunuzdaki password_encryption sunucu parametresini SCRAM-SHA-256'dan MD5'e değiştirdiğinizden emin olun. Bu, tek sunucudaki mevcut kimlik bilgilerinin esnek sunucunuzda çalışması için gereklidir

Geçiş zaman çizelgesi

Her geçişin başladıktan sonra en fazla yedi gün (168 saat) ömrü vardır ve yedi gün sonra zaman aşımına uğrar. Geçiş ve uygulama tam geçişinizi veri doğrulamasından sonra tamamlayabilir ve geçişin zaman aşımına uğradıktan sonra tüm denetimleri tamamlayabilirsiniz. Çevrimiçi geçişlerde, ilk temel kopya tamamlandıktan sonra tam geçiş penceresi zaman aşımına uğramadan önce üç gün (72 saat) sürer. Çevrimdışı geçişlerde, veri kaybını önlemek için uygulamaların veritabanına yazmayı durdurması gerekir. Benzer şekilde, çevrimiçi geçiş için geçiş boyunca trafiği düşük tutun.

Çoğu üretim dışı sunucu (geliştirme, UAT, test ve hazırlama) çevrimdışı geçişler kullanılarak geçirilir. Bu sunucularda üretim sunucularından daha az veri olduğundan geçiş hızlıdır. Üretim sunucusu geçişi için, önceden planlamak üzere geçişi tamamlamak için gereken süreyi bilmeniz gerekir.

Geçişin tamamlanması için geçen süre birkaç faktöre bağlıdır. Veritabanlarının sayısını, boyutunu, her veritabanının içindeki tablo sayısını, dizin sayısını ve tablolar arasında veri dağılımını içerir. Ayrıca hedef sunucunun SKU'sunu ve kaynak örnekte ve hedef sunucuda kullanılabilen IOPS'yi de kullanır. Geçiş süresini etkileyebilecek birçok faktör olduğunda, geçişin tamamlanması için toplam süreyi tahmin etmek zordur. En iyi yaklaşım, iş yükünüzle test geçişi gerçekleştirmektir.

Üretim sunucusu geçişini gerçekleştirmek için toplam kapalı kalma süresini hesaplamak için aşağıdaki aşamalar dikkate alınır:

  • PITR geçişi: Üretim veritabanı sunucunuzu geçirmek için geçen süreyle ilgili iyi bir tahmin elde etmenin en iyi yolu, üretim sunucunuzun belirli bir noktaya geri yüklemesini (PITR) almak ve çevrimdışı geçişi bu yeni geri yüklenen sunucuda çalıştırmaktır.

  • Arabellek geçişi: Önceki adımı tamamladıktan sonra, uygulama trafiğinin az olduğu bir zaman aralığında gerçek üretim geçişini planlayabilirsiniz. Bu geçiş aynı gün veya muhtemelen bir hafta sonra planlanabilir. Bu zamana kadar kaynak sunucunun boyutu artmış olabilir. Üretim sunucunuz için tahmini geçiş sürenizi bu artışın miktarına göre güncelleştirin. Artış önemliyse PITR sunucusunu kullanarak başka bir test yapmayı göz önünde bulundurun. Ancak çoğu sunucu için boyut artışı yeterince önemli olmamalıdır.

  • Veri doğrulama: Üretim sunucusu için geçiş tamamlandıktan sonra, esnek sunucudaki verilerin kaynak örneğin tam bir kopyası olup olmadığını doğrulamanız gerekir. Açık kaynak veya üçüncü taraf araçlarını kullanabilir veya doğrulamayı el ile yapabilirsiniz. Gerçek geçiş öncesinde yapmak istediğiniz doğrulama adımlarını hazırlayın. Doğrulama şunları içerebilir:

    • Satır sayısı, geçişte yer alan tüm tablolar için eşleşir.

    • Tüm veritabanı nesneleri (tablolar, diziler, uzantılar, yordamlar ve dizinler) için eşleşen sayımlar.

    • Uygulamayla ilgili anahtar sütunlarının maksimum veya en düşük kimliklerini karşılaştırma.

      Not

      Veritabanlarının karşılaştırmalı boyutu doğrulama için doğru ölçüm değildir. Kaynak örnekte bloblar veya ölü tanımlama kümeleri olabilir ve bu da kaynak örneğin boyutunu artırabilir. Kaynak örneklerle hedef sunucular arasında boyut farklılıkları olması normaldir. Önceki üç doğrulama adımındaki bir sorun, geçişle ilgili bir sorun olduğunu gösterir.

  • Sunucu ayarlarının geçişi: Tüm özel sunucu parametreleri, güvenlik duvarı kuralları (varsa), etiketler ve uyarılar kaynak örnekten hedefe el ile kopyalanmalıdır.

  • bağlantı dizesi değiştirme: Uygulama, başarılı doğrulamadan sonra bağlantı dizesi esnek bir sunucuyla değiştirmelidir. Bu etkinlik, kaynak örneğe işaret eden bağlantı dizesi tüm başvurularını değiştirmek için uygulama ekibiyle koordine edilir. Esnek sunucuda, kullanıcı parametresi bağlantı dizesi user=username biçiminde kullanılabilir.

Örneğin: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

Geçiş genellikle sorunsuz çalışsa da hata ayıklama için daha fazla zaman gerekiyorsa veya geçişin yeniden başlatılması gerekiyorsa olasılıkları planlamak iyi bir uygulamadır.

Geçiş hızı karşılaştırması

Aşağıdaki tabloda, geçiş hizmetini kullanarak çeşitli boyutlardaki veritabanları için geçiş gerçekleştirme süresi gösterilmektedir. Geçiş, SKU Standard_D4ds_v4 (4 çekirdek, 16 GB bellek) ile esnek bir sunucu kullanılarak gerçekleştirildi.

Veritabanı boyutu Geçen yaklaşık süre (SS:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01.00
500 GB 04.00
1.000 GB 07.00

Önceki sayılar, geçişi tamamlamak için geçen süreyi yaklaşık olarak gösterir. Sunucunuzu geçirirken kesin bir değer elde etmek için iş yükünüzle bir test geçişi çalıştırmanızı kesinlikle öneririz.

Önemli

Hızla Artırılabilir SKU bir sınırlama olmasa da esnek sunucunuz için daha hızlı geçişler gerçekleştirmek üzere daha yüksek bir SKU seçmeniz önerilir. PostgreSQL için Azure Veritabanı esnek sunucusu sıfıra yakın kapalı kalma süresi işlem ve IOPS ölçeklendirmesini desteklediğinden SKU en düşük kapalı kalma süresiyle güncelleştirilebilir. SKU'yu geçiş sonrası uygulama gereksinimleriyle eşleşecek şekilde istediğiniz zaman değiştirebilirsiniz.

Geçiş hızını artırma: Tabloların paralel geçişi

PostgreSQL geçiş hizmetinin esnek sunucudaki kapsayıcısı bittiğinden, hedef için güçlü bir SKU öneririz. Güçlü bir SKU, paralel olarak daha fazla tablonun geçirilmesini sağlar. Geçiş sonrasında SKU'yu tercih ettiğiniz yapılandırmaya geri ölçeklendirin. Bu bölüm, tablolar arasındaki veri dağılımının daha dengeli olması gerekiyorsa veya daha güçlü bir SKU geçiş hızını önemli ölçüde etkilemiyorsa geçiş hızını iyileştirme adımlarını içerir.

Kaynaktaki veri dağıtımı yüksek oranda dengesizse ve verilerin çoğu tek bir tabloda bulunursa, geçiş için ayrılan işlem tam olarak kullanılmalıdır ve bu da bir performans sorunu oluşturur. Bu nedenle, büyük tabloları daha küçük parçalara bölün ve daha sonra paralel olarak geçirilir. Bu özellik 20 GB'tan büyük tablolar için geçerlidir. Aşağıdaki koşullardan biri karşılanırsa tabloyu daha küçük öbeklere bölmek mümkündür:

  • Tablo, basit (bileşik değil) birincil anahtara veya veya türünde smallintintegerbig intbenzersiz dizine sahip bir sütuna sahip olmalıdır.

    Not

    Birinci veya ikinci yaklaşımlar söz konusu olduğunda, kaynak şemaya benzersiz bir dizin sütunu eklemenin etkilerini dikkatle değerlendirmeniz gerekir. Yalnızca benzersiz bir dizin sütunu eklemenin, değişiklikleri uygulamanız halinde uygulamayı etkilemeyebileceği onaylandıktan sonra.

  • Tablonun türü basit bir birincil anahtarı veya benzersiz dizini smallintinteger yoksa veya big int veri türü ölçütlerini karşılayan bir sütunu varsa, sütun aşağıdaki komut kullanılarak benzersiz bir dizine dönüştürülebilir. Bu komut, tabloda kilit gerektirmez.

        create unique index concurrently partkey_idx on <table name> (column name);

  • Tabloda bir smallint, integer veya birincil anahtar ya da big int benzersiz dizin ya da veri türü ölçütlerini karşılayan herhangi bir sütun yoksa, ALTER kullanarak böyle bir sütun ekleyebilir ve geçiş sonrasında bırakabilirsiniz. Komutu çalıştırmak ALTER için tabloda bir kilit gerekir.

        alter table <table name> add column <column name> big serial unique;

Yukarıdaki koşullardan herhangi biri karşılanırsa, tablo birden çok bölümde paralel olarak geçirilir ve bu da geçiş hızında bir artış sağlamalıdır.

Nasıl çalışır?

  • Geçiş hizmeti, tablonun boyutunu 20 GB'tan büyük olup olmadığını denetlemek için arar.
  • Boyut 20 GB'tan büyükse ve bir veya smallint birincil anahtar ya da integer benzersiz dizin big intvarsa, tablo birden çok bölüme bölünür ve her bölüm paralel olarak geçirilir.

Özetle, PostgreSQL geçiş hizmeti bir tabloyu paralel iş parçacıklarında geçirir ve aşağıdaki durumlarda geçiş süresini kısaltır:

  • Tabloda, basit bir birincil anahtara veya veya türünde smallintinteger benzersiz dizine sahip bir sütun vardırbig int.
  • Tablo boyutu 20 GB'tan büyük.
  • Kullanılan SKU'nun boştaki çekirdekleri vardır ve bu çekirdekler tabloyu paralel olarak geçirmek için kullanılabilir.

PostgreSQL veritabanında vakum kabarıklık

Zaman içinde veriler eklendikçe, güncelleştirildikçe ve silindikçe PostgreSQL boş satırlar ve boşa harcanan depolama alanı biriktirebilir. Bu şişkinlik, depolama gereksinimlerinin artmasına ve sorgu performansının düşmesine neden olabilir. Vakumlama, bu boşa harcanan alanın geri kazanılmasında yardımcı olan ve veritabanının verimli çalışmasını sağlayan önemli bir bakım görevidir. Vakumlama, depolamanın verimli bir şekilde kullanılmasını sağlamak için ölü satırlar ve tablo şişkinliği gibi sorunları giderir. Ayrıca, geçiş süresi veritabanı boyutunun bir işlevi olduğundan daha hızlı geçiş sağlamaya da yardımcı olur.

PostgreSQL, ölü satırlar VACUUM tarafından kullanılan depolama alanını geri kazanmak için komutunu sağlar. Seçeneği ayrıca ANALYZE sorgu planlamasını daha da iyileştirmek için istatistikler toplar. Yoğun yazma etkinliği olan tablolar için işlem VACUUM kullanılarak VACUUM FULLdaha agresif olabilir, ancak çalıştırılması daha fazla zaman gerektirir.

  • Standart vakum

    VACUUM your_table;

  • Analiz ile vakumlama

    VACUUM ANALYZE your_table;

  • Ağır yazma tabloları için agresif vakum

    VACUUM FULL your_table;

Bu örnekte, your_table yerine gerçek tablo adını yazın. Alanı VACUUM verimli bir şekilde geri kazanmadan FULL komutu, VACUUM ANALYZE sorgu planlamasını iyileştirir. Bu VACUUM FULL seçenek, daha ağır performans etkisi nedeniyle judiciously kullanılmalıdır.

Bazı veritabanları, zaman içinde veritabanı şişirmeye katkıda bulunabilecek görüntüler veya belgeler gibi büyük nesneleri depolar. VACUUMLO komutu PostgreSQL'deki büyük nesneler için tasarlanmıştır.

  • Büyük nesneleri vakumlama

    VACUUMLO;

Bu vakumlama stratejilerini düzenli olarak birleştiren, bakımlı bir PostgreSQL veritabanı sağlar.

Dikkat edilmesi gereken özel noktalar

Genellikle bir öğreticiye veya modüle devam etmeden önce bilmeniz gereken benzersiz koşullara, yapılandırmalara veya önkoşullara başvuran özel koşullar vardır. Bu koşullar, öğrenme içeriğinin başarıyla tamamlanması için gereken belirli yazılım sürümlerini, donanım gereksinimlerini veya diğer araçları içerebilir.

Çevrimiçi geçiş

Çevrimiçi geçiş, pgcopydb kullanımını takip eder ve mantıksal kod çözme kısıtlamalarından bazıları geçerlidir. Ayrıca, çevrimiçi geçiş yapılan bir veritabanının tüm tablolarında birincil anahtarınız olması önerilir. Birincil anahtar yoksa, eksiklik yalnızca insert geçiş sırasında güncelleştirmeler veya silmeler dışında işlemlerin yansıtılmasıyla sonuçlanır. Çevrimiçi geçişe devam etmeden önce ilgili tablolara geçici bir birincil anahtar ekleyin.

Not

Birincil anahtarı olmayan tabloların çevrimiçi geçişi durumunda, hedefte yalnızca insert işlemler yeniden yürütüler. Kaynakta güncelleştirilen veya silinen kayıtlar hedefe yansıtılmazsa bu durum veritabanında tutarsızlığa neden olabilir.

Alternatif olarak, eylemin ALTER TABLE ÇOĞALTMA IDENTIY olduğu komutu seçeneğiyle FULL birlikte kullanabilirsiniz. seçeneği FULL satırdaki tüm sütunların eski değerlerini kaydeder, böylece birincil anahtar olmadığında bile tüm CRUD işlemleri çevrimiçi geçiş sırasında hedefe yansıtılır. Bu seçeneklerden hiçbiri işe yaramazsa alternatif olarak çevrimdışı geçiş gerçekleştirin.

postgres_fdw uzantılı veritabanı

postgres_fdw modülü, dış PostgreSQL sunucularında depolanan verilere erişmek için kullanılabilen yabancı veri sarmalayıcı postgres_fdw sağlar. Veritabanınız bu uzantıyı kullanıyorsa, geçişin başarılı olmasını sağlamak için aşağıdaki adımların gerçekleştirilmesi gerekir.

  1. Kaynak örnekteki yabancı veri sarmalayıcısını geçici olarak kaldırın (bağlantısını kaldırın).
  2. Geçiş hizmetini kullanarak geri kalanın veri geçişini gerçekleştirin.
  3. Yabancı veri sarmalayıcı rollerini, kullanıcısını ve geçiş sonrasında hedefe bağlantıları geri yükleyin.

postGIS uzantısına sahip veritabanı

postGIS uzantısında farklı sürümler arasında hataya neden olan değişiklikler/sıkıştırma sorunları vardır. Esnek bir sunucuya geçiş yaparsanız, uygulamanın etkilenmediğinden veya gerekli değişikliklerin yapılması gerektiğinden emin olmak için uygulamanın daha yeni postGIS sürümüne karşı denetlenmesi gerekir. PostGIS haberleri ve sürüm notları, sürümler arasında son dakika değişikliklerini anlamak için iyi bir başlangıç noktasıdır.

Veritabanı bağlantısı temizleme

Bazen bir geçiş başlattığınızda şu hatayla karşılaşabilirsiniz:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

Bu senaryoda, geçişi yeniden denemeden önce veritabanına yönelik tüm etkin bağlantıları kapatma izni verebilir migration user veya bağlantıları el ile kapatabilirsiniz.

İlgili içerik

  • Last updated on