Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Keterbatasan dan pertimbangan untuk penerapan Amazon RDS Amazon blue/green
<a name="blue-green-deployments-considerations"></a>

Blue/green penerapan di Amazon RDS memerlukan pertimbangan yang cermat terhadap faktor-faktor seperti slot replikasi, manajemen sumber daya, ukuran instans, dan potensi dampak pada kinerja database. Bagian berikut memberikan panduan untuk membantu Anda mengoptimalkan strategi penerapan untuk memastikan waktu henti minimal, transisi yang mulus, dan pengelolaan lingkungan database Anda yang efektif.

**Topics**
+ [Batasan untuk blue/green penerapan](#blue-green-deployments-limitations)
+ [Pertimbangan untuk penerapan blue/green](#blue-green-deployments-consider)

## Batasan untuk blue/green penerapan
<a name="blue-green-deployments-limitations"></a>

Batasan berikut berlaku untuk blue/green penerapan.

**Topics**
+ [Batasan umum untuk blue/green penerapan](#blue-green-deployments-limitations-general)
+ [untuk penerapan blue/green](#blue-green-deployments-limitations-mysql)
+ [RDS untuk batasan PostgreSQL untuk penerapan dengan replikasi fisik blue/green](#blue-green-deployments-limitations-postgres-physical)
+ [untuk penerapan dengan replikasi logis blue/green](#blue-green-deployments-limitations-postgres-logical)

### Batasan umum untuk blue/green penerapan
<a name="blue-green-deployments-limitations-general"></a>

Batasan umum berikut berlaku untuk blue/green penerapan:
+ Blue/green penerapan tidak mendukung pengelolaan kata sandi pengguna master dengan. AWS Secrets Manager
+ Jika volume log khusus (DLV) diaktifkan pada database biru, itu harus diaktifkan pada *semua* instance DB, termasuk replika baca.
+ Selama switchover, lingkungan biru dan hijau tidak boleh memiliki integrasi nol-ETL dengan Amazon Redshift. Anda harus menghapus integrasi tersebut terlebih dahulu dan switchover, lalu membuat ulang integrasi.
+ Penjadwal Acara (`event_scheduler`parameter) harus dinonaktifkan di lingkungan hijau saat Anda membuat blue/green penerapan. Ini mencegah peristiwa dihasilkan di lingkungan hijau dan menyebabkan inkonsistensi.
+ Anda tidak dapat mengubah instans DB yang tidak terenkripsi menjadi instans DB yang terenkripsi. 
+ Anda tidak dapat mengubah instans DB biru ke versi engine yang lebih tinggi daripada instans DB hijau yang sesuai.
+ Sumber daya di lingkungan biru dan lingkungan hijau harus berada dalam Akun AWS yang sama.
+ Jika Anda menggunakan Amazon RDS Proxy, Anda harus mendaftarkan klaster biru Anda dengan proxy sebelum membuat blue/green penerapan. Jika blue/green penerapan sudah ada untuk klaster biru tertentu, mendaftarkan cluster biru itu ke Amazon RDS Proxy akan diblokir.
+ Amazon RDS Proxy dengan blue/green penerapan tidak didukung untuk Aurora Global Databases.
+ Blue/green penerapan tidak didukung untuk fitur berikut:
  + Replika baca kaskade
  + Cross-Region baca replika
  + CloudFormation
  + Multi-AZ Penerapan cluster DB

    Blue/green penerapan didukung untuk penerapan instans Multi-AZ DB. Untuk informasi selengkapnya tentang Multi-AZ penerapan, lihat. [Mengkonfigurasi dan mengelola Multi-AZ penyebaran untuk Amazon RDS](Concepts.MultiAZ.md)

### untuk penerapan blue/green
<a name="blue-green-deployments-limitations-mysql"></a>

Batasan berikut berlaku untuk : blue/green 
+  instans DB biru tidak bisa menjadi replika binlog eksternal.
+ Jika database sumber dikaitkan dengan grup opsi kustom, Anda tidak dapat menentukan pemutakhiran versi utama saat membuat blue/green penerapan.

  Dalam hal ini, Anda dapat membuat blue/green penyebaran tanpa menentukan upgrade versi utama. Kemudian, Anda dapat meningkatkan basis data di lingkungan hijau. Untuk informasi selengkapnya, lihat [Meningkatkan versi mesin instans DB ](USER_UpgradeDBInstance.Upgrading.md).
+ Blue/green penerapan tidak mendukung AWS Driver JDBC untuk MySQL. Untuk informasi selengkapnya, lihat [Batasan yang Diketahui](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations) pada GitHub.

### RDS untuk batasan PostgreSQL untuk penerapan dengan replikasi fisik blue/green
<a name="blue-green-deployments-limitations-postgres-physical"></a>

Batasan berikut berlaku untuk RDS untuk penyebaran blue/green PostgreSQL yang menggunakan replikasi fisik. Untuk penjelasan kapan blue/green penerapan menggunakan replikasi fisik alih-alih replikasi logis, lihat. [Metode replikasi PostgreSQL untuk penerapan blue/green](blue-green-deployments-replication-type.md)
+ Setelah lingkungan hijau dibuat, Anda tidak dapat melakukan upgrade versi utama manual.
+ Blue/green penerapan yang menggunakan replikasi fisik tidak mendukung perubahan skema pada lingkungan hijau, karena hanya baca.
+ Instans DB biru tidak bisa menjadi sumber logis (penerbit) atau replika (pelanggan).
+ Blue/Green penerapan memiliki batasan berikut saat mengonfigurasi replikasi tertunda di RDS untuk PostgreSQL:
  + **Instance sumber hijau** - `recovery_min_apply_delay parameter` Ini diabaikan, bahkan jika dikonfigurasi dalam grup parameter. Pengaturan penundaan apa pun pada instance sumber hijau tidak berlaku.
  + **Instance replika hijau** - `recovery_min_apply_delay parameter` Ini sepenuhnya didukung dan diterapkan ke file konfigurasi PostgreSQL. Pengaturan tunda berfungsi seperti yang diharapkan selama alur kerja switchover.
  + Replikasi tertunda tidak kompatibel dengan Blue/Green penerapan RDS untuk peningkatan versi utama.

### untuk penerapan dengan replikasi logis blue/green
<a name="blue-green-deployments-limitations-postgres-logical"></a>

Batasan berikut berlaku untuk yang menggunakan replikasi logis. blue/green Untuk penjelasan kapan blue/green penerapan menggunakan replikasi logis alih-alih replikasi fisik, lihat. [Metode replikasi PostgreSQL untuk penerapan blue/green](blue-green-deployments-replication-type.md)
+ Tabel [yang tidak tercatat](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) tidak direplikasi ke lingkungan hijau .
+  instans DB biru tidak bisa menjadi sumber logis (penerbit) atau replika (pelanggan).
+ Jika instans DB biru dikonfigurasi sebagai server asing dari ekstensi pembungkus data asing (FDW), Anda harus menggunakan nama titik akhir instans, alih-alih alamat IP. Hal ini memungkinkan konfigurasi untuk tetap berfungsi setelah switchover.
+ Dalam blue/green penyebaran, setiap database memerlukan slot replikasi logis. Seiring bertambahnya jumlah database, overhead sumber daya meningkat dan berpotensi menyebabkan kelambatan replikasi, terutama jika instans tidak cukup diskalakan. Dampaknya tergantung pada faktor-faktor seperti beban kerja database dan jumlah koneksi. 
+ [Proses penerapan](https://www.postgresql.org/docs/current/logical-replication-architecture.html) replikasi logis di lingkungan hijau adalah single-threaded. Jika lingkungan biru menghasilkan volume lalu lintas tulis yang tinggi, lingkungan hijau mungkin tidak dapat mengikutinya. Hal ini dapat menyebabkan kelambatan replikasi atau kegagalan, terutama untuk beban kerja yang menghasilkan throughput penulisan tinggi yang berkelanjutan. Pastikan untuk menguji beban kerja Anda secara menyeluruh. Untuk skenario yang memerlukan peningkatan versi mayor dan menangani beban kerja tulis volume tinggi, pertimbangkan pendekatan alternatif seperti menggunakan [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) .
+ Blue/Green penerapan memiliki batasan berikut saat mengonfigurasi replikasi tertunda di RDS untuk PostgreSQL:
  + **Instance sumber hijau** - `recovery_min_apply_delay parameter` Ini diabaikan, bahkan jika dikonfigurasi dalam grup parameter. Pengaturan penundaan apa pun pada instance sumber hijau tidak berlaku.
  + **Instance replika hijau** - `recovery_min_apply_delay parameter` Ini sepenuhnya didukung dan diterapkan ke file konfigurasi PostgreSQL. Pengaturan tunda berfungsi seperti yang diharapkan selama alur kerja switchover.
  + Replikasi tertunda tidak kompatibel dengan Blue/Green penerapan RDS untuk peningkatan versi utama.
+ Membuat partisi baru pada tabel yang dipartisi tidak didukung selama penerapan untuk RDS untuk PostgreSQL. Membuat partisi baru melibatkan operasi bahasa definisi data (DDL) seperti`CREATE TABLE`, yang tidak direplikasi dari lingkungan biru ke lingkungan hijau. Namun, tabel partisi yang ada dan datanya akan direplikasi ke lingkungan hijau.
+ Batasan berikut berlaku untuk ekstensi PostgreSQL:
  + `pg_partman`Ekstensi harus dinonaktifkan di lingkungan biru saat Anda membuat blue/green penerapan. Ekstensi tersebut menjalankan operasi DDL seperti `CREATE TABLE`, yang memecah replikasi logis dari lingkungan biru ke lingkungan hijau.
  + `pg_cron`Ekstensi harus tetap dinonaktifkan pada semua database hijau setelah blue/green penerapan dibuat. Ekstensi tersebut memiliki pekerja latar belakang yang berjalan sebagai superuser dan melewati pengaturan hanya baca di lingkungan hijau, yang dapat menyebabkan konflik replikasi.
  + `pgactive`Ekstensi `pglogical` dan harus dinonaktifkan di lingkungan biru saat Anda membuat blue/green penerapan. Setelah Anda beralih ke lingkungan hijau menjadi lingkungan produksi baru, Anda dapat mengaktifkan ekstensi lagi. Selain itu, basis data biru tidak bisa menjadi pelanggan logis dari instans eksternal.
  + Jika Anda menggunakan `pgAudit` ekstensi, ekstensi harus tetap berada di pustaka bersama (`shared_preload_libraries`) pada grup parameter DB khusus untuk instance DB biru dan hijau. Untuk informasi selengkapnya, lihat [Menyiapkan ekstensi pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).

#### Keterbatasan spesifik replikasi logis untuk penerapan blue/green
<a name="blue-green-deployments-limitations-postgres"></a>

PostgreSQL memiliki batasan tertentu yang terkait dengan replikasi logis, yang diterjemahkan ke batasan saat membuat penerapan untuk klaster PostgreSQL DB RDS blue/green untuk instance PostgreSQL DB.

Tabel berikut menjelaskan batasan replikasi logis yang berlaku untuk blue/green penerapan untuk . Untuk informasi selengkapnya, lihat [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) di dokumentasi replikasi logis PostgreSQL.


| Batasan | Penjelasan | 
| --- | --- | 
| Pernyataan bahasa definisi data (DDL), seperti CREATE TABLE dan CREATE SCHEMA, tidak direplikasi dari lingkungan biru ke lingkungan hijau. | Jika Amazon RDS mendeteksi perubahan DDL di lingkungan biru, basis data hijau Anda memasukkan status **Replikasi terdegradasi**. Anda harus menghapus blue/green penyebaran dan semua database hijau, lalu membuatnya kembali. | 
| Pernyataan bahasa kontrol data (DCL), seperti GRANT danREVOKE, tidak direplikasi dari lingkungan biru ke lingkungan hijau. | Jika RDS PostgreSQL mendeteksi upaya untuk mengeksekusi pernyataan DCL di lingkungan biru, Anda akan melihat pesan peringatan. Tidak ada konfigurasi atau API yang tersedia untuk mengubah perilaku ini, karena ini merupakan batasan dari proses blue/green penerapan. | 
| Operasi NEXTVAL pada objek urutan tidak disinkronkan antara lingkungan biru dan lingkungan hijau. | Selama switchover, Amazon RDS menambah nilai urutan di lingkungan hijau agar sesuai dengan yang ada di lingkungan biru. Sementara volume urutan yang tinggi umumnya memungkinkan peralihan untuk dilanjutkan, jumlah yang sangat besar—seperti beberapa ratus ribu—dapat menyebabkan proses habis sebelum selesai. Anda dapat meningkatkan batas waktu peralihan untuk memungkinkan lebih banyak waktu untuk sinkronisasi. Untuk informasi selengkapnya, lihat [Waktu habis switchover](blue-green-deployments-switching.md#blue-green-deployments-switching-timeout). | 
| Objek besar di lingkungan biru tidak direplikasi ke lingkungan hijau. Ini termasuk objek besar yang ada dan objek besar yang baru dibuat atau dimodifikasi selama proses blue/green penyebaran. | Jika Amazon RDS mendeteksi pembuatan atau perubahan objek besar di lingkungan biru yang disimpan dalam tabel sistem `pg_largeobject`, basis data hijau Anda memasukkan status **Replikasi terdegradasi**. Anda harus menghapus blue/green penyebaran dan semua database hijau, lalu membuatnya kembali. | 
| Tampilan terwujud tidak disegarkan secara otomatis di lingkungan hijau. | Menyegarkan tampilan terwujud di lingkungan biru tidak akan menyegarkannya di lingkungan hijau. Setelah peralihan, Anda dapat menyegarkannya secara manual menggunakan perintah REFRESH [MATERIALIZED VIEW, atau menjadwalkan penyegaran](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html). | 
| Operasi UPDATE dan DELETE tidak diizinkan pada tabel yang tidak memiliki kunci primer. | Sebelum Anda membuat blue/green penerapan, pastikan bahwa semua tabel memiliki kunci utama atau penggunaan`REPLICA IDENTITY FULL`. Namun, gunakan hanya `REPLICA IDENTITY FULL` jika tidak ada kunci primer atau unik, karena memengaruhi kinerja replikasi. Untuk informasi selengkapnya, lihat [Dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). | 

## Pertimbangan untuk penerapan blue/green
<a name="blue-green-deployments-consider"></a>

Amazon RDS melacak sumber daya dalam blue/green penerapan dengan `DbiResourceId` dari setiap sumber daya. ID sumber daya ini adalah pengenal AWS Region-unik dan tidak dapat diubah untuk sumber daya.

ID *sumber daya* terpisah dari ID *instance* ** DB. Masing-masing tercantum dalam konfigurasi database di konsol RDS.

Nama (ID instans) sumber daya berubah saat Anda mengalihkan blue/green penerapan, tetapi setiap sumber daya menyimpan ID sumber daya yang sama. Misalnya, pengidentifikasi instans DB mungkin adalah `mydb` di lingkungan biru. Setelah switchover, instans DB yang sama mungkin diganti namanya menjadi `mydb-old1`. Namun, ID sumber daya instans DB tidak berubah selama switchover. Jadi, saat Anda mengganti sumber daya hijau menjadi sumber daya produksi baru, ID sumber daya mereka tidak cocok dengan ID sumber daya biru yang sebelumnya diproduksi.

Setelah Anda mengalihkan blue/green penerapan, pertimbangkan untuk memperbarui ID sumber daya ke sumber daya produksi yang baru ditransisi untuk fitur dan layanan terintegrasi yang Anda gunakan dengan sumber daya produksi. Secara khusus, pertimbangkan pembaruan berikut:
+ Jika Anda melakukan pemfilteran menggunakan API RDS dan ID sumber daya, sesuaikan ID sumber daya yang digunakan dalam pemfilteran setelah switchover.
+ Jika Anda menggunakan CloudTrail untuk mengaudit sumber daya, sesuaikan konsumen CloudTrail untuk melacak ID sumber daya baru setelah peralihan. Untuk informasi selengkapnya, lihat [Memantau Amazon RDS AWS CloudTrail](logging-using-cloudtrail.md).
+ Jika Anda menggunakan API Wawasan Performa, sesuaikan ID sumber daya dalam panggilan ke API setelah switchover. Untuk informasi selengkapnya, lihat [Memantau muatan DB dengan Wawasan Performa di Amazon RDS](USER_PerfInsights.md).

  Anda dapat memantau basis data dengan nama yang sama setelah switchover, tetapi basis data tersebut tidak berisi data sebelum switchover.
+ Jika Anda menggunakan ID sumber daya dalam kebijakan IAM, pastikan Anda menambahkan ID sumber daya dari sumber daya yang baru ditransisi bila diperlukan. Untuk informasi selengkapnya, lihat [Manajemen identitas dan akses untuk Amazon RDS](UsingWithRDS.IAM.md).
+ Jika Anda memiliki peran IAM yang terkait dengan instans  Anda, pastikan untuk mengasosiasikannya kembali setelah peralihan. Peran terlampir tidak secara otomatis disalin ke lingkungan hijau.
+ Jika Anda mengautentikasi instans DB menggunakan [ autentikasi basis data IAM](UsingWithRDS.IAMDBAuth.md), pastikan kebijakan IAM yang digunakan untuk akses basis data memiliki basis data biru dan hijau yang tercantum di elemen `Resource` kebijakan. Ini diperlukan agar dapat terhubung ke basis data hijau setelah switchover. Untuk informasi selengkapnya, lihat [Membuat dan menggunakan kebijakan IAM untuk akses basis data IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
+ Jika Anda menggunakannya AWS Backup untuk mengelola pencadangan otomatis sumber daya dalam blue/green penerapan, sesuaikan ID sumber daya yang digunakan setelah peralihan. AWS Backup Untuk informasi selengkapnya, lihat [Menggunakan AWS Backup untuk mengelola cadangan otomatis untuk Amazon RDS](AutomatedBackups.AWSBackup.md).
+ Jika Anda ingin memulihkan snapshot DB manual atau otomatis untuk instans DB yang merupakan bagian dari blue/green penerapan, pastikan Anda memulihkan snapshot DB yang benar dengan memeriksa waktu ketika snapshot diambil. Untuk informasi selengkapnya, lihat [Memulihkan ke instans DB](USER_RestoreFromSnapshot.md).
+ Jika Anda ingin menjelaskan pencadangan otomatis instans DB lingkungan biru sebelumnya atau memulihkannya ke waktu tertentu, gunakan ID sumber daya untuk operasi tersebut.

  Karena nama instans DB berubah selama switchover, Anda tidak dapat menggunakan nama sebelumnya untuk operasi `DescribeDBInstanceAutomatedBackups` atau `RestoreDBInstanceToPointInTime`.

  Untuk informasi selengkapnya, lihat [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md).
+ Saat Anda menambahkan replika baca ke instans DB di lingkungan hijau blue/green penerapan, replika baca baru tidak akan menggantikan replika baca di lingkungan biru saat Anda beralih. Namun, replika baca baru dipertahankan di lingkungan produksi baru setelah switchover.
+ Setelah Anda beralih, AWS Database Migration Service (AWS DMS) tugas replikasi tidak dapat dilanjutkan karena pos pemeriksaan dari lingkungan biru tidak valid di lingkungan hijau. Anda harus membuat ulang tugas DMS dengan pos pemeriksaan baru untuk melanjutkan replikasi.
+ Saat menghapus instans DB di lingkungan hijau blue/green penerapan, Anda tidak dapat membuat instans DB baru untuk menggantikannya dalam blue/green penerapan.

  Jika Anda membuat instans DB baru dengan nama yang sama dan Amazon Resource Name (ARN) dengan instans DB yang dihapus, instans tersebut memiliki `DbiResourceId` yang berbeda, jadi instans tersebut bukan bagian dari lingkungan hijau.

  Perilaku berikut akan terjadi jika Anda menghapus instans DB di lingkungan hijau:
  + Jika ada instans DB di lingkungan biru dengan nama yang sama, instans tersebut tidak akan switchover ke instans DB di lingkungan hijau. Instans DB ini tidak akan diganti namanya dengan menambahkan `-old{{n}}` ke nama instans DB tersebut.
  + Aplikasi apa pun yang menunjuk ke instans DB di lingkungan biru terus menggunakan instans DB yang sama setelah switchover.

  Perilaku yang sama berlaku untuk instans DB dan replika baca.
+ Jika Anda menggunakan tag sumber daya untuk kontrol akses atau manajemen operasional, Anda perlu memahami bahwa perubahan tag tidak disinkronkan antara lingkungan biru dan hijau hingga peralihan. Saat Anda membuat blue/green penerapan, tag dari lingkungan biru disalin ke lingkungan hijau. Setelah pembuatan, modifikasi tag apa pun yang Anda buat pada salah satu lingkungan tidak disinkronkan secara otomatis. Selama peralihan, tag lingkungan biru menggantikan semua tag di lingkungan hijau. Terapkan semua tag yang diperlukan ke lingkungan biru sebelum Anda membuat blue/green penerapan, atau menerapkan kembali tag yang diperlukan ke lingkungan produksi baru setelah peralihan. Untuk informasi selengkapnya tentang tag, lihat [Menandai sumber Amazon RDS](USER_Tagging.md).