Gambaran Umum Deployment Blue/Green Amazon RDS untuk Aurora

Dengan menggunakan Deployment Blue/Green Amazon RDS, Anda dapat membuat dan menguji perubahan basis data sebelum menerapkannya di lingkungan produksi. Deployment blue/green menciptakan lingkungan pementasan yang menyalin lingkungan produksi. Dalam deployment blue/green, lingkungan biru adalah lingkungan produksi saat ini. Lingkungan hijau adalah lingkungan pementasannya. Lingkungan pementasan tetap sinkron dengan lingkungan produksi saat ini menggunakan replikasi logis.

Anda dapat membuat perubahan pada klaster DB Aurora di lingkungan hijau tanpa memengaruhi beban kerja produksi. Misalnya, Anda dapat meningkatkan versi mesin DB mayor atau minor atau mengubah parameter basis data di lingkungan pementasannya. Anda dapat menguji perubahan di lingkungan hijau secara menyeluruh. Setelah siap, Anda dapat melakukan switchover lingkungan untuk mempromosikan lingkungan hijau menjadi lingkungan produksi baru. Switchover biasanya memakan waktu kurang dari satu menit tanpa kehilangan data dan tidak perlu mengubah aplikasi.

Karena lingkungan hijau adalah salinan topologi lingkungan dari produksi, klaster DB dan semua instans DB-nya disalin dalam deployment. Lingkungan hijau juga mencakup fitur yang digunakan oleh klaster DB, seperti snapshot klaster DB, Wawasan Performa, Pemantauan yang Ditingkatkan, dan Aurora Serverless v2.

catatan

Penerapan Biru/Hijau didukung untuk Aurora MySQL dan Aurora PostgreSQL. Untuk ketersediaan Amazon RDS, lihat Menggunakan Amazon RDS Blue/Green Deployment untuk pembaruan database di Panduan Pengguna Amazon RDS.

Manfaat menggunakan Deployment Blue/Green Amazon RDS

Dengan menggunakan Deployment Blue/Green Amazon RDS, Anda dapat tetap mengikuti perkembangan patch keamanan, meningkatkan performa basis data, dan mengadopsi fitur basis data yang lebih baru dengan waktu henti yang singkat dan dapat diprediksi. Deployment blue/green mengurangi risiko dan waktu henti untuk pembaruan basis data, seperti peningkatan versi mesin mayor atau minor.

Deployment blue/green memberikan manfaat berikut:

• Memudahkan pembuatan lingkungan pementasan siap produksi.

• Mereplikasi otomatis perubahan basis data dari lingkungan produksi ke lingkungan pementasan.

• Menguji perubahan basis data di lingkungan pementasan yang aman tanpa memengaruhi lingkungan produksi.

• Anda dapat mengikuti perkembangan terbaru dengan patch basis data dan pembaruan sistem.

• Menerapkan dan menguji fitur basis data yang lebih baru.

• Melakukan switchover pada lingkungan pementasan untuk menjadi lingkungan produksi baru tanpa perubahan pada aplikasi.

• Melakukan switchover dengan aman melalui penggunaan pagar pembatas switchover default.

• Tidak ada kehilangan data selama switchover.

• Melakukan switchover dengan cepat, biasanya kurang dari satu menit tergantung beban kerja Anda.

Alur kerja deployment blue/green

Selesaikan langkah-langkah utama berikut saat Anda menggunakan deployment blue/green untuk pembaruan klaster DB Aurora.

1. Identifikasi klaster DB produksi yang memerlukan pembaruan.

   Gambar berikut menunjukkan contoh klaster DB produksi.

   

2. Buat deployment blue/green. Untuk petunjuknya, lihat Membuat deployment blue/green.

   Gambar berikut menunjukkan contoh deployment blue/green pada lingkungan produksi dari langkah 1. Saat membuat deployment blue/green, RDS menyalin topologi lengkap dan konfigurasi klaster Aurora DB untuk menciptakan lingkungan hijau. Nama-nama klaster DB dan instans DB yang disalin ditambahkan dengan -green-random-characters. Lingkungan pementasan dalam gambar berisi klaster DB (auroradb-green-abc123). Gambar tersebut juga berisi tiga instans DB dalam klaster DB (auroradb-instance1-green-abc123, auroradb-instance2-green-abc123, dan auroradb-instance3-green-abc123).

   

   Saat membuat deployment blue/green, Anda dapat menentukan versi mesin DB yang lebih tinggi dan grup parameter klaster DB yang berbeda untuk klaster DB di lingkungan hijau. Anda juga dapat menentukan grup parameter DB yang berbeda untuk instans DB di klaster DB.

   RDS juga mengonfigurasi replikasi dari instans DB primer di lingkungan biru ke instans DB primer di lingkungan hijau.

   penting

   Untuk Aurora MySQL versi 3, setelah Anda membuat penyebaran biru/hijau, cluster DB di lingkungan hijau memungkinkan operasi tulis secara default. Kami menyarankan Anda membuat cluster DB hanya-baca dengan menyetel read_only parameter ke 1 dan me-reboot cluster.

