Upgrade a major version using zero-downtime mode - ApsaraDB RDS

Veritabanınızı tamamen çalışır durumda tutarken bir ApsaraDB RDS for PostgreSQL örneğinin ana motor sürümünü yükseltmek için kesintisiz modu kullanın. Örnek, tüm süreç boyunca okuma ve yazma işlemlerini kabul eder. Son geçiş aşamasında örnek yalnızca birkaç saniye salt okunur moda geçer; kesin süre, dizi sayısına ve büyük işlemli yazma hacmine bağlıdır.

Diğer yükseltme yaklaşımları için bkz. Ana sürüm yükseltme çözümlerine giriş.

Çalışma prensibi

Kesintisiz mod, örneğinizin bir anlık görüntüsünü hedef sürüme yükseltmek için pg_upgrade aracını çalıştırır, ardından artımlı değişiklikleri kaynaktan eşitlemek için yerel mantıksal çoğaltmayı kullanır. Geçişi tetiklemeden önce hedef örneği doğrularsınız. Geçişi başlattığınızda diziler senkronize edilirken örnek kısa süreyle salt okunur duruma gelir ve ardından trafik yeni sürüme yönlendirilir.

Faturalama

Ücretsizdir.

Ön koşullar

Başlamadan önce aşağıdaki koşulların sağlandığından emin olun:

Örnek, ApsaraDB RDS for PostgreSQL 16 veya daha eski bir sürümü çalıştırıyor olmalıdır.
Depolama türü cloud disk olmalıdır. Yüksek performanslı yerel disklere sahip örnekler yalnızca blue-green deployment mode kullanabilir.
Faturalandırma yöntemi kullandıkça öde veya abonelik olmalıdır. Sunucusuz örnekler yalnızca blue-green deployment mode kullanabilir.
Örnek, bir salt okunur örnek veya özel küme örneği olmamalıdır.
wal_level parametresi logical olarak ayarlanmış olmalıdır. Kesintisiz yükseltmeler mantıksal çoğaltmaya dayandığından wal_level değeri replica veya minimal ise ön yükseltme denetimi başarısız olur. Aksi takdirde devam etmeden önce örnek parametrelerini değiştirin.
Babelfish etkinleştirilmemiş olmalıdır. Küçük motor sürümü numarası babelfish ile bitmemelidir.

Kullanım notları

Yükseltmeye başlamadan önce aşağıdakileri gözden geçirin.

İş etkisi

DDL (Veri Tanımlama Dili) işlemleri, yükseltmenin başladığı andan geçiş tamamlanana kadar yasaktır. Kaynak örnek için kesinti süresi saniyeler cinsinden ölçülür ve dizi sayısı ile büyük işlemli yazma hacmine bağlıdır.

Çoğaltma yuvaları

Kaynak örnekte bir yayın (çoğaltma yuvasının yayınlama ucu) varsa bu çoğaltma yuvası yükseltmeden sonra kaybolur.
Kaynak örnekte bir abone (çoğaltma yuvasının abonelik ucu) varsa yükseltme, çoğaltma yuvasının ele geçirilmesi nedeniyle veri senkronizasyon sorunlarına neden olabilir. Ayrıntılar için SSS bölümüne bakın.

Parametre değişiklikleri

Hedef sürüm tarafından desteklenmeyen parametreler otomatik olarak silinir.
Değerleri hedef sürümün geçerli aralığının dışında kalan parametreler, hedef sürümün parametre şablonundaki varsayılan değerlere sıfırlanır.
statement_timeout yükseltme sırasında geçici olarak 0 değerine ayarlanır ve sonrasında orijinal değerine geri döndürülür.

DTS görevleri

Örnek, Data Transmission Service (DTS) için kaynak veya hedef konumundaysa yükseltmeden sonra DTS görevini yeniden oluşturun.

Eklenti uyumluluğu

Yükseltme, örneği en son küçük motor sürümüne otomatik olarak günceller; bu durum eklenti uyumluluk sorunlarına neden olabilir.

