ApsaraDB RDS:In-place major version upgrade

Ö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 önceki bir sürümü çalıştırıyor olmalıdır.

• Depolama türü bulut disk olmalıdır.

• Faturalama yöntemi kullandıkça öde veya abonelik olmalıdır.

• Örnek, bir salt okunur örnek veya özel küme örneği olmamalıdır.

• Babelfish etkinleştirilmemiş olmalıdır. Küçük altyapı sürüm numarası babelfish ile bitmemelidir.

Faturalama

Ücretsizdir.

Kullanım notları

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

SELECT count(1) FROM pg_class;

Adım 1: Yükseltme öncesi kontrolü çalıştırma

1. ApsaraDB RDS konsoluna giriş yapın. Üst gezinme çubuğundan örneğin bulunduğu bölgeyi seçin. Örneği bulun ve örnek kimliğine tıklayın.

2. (İsteğe bağlı) Örneğin salt okunur örnekleri varsa uygulama uç noktasını salt okunur örnek uç noktasından birincil örnek uç noktasına değiştirin, ardından salt okunur örnekleri silin.

   Not

   Hizmet etkisini en aza indirmek için uygulama uç noktasını yoğun olmayan saatlerde değiştirin.

3. Sol gezinme bölmesinde Major Version Upgrade seçeneğine tıklayın.

   Not

   Major Version Upgrade görünmüyorsa örneğinizin sürümünü ve yapılandırmasını kontrol edin. Daha fazla bilgi için bkz.

   Ön koşullar

   .

4. Upgrade Check sekmesinde Create upgrade check report öğesine tıklayın.

5. Hedef sürümü seçin, Upgrade Mode seçeneğini Local Upgrade olarak ayarlayın ve OK düğmesine tıklayın. Kontrol çalışırken örnek durumu Maintaining Instance olarak değişir, kontrol tamamlandığında tekrar Running durumuna döner.

6. Kontrol sonuçlarını inceleyin:

   • Success veya Warning: 2. Adıma devam edin.

   • Failed: View Information seçeneğine tıklayın, raporda belirtilen sorunları düzeltin ve kontrolü tekrar çalıştırın. Yaygın hatalarla ilgili ayrıntılar için bkz. ApsaraDB RDS for PostgreSQL ana sürüm yükseltme kontrol raporunu yorumlama.

   Önemli

   - Sonuç Warning ise sorunları düzeltin ve sonuç Success olana kadar kontrolü yeniden çalıştırın. - Kontrol başarılı olduktan sonra birincil örnekte bir eklenti oluşturursanız kontrolü tekrar çalıştırın.

Adım 2: Ana altyapı sürümünü yükseltme

1. Upgrade Instance sekmesine tıklayın. Uyarıları okuyun, yükseltme sürümünü seçin ve Create Upgrade Task düğmesine tıklayın.

2. İletişim kutusunda istemi okuyun ve OK düğmesine tıklayın.

3. Create Major Engine Version Upgrade Task bölümünde Upgrade Mode seçeneğini Local Upgrade olarak ayarlayın ve Cutover time değerini yapılandırın:

   • immediately: Geçiş tamamlandıktan hemen sonra anahtarlama gerçekleşir.

   • Instance operation and maintenance time: Anahtarlama, yapılandırılan bakım penceresi içinde gerçekleşir.

4. Create now düğmesine tıklayın. Yükseltme görevi başladığında örnek durumu Migration in Progress olarak değişir. Süre, veritabanı nesnelerinin sayısına göre artar. İlerlemeyi Task Hub üzerinden takip edebilirsiniz.

   Önemli

   - Yükseltme görevleri oluşturulduktan sonra değiştirilemez veya silinemez. - Örnek Migration in Progress durumundayken parametreleri değiştirme, yeniden başlatma veya örneği serbest bırakma gibi işlemler kullanılamaz.

5. Kaynak ve hedef örneklerin her ikisinin durumu da Running olduğunda yükseltme tamamlanmış olur.

   Not

   Upgrade History

   sekmesinde,

   Upgrade Log

   sütunundaki

   View Information

   seçeneğine tıklayarak salt okunur süresini ve ayrıntılı yükseltme günlüğünü görüntüleyebilirsiniz. Salt okunur süresi, DNS önbelleği temizleme süresi hariç olmak üzere

   Cutover Time

   ve

   Cutover End Time

   arasındaki süredir.