3. Buat perubahan pada lingkungan pementasan.

   Misalnya, Anda dapat membuat perubahan skema pada basis data Anda atau mengubah kelas instans DB yang digunakan oleh satu atau beberapa instans DB di lingkungan hijau.

   Untuk informasi tentang memodifikasi klaster DB, lihat Memodifikasi klaster DB Amazon Aurora.

4. Uji lingkungan pementasan Anda.

   Selama pengujian, sebaiknya pertahankan basis data Anda di lingkungan hijau agar hanya dapat dibaca saja. Aktifkan operasi tulis di lingkungan hijau dengan hati-hati karena dapat mengakibatkan konflik replikasi. Hal ini juga dapat menghasilkan data yang tidak diinginkan dalam basis data produksi setelah switchover. Untuk mengaktifkan operasi tulis untuk Aurora MySQL, atur read_only parameternya ke0, lalu reboot instance DB. Untuk Aurora PostgreSQL, atur parameter ke level sesi. default_transaction_read_only off

5. Saat siap, lakukan switchover untuk mempromosikan lingkungan pementasan menjadi lingkungan produksi baru. Untuk petunjuknya, lihat Mengganti deployment blue/green.

   Switchover menyebabkan waktu henti. Waktu henti biasanya kurang dari satu menit, tetapi bisa lebih lama tergantung beban kerja Anda.

   Gambar berikut menunjukkan klaster DB setelah switchover.

   

   Setelah switchover, klaster DB Aurora di lingkungan hijau menjadi klaster DB produksi baru. Nama dan titik akhir di lingkungan produksi saat ini ditetapkan ke lingkungan produksi yang baru dipromosikan, sehingga Anda tidak perlu melakukan perubahan pada aplikasi. Akibatnya, lalu lintas produksi Anda sekarang mengalir ke lingkungan produksi baru. Klaster DB dan instans DB di lingkungan biru diganti namanya dengan menambahkan -oldn ke nama saat ini, dengan n adalah angka. Misalnya, anggap nama instans DB di lingkungan biru adalah auroradb-instance-1. Setelah switchover, nama instans DB bisa jadi auroradb-instance-1-old1.

   Dalam contoh pada gambar, perubahan berikut terjadi selama switchover:

   • Klaster DB lingkungan hijau auroradb-green-abc123 menjadi klaster DB produksi bernama auroradb.

   • Instans DB lingkungan hijau bernama auroradb-instance1-green-abc123 menjadi instans DB produksi auroradb-instance1.

   • Instans DB lingkungan hijau bernama auroradb-instance2-green-abc123 menjadi instans DB produksi auroradb-instance2.

   • Instans DB lingkungan hijau bernama auroradb-instance3-green-abc123 menjadi instans DB produksi auroradb-instance3.

   • Klaster DB lingkungan biru bernama auroradb menjadi auroradb-old1.

   • Instans DB lingkungan biru bernama auroradb-instance1 menjadi auroradb-instance1-old1.

   • Instans DB lingkungan biru bernama auroradb-instance2 menjadi auroradb-instance2-old1.

   • Instans DB lingkungan biru bernama auroradb-instance3 menjadi auroradb-instance3-old1.

6. Jika Anda tidak lagi memerlukan deployment blue/green, Anda dapat menghapusnya. Untuk petunjuknya, lihat Menghapus deployment blue/green.

   Setelah switchover, lingkungan produksi sebelumnya tidak dihapus sehingga Anda dapat menggunakannya untuk pengujian regresi, jika perlu.

Mengizinkan akses ke operasi deployment blue/green