Yedeklemeler

Klon tabanlı kurtarmayı desteklemek amacıyla yükseltmeden önce ve sonra tam yedekleme yapılır.

Farklı yükseltme aşamalarındaki etki

Yükseltme aşaması	Etki
Ana sürüm yükseltmesini başlatın	DDL işlemleri yasaktır.
Çoğaltma yuvaları ve yayınlar oluşturun	DDL işlemleri yasaktır. WAL günlükleri birikmeye başlar.
Aboneyi başlatın ve mantıksal çoğaltma ilişkisi kurun	DDL işlemleri yasaktır. WAL günlükleri tüketilmeye başlar ve artık birikmez. Mantıksal çoğaltma belirli bir kaynak yükü oluşturur; bu yük veritabanı sayısı ve trafikle yakından ilişkilidir.
Geçişi başlatın	DDL işlemleri yasaktır. Mantıksal çoğaltma belirli bir kaynak yükü oluşturur; bu yük veritabanı sayısı ve trafikle yakından ilişkilidir. Örnek salt okunur durumdadır; salt okunur süresi dizi sayısıyla ilgilidir.
Geçişi tamamlayın (yükseltme tamamlandı)	Mantıksal çoğaltma yuvası silinir ve mantıksal çoğaltma tarafından oluşturulan kaynak yükü ortadan kalkar. Örnek normal okuma ve yazma işlemlerine devam eder.

Yükseltme görevi başladıktan sonra Upgrade History sekmesine gidin. Hedef yükseltme görevinin Upgrade Log sütununda View Information seçeneğine tıklayarak ayrıntılı yükseltme sürecini görüntüleyin.

Adım 1: Ön yükseltme denetimi çalıştırın

ApsaraDB RDS konsoluna oturum açın. Üst gezinme çubuğunda örneğin bulunduğu bölgeyi seçin, örneği bulun ve kimliğine tıklayın.
Sol gezinme bölmesinde Major Version Upgrade seçeneğine tıklayın.

Major Version Upgrade görünmüyorsa örneğinizin sürümünü ve yapılandırmasını kontrol edin. Ayrıntılar için bkz. Ön koşullar .
Upgrade Check sekmesinde Create upgrade check report seçeneğine tıklayın.
Hedef sürümü seçin, Upgrade Mode değerini Zero Downtime olarak ayarlayın ve OK seçeneğine tıklayın. Örnek durumu Maintaining Instance olarak değişir. Denetim tamamlandığında durum Running haline döner.
Denetim sonucunu gözden geçirin: Denetim sonuçlarını yorumlamaya yönelik yardım için bkz. ApsaraDB RDS for PostgreSQL ana sürüm yükseltme denetim raporunu yorumlama.
- Success veya Warning: 2. Adıma geçin.
- Failed: View Information seçeneğine tıklayın, bildirilen sorunları düzeltin ve denetimi yeniden çalıştırın.
Önemli
- Sonuç Warning ise bildirilen tüm sorunları düzeltin ve sonuç Success olana kadar denetimi yeniden çalıştırın. - Başarılı bir denetimden sonra birincil örnekte bir eklenti oluşturursanız yükseltmeden önce denetimi yeniden çalıştırın.

Adım 2: Yükseltmeyi başlatın

Bu adımı uygulamadan önce Adım 1: Ön yükseltme denetimi çalıştırın adımını tamamladığınızdan emin olun: Upgrade Check sekmesinde bir yükseltme denetim raporu oluşturun ve yükseltme görevini oluşturmadan önce denetim sonucunun Success veya Warning olduğunu onaylayın.

Upgrade Instance sekmesine tıklayın, uyarıları okuyun, Select The Destination Version alanından bir sürüm seçin ve Create Upgrade Task seçeneğine tıklayın.
İletişim kutusunda istemi okuyun ve OK seçeneğine tıklayın.
Create Major Engine Version Upgrade Task bölümünde Upgrade Mode değerini Zero Downtime olarak ayarlayın ve Create seçeneğine tıklayın.