Sonraki adımlar

Yükseltme öncesinde salt okunur örnekleri sildiyseniz:

1. Hedef örnekte salt okunur örnekler oluşturun.

2. Uygulamanızda uç noktayı yeni salt okunur örneği gösterecek şekilde güncelleyin.

Yükseltme sonucu referansı

Upgrade History sekmesindeki Upgrade Result sütunu aşağıdaki durumlardan birini gösterir:

API referansı

Başvurular

• Ana sürüm yükseltmelerine giriş

• Sıfır kesinti süresi yöntemini kullanarak ana altyapı sürümünü yükseltme

• Mavi-yeşil dağıtım yöntemini kullanarak ana altyapı sürümünü yükseltme

• Ana altyapı sürümü yükseltme kontrol raporunu yorumlama

SSS

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

Hayır. Örnekte değişiklik yapmadan önce yükseltmenin tamamlanmasını bekleyin.

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

Hayır. Ana altyapı sürümü yükseltmeleri manuel olarak başlatılmalıdır.

Ana altyapı sürümü düşürme destekleniyor mu?

Hayır. Daha düşük bir sürüm çalıştırmak için hedef sürümde yeni bir örnek satın alın ve verileri geçirmek için DTS kullanın.

Yükseltme sonrası bir görünüm oluştururken raster_overviews çakışma hatası alıyorum. Bunu nasıl düzeltirim?

Bu durum, PostgreSQL 10 veya 11 üzerindeki 2.5.2'den önceki PostGIS sürümlerini PostgreSQL 12'ye yükseltirken etkiler. Aşağıdaki adımları izleyin:

1. Kaynak örnekte PostGIS eklentisini yükseltin. İşlemin 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();

2. PostGIS Raster eklentisini kullanıp kullanmadığınıza bağlı olarak düzeltme yöntemini seçin.

PostGIS Raster kullanıyorsanız:

1. Kaynak örnekte raster_overviews görünümünü eklentiden kaldırın ve yerine bir yer tutucu ekleyin:

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

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

3. Hedef örnekte tam görünümü yeniden oluşturun ve bunu tekrar eklentiye ekleyin:

   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 kullanmıyorsanız:

1. Kaynak örnekte eklentiyi kaldırın:

   DROP EXTENSION PostGIS_Raster;

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

Yükseltme sırasında çoğaltma yuvası çakışmasından kaynaklanan veri tutarsızlığını nasıl önlerim?

Abonelik verilerinin yükseltme sonrasında nerede bulunmasını istediğinize bağlı olarak aşağıdaki yaklaşımlardan birini seçin.

Abonelik verilerini kaynak örnekte tutma:

Yükseltme sırasında aşırı yük altında kaynak örneğin kapanmadığından emin olun. Kapanırsa çoğaltma yuvası hedef örnek tarafından ele geçirilebilir ve bu durum veri tutarsızlığına neden olabilir. Yükseltme sonrası hedef veritabanındaki aboneliği devre dışı bırakın:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Abonelik verilerini hedef örneğe taşıma:

Yükseltme öncesinde kaynak örnekteki aboneliği devre dışı bırakın:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Yükseltme sonrası hedef örnekteki aboneliği etkinleştirin:

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Yükseltme sonrası abonelik verisi tutarsızlığını nasıl düzeltirim?

1. Hedef örnekte (daha yüksek sürüm) etkilenen tablo verilerini silin. Ardından aboneliği copy_data=true parametresiyle yeniden oluşturun. Ayrıntılar için bkz. ALTER SUBSCRIPTION.

2. Kaynak örnekteki (daha düşük sürüm) verileri hedefe aktarmak için ON CONFLICT kullanın. Aşağıdaki örnek deseni 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');
   
   -- Newer timestamp: update the existing row
   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;
   
   -- Older timestamp: skip the row
   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;
   
   -- New row: insert
   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;

Neden ana altyapı sürümü yükseltmesinden önce salt okunur örnekleri silmem gerekiyor?

Salt okunur düğümler ve bunların çoğaltma yuvaları, yükseltme sonrası kaynak örneğe bağlı kalır ve otomatik olarak hedef örneğe aktarılmaz. Bunları yükseltme öncesinde silin ve ardından hedef örnekte yeniden oluşturun.