Pengguna harus memiliki izin yang diperlukan untuk melakukan operasi yang terkait dengan deployment blue/green. Anda dapat membuat kebijakan IAM yang memberi izin kepada pengguna dan peran untuk menjalankan operasi API tertentu pada sumber daya yang diperlukan. Anda kemudian dapat melampirkan kebijakan tersebut ke set izin IAM atau peran yang memerlukan izin tersebut. Untuk informasi selengkapnya, lihat Manajemen identitas dan akses untuk Amazon Aurora.

Pengguna yang membuat deployment blue/green harus memiliki izin untuk menjalankan operasi RDS berikut:

• rds:AddTagsToResource

• rds:CreateDBCluster

• rds:CreateDBInstance

• rds:CreateDBClusterEndpoint

Pengguna yang melakukan switchover pada deployment blue/green harus memiliki izin untuk menjalankan operasi RDS berikut:

• rds:ModifyDBCluster

• rds:PromoteReadReplicaDBCluster

Pengguna yang menghapus deployment blue/green harus memiliki izin untuk menjalankan operasi RDS berikut:

• rds:DeleteDBCluster

• rds:DeleteDBInstance

• rds:DeleteDBClusterEndpoint

Aurora menyediakan dan memodifikasi sumber daya di lingkungan pementasan atas nama Anda. Sumber daya ini mencakup instance DB yang menggunakan konvensi penamaan yang ditentukan secara internal. Oleh karena itu, kebijakan IAM terlampir tidak dapat berisi pola nama sumber daya sebagian sepertimy-db-prefix-*. Hanya wildcard (*) yang didukung. Secara umum, sebaiknya gunakan tag sumber daya dan atribut lain yang didukung untuk mengontrol akses ke sumber daya ini, bukan wildcard. Untuk informasi selengkapnya, lihat Kunci tindakan, sumber daya, dan kondisi untuk Amazon RDS.

Pertimbangan untuk deployment blue/green

Amazon RDS melacak sumber daya di deployment blue/green dengan DbiResourceId dan DbClusterResourceId dari setiap sumber daya. ID sumber daya ini adalah pengenal Wilayah AWS-unik dan tidak dapat diubah untuk sumber daya.

ID sumber daya terpisah dari ID instans DB:

Nama (ID klaster) sumber daya berubah saat Anda switchover deployment blue/green, tetapi setiap sumber daya menyimpan ID sumber daya yang sama. Misalnya, pengidentifikasi klaster DB mungkin adalah mycluster di lingkungan biru. Setelah switchover, klaster DB yang sama mungkin diganti namanya menjadi mycluster-old1. Namun, ID sumber daya klaster DB tidak berubah selama switchover. Jadi, ketika sumber daya hijau dipromosikan menjadi sumber daya produksi baru, ID sumber dayanya tidak cocok dengan ID sumber daya biru yang sebelumnya diproduksi.

Setelah switchover deployment blue/green, sebaiknya perbarui ID sumber daya ke sumber daya produksi yang baru dipromosikan 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 panggilan API Amazon Aurora di AWS CloudTrail.

• Jika Anda menggunakan Stream Aktivitas Basis Data untuk sumber daya di lingkungan biru, sesuaikan aplikasi Anda untuk memantau peristiwa basis data aliran baru setelah switchover. Untuk informasi selengkapnya, lihat Aliran aktivitas basis data di Aurora.

• 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 Aurora.

  Anda dapat memantau basis data dengan nama yang sama setelah switchover, tetapi basis data tersebut tidak berisi data sebelum switchover.

• Jika menggunakan ID sumber daya dalam kebijakan IAM, pastikan Anda menambahkan ID sumber daya dari sumber daya yang baru dipromosikan jika diperlukan. Untuk informasi selengkapnya, lihat Manajemen identitas dan akses untuk Amazon Aurora.

• Jika Anda memiliki peran IAM yang terkait dengan Anda, pastikan untuk mengasosiasikannya kembali setelah peralihan. Peran terlampir tidak secara otomatis disalin ke lingkungan hijau.

• Jika Anda mengautentikasi klaster DB menggunakan autentikasi basis data IAM, 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.

• Jika Anda ingin memulihkan snapshot klaster DB manual untuk klaster DB yang merupakan bagian dari deployment blue/green, pastikan Anda memulihkan snapshot klaster DB yang benar dengan memeriksa waktu ketika snapshot diambil. Untuk informasi selengkapnya, lihat Memulihkan dari snapshot klaster DB.