Örnek durumu Migrating olarak değiştiğinde yükseltme görevi başlamış demektir.

Gerekli süre, örnekteki veritabanı nesnelerinin sayısına bağlıdır; nesne sayısı arttıkça süre uzar. İlerlemeyi Task Hub üzerinden izleyebilirsiniz.

Önemli

Yükseltme görevleri oluşturulduktan sonra değiştirilemez veya silinemez.
Örnek Migrating durumundayken parametreleri değiştirme, yeniden başlatma veya örneği serbest bırakma gibi O&M (işletim ve bakım) görevleri desteklenmez.

Adım 3: Doğrulayın ve geçiş yapın

Hedef örneği doğrulayın

Örnek durumu Migrating değerinden Migrating Data Out değerine geçtiğinde mantıksal çoğaltma kurulur ve hedef örnek doğrulamaya hazır hale gelir.

Upgrade History sekmesine gidin ve yükseltme kaydındaki Later Version Verification URL bilgisini kullanarak hedef örneğe bağlanın ve verileri doğrulayın.

Bu aşamada hedef örnek salt okunur moddadır. Yazma işlemleri desteklenmez.

Yeni sürüme geçiş yapın

Verilerin beklentilerinizi karşıladığını onayladıktan ve Upgrade Result değeri Synchronizing olarak göründükten sonra Upgrade Log sütunundaki Switchover seçeneğine tıklayın.

- Upgrade Result farklı bir durum gösteriyorsa bkz. Yükseltme sonucu açıklamaları . - Yükseltmeden vazgeçmek için Upgrade Log sütunundaki Cancel seçeneğine tıklayın. Bu işlem mantıksal çoğaltma yuvasını siler, kaynak örnekteki çoğaltma ek yükünü kaldırır ve DDL işlemlerini yeniden etkinleştirir.
Switchover iletişim kutusunda Write Downtime Tolerance değerini (saniye cinsinden) ayarlayın ve OK seçeneğine tıklayın. Bu ayar, sistemin geçişi tamamlamadan önce çoğaltma gecikmesinin temizlenmesini beklemesini sağlar ve böylece veri tutarlılığı garanti edilir. Bu bekleme sırasında Upgrade Result değeri Read-only olarak görünür. Tolerans süresi aşılırsa sistem Synchronizing durumuna döner ve salt okunur kısıtlamasını kaldırır. Upgrade Result değeri Read-only olarak değiştiğinde geçiş devam ediyordur ve örnek durumu Migrating şeklindedir. Zaten başlamış olan bir geçişi iptal etmek için Upgrade Log sütunundaki Interrupted seçeneğine tıklayın.
Upgrade Result değeri Succeeded olarak değiştiğinde geçiş tamamlanmış ve örnek durumu Running haline gelmiştir. Örneğin Basic Information sayfasındaki geçerli sürümü doğrulayın.

Yükseltmeden sonraki kesin salt okunur süresini görmek için Upgrade History sekmesine gidin ve Upgrade Log sütunundaki View Information seçeneğine tıklayın. Salt okunur süresi, Switching time ile Switching completion time arasındaki aralıktır ve DNS önbellek yayılımı nedeniyle örneğe ulaşılamayan süreyi içermez.

Yükseltme sonucu açıklamaları

Upgrade History sekmesindeki Upgrade Result sütunu, yükseltme sırasında aşağıdaki değerlerden birini gösterir.

Yükseltme sonucu	Örnek durumu	Açıklama	Kullanılabilir eylemler
Running	Migrating	Yükseltme görevi çalışıyor.	Yok.
Synchronizing	Migrating Data Out	Mantıksal çoğaltma normal.	Yeni sürüme geçiş yapın veya yükseltmeyi iptal edin.
Replication Interrupted	Migrating Data Out	Mantıksal çoğaltma anormal.	Nedeni belirlemek için yükseltme günlüğünü görüntüleyin veya yükseltmeyi iptal edin.
Read-only	Migrating	Geçiş devam ediyor. Diziler senkronize edilirken örnek salt okunur durumdadır.	Kesme: Geçişi iptal edin.
Switchover	Migrating	Dizi senkronizasyonu tamamlandı; geçiş sonlandırılıyor.	Yok.
Cancel	Running	Yükseltme görevi iptal edildi.	Yok.
Succeeded	Running	Yükseltme görevi başarıyla tamamlandı.	Yok.