• Amazon Aurora menciptakan lingkungan hijau dengan mengkloning volume penyimpanan Aurora yang mendasarinya di lingkungan biru. Volume klaster hijau hanya menyimpan perubahan tambahan yang dilakukan pada lingkungan hijau. Jika Anda menghapus klaster DB di lingkungan biru, ukuran volume penyimpanan Aurora yang mendasarinya di lingkungan hijau meningkat ke ukuran penuh. Untuk informasi selengkapnya, lihat Mengkloning volume untuk klaster DB Amazon Aurora.

• Saat Anda menambahkan instans DB ke klaster DB di lingkungan hijau deployment blue/green, instans DB baru tidak akan menggantikan instans DB di lingkungan biru saat Anda switchover. Namun, instans DB baru dipertahankan di klaster DB dan menjadi instans DB di lingkungan produksi baru.

• Saat Anda menghapus instans DB di klaster DB di lingkungan hijau deployment blue/green, Anda tidak dapat membuat instans DB baru untuk menggantikannya dalam deployment blue/green.

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

  Perilaku berikut terjadi jika Anda menghapus instans DB di klaster 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 -oldn ke nama instans DB.

  • Aplikasi apa pun yang menunjuk ke instans DB di lingkungan biru terus menggunakan instans DB yang sama setelah switchover.

Praktik terbaik untuk deployment blue/green

Berikut ini adalah praktik terbaik untuk deployment blue/green:

Praktik terbaik umum

• Uji klaster DB Aurora secara menyeluruh di lingkungan hijau sebelum switchover.

• Simpan basis data Anda di lingkungan hijau dengan kondisi hanya baca. Sebaiknya Anda mengaktifkan operasi tulis di lingkungan hijau dengan hati-hati karena dapat mengakibatkan konflik replikasi. Hal ini juga dapat menghasilkan data yang tidak diinginkan dalam basis data produksi setelah switchover.

• Saat menggunakan deployment blue/green untuk mengimplementasikan perubahan skema, hanya buat perubahan yang kompatibel dengan replikasi.

  Misalnya, Anda dapat menambahkan kolom baru di akhir tabel, membuat indeks, atau menghapus indeks tanpa mengganggu replikasi dari deployment biru ke deployment hijau. Namun, perubahan skema, seperti penggantian nama kolom atau nama tabel, memecah replikasi ke deployment hijau.

  Untuk informasi selengkapnya tentang perubahan yang kompatibel dengan replikasi, lihat Replication with Differing Table Definitions on Source and Replica di dokumentasi MySQL dan Restrictions dalam dokumentasi replikasi logis PostgreSQL.

• Gunakan titik akhir klaster, titik akhir pembaca, atau titik akhir kustom untuk semua koneksi di kedua lingkungan. Jangan gunakan titik akhir instans atau titik akhir kustom dengan daftar statis atau pengecualian.

• Saat Anda mengalihkan deployment blue/green, ikuti praktik terbaik switchover. Untuk informasi selengkapnya, lihat Praktik terbaik switchover.

Praktik terbaik Aurora PostgreSQL

• Pantau cache penulisan replikasi logis Aurora PostgreSQL dan buat penyesuaian pada buffer cache jika perlu. Untuk informasi selengkapnya, lihat Mengelola cache write-through replikasi logis Aurora PostgreSQL.

• Jika database Anda memiliki memori freeable yang cukup, tingkatkan nilai parameter logical_decoding_work_mem DB di lingkungan biru. Tindakan ini memungkinkan lebih sedikit decoding pada disk, alih-alih menggunakan memori. Anda dapat memantau memori yang dapat dibebaskan dengan FreeableMemory CloudWatch metrik. Untuk informasi selengkapnya, lihat CloudWatch Metrik Amazon untuk Amazon Aurora.

• Perbarui semua ekstensi PostgreSQL Anda ke versi terbaru sebelum membuat deployment blue/green. Untuk informasi selengkapnya, lihat Meningkatkan ekstensi PostgreSQL.

• Jika Anda menggunakan ekstensi aws_s3, pastikan Anda memberikan akses klaster DB hijau ke Amazon S3 melalui peran IAM setelah lingkungan hijau dibuat. Hal ini memungkinkan perintah impor dan ekspor untuk terus berfungsi setelah switchover. Untuk petunjuknya, lihat Menyiapkan akses ke bucket Amazon S3.

Ketersediaan wilayah dan versi

Ketersediaan fitur dan dukungan bervariasi di seluruh versi spesifik dari setiap mesin basis data, dan di seluruh bagian Wilayah AWS. Untuk informasi selengkapnya tentang versi dan ketersediaan Wilayah dengan Deployment Blue/Green Amazon RDS, lihat Deployment Blue/Green.

Batasan untuk deployment blue/green

Batasan berikut berlaku untuk deployment blue/green.

Topik

• Batasan umum untuk deployment blue/green
• Batasan ekstensi PostgreSQL untuk deployment blue/green
• Batasan untuk perubahan dalam deployment blue/green
• Batasan replikasi logis PostgreSQL untuk deployment blue/green

Batasan umum untuk deployment blue/green

Batasan umum berikut berlaku untuk deployment blue/green:

• Aurora MySQL versi 2.08 dan 2.09 tidak didukung sebagai sumber peningkatan atau versi target.

• Anda tidak dapat berhenti dan memulai klaster yang merupakan bagian dari deployment blue/green.

• Penerapan biru/hijau tidak mendukung pengelolaan kata sandi pengguna utama dengan. AWS Secrets Manager

• Untuk Aurora MySQL, klaster DB sumber tidak dapat berisi basis data yang bernama tmp. Basis data dengan nama ini tidak akan disalin ke lingkungan hijau.

• Untuk Aurora PostgreSQL, tabel yang tidak tercatat tidak direplikasi ke lingkungan hijau kecuali parameter rds.logically_replicate_unlogged_tables diatur ke 1 pada klaster DB biru. Sebaiknya Anda tidak mengubah nilai parameter ini setelah membuat deployment blue/green untuk menghindari kemungkinan kesalahan replikasi pada tabel yang tidak tercatat.

• Untuk Aurora PostgreSQL RDS untuk PostgreSQLpenerbit) atau replika (pelanggan) yang dikelola sendiri.

• 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 Peristiwa (parameter event_scheduler) harus dinonaktifkan di lingkungan hijau saat Anda membuat deployment blue/green. Ini mencegah peristiwa dihasilkan di lingkungan hijau dan menyebabkan inkonsistensi.

• Kebijakan Auto Scaling Aurora apa pun yang ditentukan pada klaster DB biru tidak akan disalin ke lingkungan hijau.

• Penerapan biru/hijau tidak mendukung Driver AWS JDBC untuk MySQL. Untuk informasi selengkapnya, lihat Batasan yang Diketahui pada GitHub.

• Deployment blue/green tidak didukung untuk fitur berikut:

  • Proksi Amazon RDS

  • Replika baca Lintas Wilayah

  • Klaster DB Aurora Serverless v1

  • Klaster DB yang merupakan bagian dari basis data global Aurora

  • Babelfish for Aurora PostgreSQL

  • AWS CloudFormation

Batasan ekstensi PostgreSQL untuk deployment blue/green

Batasan berikut berlaku untuk ekstensi PostgreSQL:

• Ekstensi pg_partman harus dinonaktifkan di lingkungan biru saat Anda membuat deployment blue/green. Ekstensi tersebut menjalankan operasi DDL seperti CREATE TABLE, yang memecah replikasi logis dari lingkungan biru ke lingkungan hijau.

• Ekstensi pg_cron harus tetap dinonaktifkan di semua basis data hijau setelah deployment blue/green dibuat. Ekstensi tersebut memiliki pekerja latar belakang yang berjalan sebagai superuser dan melewati pengaturan hanya baca di lingkungan hijau, yang dapat menyebabkan konflik replikasi.

• Ekstensi apg_plan_mgmt harus memiliki parameter apg_plan_mgmt.capture_plan_baselines yang diatur ke off di semua basis data hijau untuk menghindari konflik kunci primer jika rencana yang identik ditangkap di lingkungan biru. Untuk informasi selengkapnya, lihat Gambaran umum manajemen rencana kueri Aurora PostgreSQL.

  Jika ingin menangkap rencana eksekusi di Aurora Replicas, Anda harus memberikan titik akhir klaster DB biru saat memanggil fungsi apg_plan_mgmt.create_replica_plan_capture. Ini memastikan bahwa pengambilan rencana terus berfungsi setelah switchover. Untuk informasi selengkapnya, lihat Mengambil rencana eksekusi Aurora PostgreSQL di Replika.