API başvurusu

API işlemi	Açıklama
UpgradeDBInstanceMajorVersionPrecheck	Ana sürüm yükseltmesi için ön yükseltme denetimi çalıştırır.
DescribeUpgradeMajorVersionPrecheckTask	Ön yükseltme denetim raporunu sorgular.
UpgradeDBInstanceMajorVersion	Ana motor sürümünü yükseltir.
DescribeUpgradeMajorVersionTask	Ana sürüm yükseltme görevlerinin geçmişini sorgular.

SSS

Ana sürüm yükseltmesi sırasında örneği değiştirebilir miyim?

Hayır. Örnek türünü değiştirmek dahil olmak üzere örnek değişiklikleri yükseltme sırasında desteklenmez. Diğer işlemleri yalnızca yükseltme tamamlandıktan sonra gerçekleştirin.

Otomatik ana sürüm yükseltmeleri destekleniyor mu?

Hayır. Ana motor sürümlerine otomatik yükseltmeler desteklenmez.

Ana sürüm düşürme işlemleri destekleniyor mu?

Hayır. Yükseltmeden sonra daha düşük bir ana sürüme düşürme işlemi desteklenmez. Daha düşük bir sürüm çalıştırmak için o sürümü çalıştıran yeni bir örnek satın alın ve verileri geçirmek için DTS kullanın.

Ana sürüm yükseltmesinden sonra hedef örnekte bir raster_overviews görünümü oluşturduğumda raster_overviews çakışması oluşuyor. Bu sorunu nasıl düzeltebilirim?

Bu çakışma, PostGIS sürümü 2.5.2'den eskiyse ve kaynak örnek PostgreSQL 10 veya 11 çalıştırıyorsa ve PostgreSQL 12'ye yükseltme yapıyorsanız ortaya çıkabilir.

Adım 1: Kaynak örnekteki PostGIS eklentisini yükseltin.

Komutun başarılı olduğundan emin olmak için aşağıdaki komutu iki kez çalıştırın.

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

Adım 2: PostGIS Raster eklentisini kullanıp kullanmadığınıza göre düzeltme yöntemini seçin.

PostGIS Raster eklentisi kullanılıyorsa:

raster_overviews görünümünü uzantıdan ayırmak için kaynak örnekte aşağıdaki komutu çalıştırın:

ALTER EXTENSION PostGIS_Raster DROP VIEW raster_overviews;
CREATE OR REPLACE VIEW raster_overviews AS SELECT 1;

PostgreSQL örneğini en az PostgreSQL 12 sürümüne yükseltin.

Yükseltmeden sonra hedef örnekte görünümü yeniden oluşturun:

CREATE OR REPLACE VIEW raster_overviews AS
SELECT
  current_database() AS o_table_catalog,
  n.nspname AS o_table_schema,
  c.relname AS o_table_name,
  a.attname AS o_raster_column,
  current_database() AS r_table_catalog,
  split_part(split_part(s.consrc, '''::name', 1), '''', 2)::name AS r_table_schema,
  split_part(split_part(s.consrc, '''::name', 2), '''', 2)::name AS r_table_name,
  split_part(split_part(s.consrc, '''::name', 3), '''', 2)::name AS r_raster_column,
  trim(both from split_part(s.consrc, ',', 2))::integer AS overview_factor
FROM
  pg_class c,
  pg_attribute a,
  pg_type t,
  pg_namespace n,
  (SELECT connamespace, conrelid, conkey, pg_get_constraintdef(oid) AS consrc FROM pg_constraint) AS s
WHERE
  t.typname = 'raster'::name
  AND a.attisdropped = false
  AND a.atttypid = t.oid
  AND a.attrelid = c.oid
  AND c.relnamespace = n.oid
  AND c.relkind = ANY(ARRAY['r'::char, 'v'::char, 'm'::char, 'f'::char])
  AND s.connamespace = n.oid
  AND s.conrelid = c.oid
  AND s.consrc LIKE '%_overview_constraint(%'
  AND NOT pg_is_other_temp_schema(c.relnamespace)
  AND has_table_privilege(c.oid, 'SELECT'::text);
ALTER EXTENSION PostGIS_Raster ADD VIEW raster_overviews;

PostGIS Raster eklentisi kullanılmıyorsa:

Kaynak örnekteki eklentiyi kaldırın:
```
DROP EXTENSION PostGIS_Raster;
```
PostgreSQL örneğini en az PostgreSQL 12 sürümüne yükseltin.

Çoğaltma yuvasının ele geçirilmesinden kaynaklanan veri senkronizasyon sorunlarını nasıl önleyebilirim?

Kaynak örnekteki abonelik verilerini korumak için: Yükseltme sırasında kaynak örneğin aşırı yük nedeniyle kapanmadığından emin olun. Kapanırsa hedef örnek çoğaltma yuvasını ele geçirebilir ve bu durum veri tutarsızlığına neden olur. Yükseltme tamamlandıktan sonra hedef veritabanındaki aboneliği devre dışı bırakın:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Hedef örnekteki abonelik verilerini korumak için: Yükseltmeden önce kaynak örnekteki aboneliği devre dışı bırakın ve yükseltme tamamlandıktan sonra hedef örnekte yeniden etkinleştirin.

Kaynak örnekte (yükseltmeden önce):

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Hedef örnekte (yükseltmeden sonra):

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Veri aboneliği için çoğaltma yuvalarının kullanımı hakkında daha fazla bilgi için bkz. Mantıksal abonelik ve Değişiklik izleme . Abonelik verileri zaten tutarsızsa sonraki SSS'ye bakın.

Yükseltmeden sonraki abonelik verisi tutarsızlığını nasıl ele alabilirim?

Yükseltme başarıyla tamamlandıktan sonra hedef örnekteki (daha yüksek sürümü çalıştıran) tablo verilerini silin ve ardından copy_data=true parametresiyle aboneliği yeniden oluşturun. Ayrıntılar için bkz. ALTER SUBSCRIPTION.

Alternatif olarak, kaynak örnek tarafından tüketilen verileri hedefe birleştirmek için ON CONFLICT yan tümcesini kullanın. Aşağıdaki örnek, zaman damgasına göre çakışmaların nasıl ele alınacağını göstermektedir:

CREATE TABLE my_tbl(id INT PRIMARY KEY, t TIMESTAMP, val TEXT);

INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'a');
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP, 'b');
INSERT INTO my_tbl VALUES (3, CURRENT_TIMESTAMP, 'c');

-- Update if the incoming row has a newer timestamp
INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'd')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

-- Skip if the incoming row has an older timestamp
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP - '10 hours'::interval, 'e')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

-- Insert new rows normally
INSERT INTO my_tbl VALUES (5, CURRENT_TIMESTAMP - '10 hours'::interval, 'f')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

Veri geçiş aşaması neden beklenenden daha uzun sürüyor?

Veri geçiş aşaması (örnek durumu Migrating iken) veri hacmi, veritabanı nesnelerinin sayısı, örnek teknik özellikleri ve ağ bant genişliğine bağlı olarak zaman alır. Beklenenden daha uzun sürüyorsa aşağıdakileri kontrol edin:

Cloud Monitor'daki örneğin CPU ve G/Ç yükü.
pg_stat_replication görünümündeki çoğaltma gecikmesi.
Ağ bant genişliğinin sınırına ulaşıp ulaşmadığı.

ApsaraDB RDS:Upgrade a major version using zero-downtime mode