• Jika klaster DB biru dikonfigurasi sebagai server asing dari ekstensi pembungkus data asing (FDW), Anda harus menggunakan nama titik akhir klaster, alih-alih alamat IP. Hal ini memungkinkan konfigurasi untuk tetap berfungsi setelah switchover.

• Ekstensi pg_active dan pglogical harus dinonaktifkan di lingkungan biru saat Anda membuat deployment blue/green. Setelah Anda mempromosikan 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 pgAdit.

Batasan untuk perubahan dalam deployment blue/green

Berikut ini adalah batasan untuk perubahan dalam deployment blue/green:

• Anda tidak dapat mengubah klaster DB yang tidak terenkripsi menjadi klaster DB yang terenkripsi.

• Anda tidak dapat mengubah klaster DB yang terenkripsi menjadi klaster DB yang tidak terenkripsi.

• Anda tidak dapat mengubah klaster DB lingkungan biru ke versi mesin yang lebih tinggi daripada klaster DB lingkungan hijau yang sesuai.

• Sumber daya di lingkungan biru dan lingkungan hijau harus berada dalam Akun AWS yang sama.

• Jika lingkungan biru berisi kebijakan Aurora Auto Scaling, kebijakan tersebut tidak disalin ke lingkungan hijau. Anda harus menambahkan kembali kebijakan tersebut secara manual ke lingkungan hijau.

Batasan replikasi logis PostgreSQL untuk deployment blue/green

Deployment blue/green menggunakan replikasi logis agar lingkungan pementasan tetap sinkron dengan lingkungan produksi. PostgreSQL memiliki batasan tertentu yang terkait dengan replikasi logis, yang diterjemahkan ke batasan saat membuat deployment blue/green untuk klaster DB Aurora PostgreSQL.

Tabel berikut menjelaskan batasan replikasi logis yang berlaku untuk deployment blue/green Aurora PostgreSQL.

Batasan	Penjelasan
Pernyataan bahasa definisi data (DDL), seperti CREATE TABLE dan CREATE SCHEMA, tidak direplikasi dari lingkungan biru ke lingkungan hijau.	Jika Aurora mendeteksi perubahan DDL di lingkungan biru, basis data hijau Anda memasukkan status Replikasi terdegradasi. Anda menerima peristiwa yang memberi tahu bahwa perubahan DDL di lingkungan biru tidak dapat direplikasi ke lingkungan hijau. Anda harus menghapus deployment blue/green dan semua basis data hijau, lalu buat kembali semuanya. Jika tidak, Anda tidak dapat switchover deployment blue/green.
Operasi NEXTVAL pada objek urutan tidak disinkronkan antara lingkungan biru dan lingkungan hijau.	Selama switchover, Aurora menambah nilai urutan di lingkungan hijau agar sesuai dengan yang ada di lingkungan biru. Jika Anda memiliki ribuan urutan, hal ini dapat menunda switchover.
Pembuatan atau perubahan objek besar di lingkungan biru tidak direplikasi ke lingkungan hijau.	Jika Aurora mendeteksi pembuatan atau perubahan objek besar di lingkungan biru yang disimpan dalam tabel sistem pg_largeobject, basis data hijau Anda memasukkan status Replikasi terdegradasi. Aurora menghasilkan peristiwa yang memberi tahu Anda bahwa perubahan objek besar di lingkungan biru tidak dapat direplikasi ke lingkungan hijau. Anda harus menghapus deployment blue/green dan semua basis data hijau, lalu buat kembali semuanya. Jika tidak, Anda tidak dapat switchover deployment blue/green.
Tampilan terwujud tidak secara otomatis disegarkan di lingkungan hijau.	Menyegarkan tampilan terwujud di lingkungan biru tidak akan menyegarkannya di lingkungan hijau. Setelah switchover, Anda dapat menjadwalkan penyegaran tampilan terwujud.
Operasi UPDATE dan DELETE tidak diizinkan pada tabel yang tidak memiliki kunci primer.	Sebelum Anda membuat deployment blue/green, pastikan semua tabel di klaster DB memiliki kunci primer.

Untuk informasi selengkapnya, lihat Restrictions di dokumentasi replikasi logis PostgreSQL.