Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Ikhtisar Amazon Blue/Green Aurora Dengan menggunakan Amazon Blue/Green Aurora Deployment, Anda dapat membuat dan menguji perubahan database 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* pementasan dan tetap sinkron dengan lingkungan produksi saat ini. 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. Saat siap, Anda dapat *beralih ke* lingkungan untuk mentransisikan 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, Aurora PostgreSQL, dan Aurora Global Database. Untuk ketersediaan Amazon RDS, lihat [Ikhtisar Blue/Green Penerapan Amazon RDS di Panduan Pengguna](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html) *Amazon* RDS. **Topics** + [Wilayah dan ketersediaan versi](#blue-green-deployments-region-version-availability) + [Manfaat menggunakan Amazon RDS Blue/Green Deployment](#blue-green-deployments-benefits) + [Alur kerja penerapan blue/green](#blue-green-deployments-major-steps) + [Mengotorisasi akses ke operasi penyebaran Amazon blue/green Aurora](blue-green-deployments-authorizing-access.md) + [Keterbatasan dan pertimbangan untuk penerapan Aurora blue/green](blue-green-deployments-considerations.md) + [Praktik terbaik untuk penerapan Amazon blue/green Aurora](blue-green-deployments-best-practices.md) ## Wilayah dan ketersediaan versi Ketersediaan dan dukungan fitur bervariasi di seluruh versi spesifik dari setiap mesin basis data, dan di seluruh Wilayah AWS. Untuk informasi selengkapnya, lihat [Daerah yang Didukung dan mesin Aurora DB untuk Deployment Blue/Green](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md). ## Manfaat menggunakan Amazon RDS Blue/Green Deployment Dengan menggunakan Amazon RDS Blue/Green Deployment, Anda dapat tetap mengikuti patch keamanan, meningkatkan kinerja database, dan mengadopsi fitur database yang lebih baru dengan waktu henti yang singkat dan dapat diprediksi. Blue/green penerapan mengurangi risiko dan waktu henti untuk pembaruan basis data, seperti peningkatan versi mesin utama 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 penerapan blue/green Selesaikan langkah-langkah utama berikut saat Anda menggunakan blue/green penerapan untuk pembaruan cluster Aurora DB. 1. Identifikasi klaster DB produksi yang memerlukan pembaruan. Gambar berikut menunjukkan contoh klaster DB produksi. ![\[Produksi (biru) Aurora DB cluster dalam penerapan blue/green\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png) 1. Buat blue/green penyebaran. Untuk petunjuk, lihat [Membuat blue/green penyebaran di ](blue-green-deployments-creating.md). Gambar berikut menunjukkan contoh blue/green penerapan lingkungan produksi dari langkah 1. Saat membuat blue/green penyebaran, RDS menyalin topologi lengkap dan konfigurasi cluster 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 cluster DB (auroradb-green-). **abc123** Ini juga berisi tiga instance DB di cluster DB (auroradb-instance1-green-, auroradb-instance2-green-, dan auroradb-instance3-green-)**abc123**. **abc123** **abc123** ![\[Deployment blue/green untuk Amazon Aurora\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png) Saat Anda membuat blue/green penerapan, Anda dapat menentukan versi mesin DB yang lebih tinggi dan grup parameter cluster DB yang berbeda untuk cluster 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 blue/green penyebaran, cluster DB di lingkungan hijau tidak mengizinkan operasi tulis secara default. Namun, ini tidak berlaku untuk pengguna yang memiliki `CONNECTION_ADMIN` hak istimewa, termasuk pengguna master Aurora. Pengguna dengan hak istimewa ini dapat mengesampingkan perilaku tersebut. `read_only` Untuk informasi selengkapnya, lihat [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). 1. Buat perubahan pada lingkungan pementasan. Misalnya, Anda dapat mengubah kelas instans DB yang digunakan oleh satu atau lebih instance DB di lingkungan hijau. Untuk informasi tentang memodifikasi klaster DB, lihat [Memodifikasi klaster DB Amazon Aurora](Aurora.Modifying.md). 1. 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 ke`0`, lalu reboot instance DB. Untuk Aurora PostgreSQL, atur parameter ke level sesi. `default_transaction_read_only` `off` 1. Saat siap, beralih ke transisi lingkungan pementasan menjadi lingkungan produksi baru. Untuk petunjuknya, lihat [Mengalihkan blue/green penerapan di ](blue-green-deployments-switching.md). 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. ![\[Cluster DB dan instans DB setelah beralih ke penerapan Amazon Aurora blue/green\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png) 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 dialihkan, tidak memerlukan perubahan pada aplikasi Anda. 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`. 1. Jika Anda tidak lagi membutuhkan blue/green penerapan, Anda dapat menghapusnya. Untuk petunjuknya, lihat [Menghapus blue/green penerapan di Amazon Aurora](blue-green-deployments-deleting.md). Setelah switchover, lingkungan produksi sebelumnya tidak dihapus sehingga Anda dapat menggunakannya untuk pengujian regresi, jika perlu. # Mengotorisasi akses ke operasi penyebaran Amazon blue/green Aurora 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](UsingWithRDS.IAM.md). Pengguna yang membuat blue/green penerapan harus memiliki izin untuk melakukan operasi RDS berikut: + `rds:CreateBlueGreenDeployment` + `rds:AddTagsToResource` + `rds:CreateDBCluster` + `rds:CreateDBInstance` + `rds:CreateDBClusterEndpoint` Pengguna yang mengalihkan blue/green penerapan harus memiliki izin untuk melakukan operasi RDS berikut: + `rds:SwitchoverBlueGreenDeployment` + `rds:ModifyDBCluster` + `rds:PromoteReadReplicaDBCluster` Pengguna yang menghapus blue/green penerapan harus memiliki izin untuk melakukan operasi RDS berikut: + `rds:DeleteBlueGreenDeployment` + `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 seperti`my-db-prefix-*`. Hanya wildcard (\$1) 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.](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html) ## Izin tambahan untuk Penerapan Basis Data Global Aurora Blue/Green Saat membuat blue/green penerapan untuk klaster Aurora Global Database, selain izin yang tercantum di atas, pengguna memerlukan izin berikut untuk melakukan operasi untuk mengelola topologi cluster global. Pengguna yang membuat blue/green penerapan harus memiliki izin untuk melakukan operasi RDS berikut: + `rds:CreateGlobalCluster` Pengguna yang mengalihkan blue/green penerapan harus memiliki izin untuk melakukan operasi RDS berikut: + `rds:ModifyGlobalCluster` + `rds:PromoteReadReplicaDBCluster` Pengguna yang menghapus blue/green penerapan harus memiliki izin untuk melakukan operasi RDS berikut: + `rds:DeleteGlobalCluster` # Keterbatasan dan pertimbangan untuk penerapan Aurora blue/green Penerapan biru/hijau 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) + [Batasan Aurora Global Database untuk penyebaran blue/green](#blue-green-deployments-limitations-agd) + [Pertimbangan untuk penerapan blue/green](#blue-green-deployments-consider) ## Batasan untuk blue/green penerapan Batasan berikut berlaku untuk blue/green penerapan. **Topics** + [Batasan umum untuk blue/green penerapan](#blue-green-deployments-limitations-general) + [Aurora MySQL untuk batasan MySQL untuk penerapan blue/green](#blue-green-deployments-limitations-mysql) + [Aurora PostgreSQL RDS untuk batasan PostgreSQL](#blue-green-deployments-limitations-postgres-logical) ### Batasan umum untuk blue/green penerapan Batasan umum berikut berlaku untuk blue/green penerapan: + Anda tidak dapat menghentikan dan memulai cluster yang merupakan bagian dari blue/green penerapan. + Penerapan biru/hijau tidak mendukung pengelolaan kata sandi pengguna utama dengan. AWS Secrets Manager + Jika Anda mencoba memaksa backtrack pada cluster DB biru, blue/green penerapan akan rusak dan peralihan diblokir. + 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. + Kebijakan Auto Scaling yang dikonfigurasi pada cluster DB biru tidak disalin ke lingkungan hijau. Anda harus mengkonfigurasi ulang mereka setelah peralihan, terlepas dari apakah mereka awalnya diatur di lingkungan biru atau hijau. + Anda tidak dapat mengubah klaster DB yang tidak terenkripsi menjadi klaster DB yang terenkripsi. + Anda tidak dapat mengubah cluster DB biru ke versi engine yang lebih tinggi daripada cluster DB hijau yang sesuai. + Sumber daya di lingkungan biru dan lingkungan hijau harus berada dalam Akun AWS yang sama. + Deployment blue/green tidak didukung untuk fitur berikut: + Proksi Amazon RDS + Replika baca Lintas Wilayah + Klaster DB Aurora Serverless v1 + CloudFormation ### Aurora MySQL untuk batasan MySQL untuk penerapan blue/green blue/green + Cluster DB sumber tidak dapat berisi database apa pun bernama`tmp`. Basis data dengan nama ini tidak akan disalin ke lingkungan hijau. + Cluster DB biru tidak bisa menjadi replika binlog eksternal. + Jika cluster DB sumber yang memiliki backtrack diaktifkan, cluster DB hijau dibuat tanpa dukungan backtracking. Ini karena backtracking tidak berfungsi dengan replikasi log biner (binlog), yang diperlukan untuk penerapan. blue/green Untuk informasi selengkapnya, lihat [Melakukan backtracking klaster DB Aurora](AuroraMySQL.Managing.Backtrack.md). + Penerapan biru/hijau tidak mendukung Driver AWS 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. ### Aurora PostgreSQL RDS untuk batasan PostgreSQL + Tabel [yang tidak tercatat](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) tidak direplikasi ke lingkungan hijau kecuali `rds.logically_replicate_unlogged_tables` parameter disetel ke `1` pada cluster DB biru. Jangan mengubah nilai parameter ini setelah Anda membuat blue/green penerapan untuk menghindari kemungkinan kesalahan replikasi pada tabel yang tidak tercatat. + Cluster DB biru tidak bisa menjadi sumber logis (penerbit) atau replika (pelanggan). + 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. + 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 . Dampaknya tergantung pada faktor-faktor seperti beban kerja database dan jumlah koneksi. + Penerapan biru/hijau didukung untuk Babelfish untuk Aurora PostgreSQL hanya untuk versi 15.7 dan versi 15 yang lebih tinggi, dan 16.3 dan versi 16 yang lebih tinggi. + 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](AuroraPostgreSQL.QPM.Plancapturereplicas.md). + [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) atau replikasi logis yang dikelola [sendiri](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html). + 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. + 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](AuroraPostgreSQL.Optimize.overview.md). + `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 pgAudit ekstensi](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md). #### Keterbatasan spesifik replikasi logis untuk penerapan blue/green Tabel berikut menjelaskan batasan replikasi logis yang berlaku untuk deployment blue/green Aurora PostgreSQL. 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 Aurora 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 Aurora Amazon 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, 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. | | 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 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**. Anda harus menghapus blue/green penyebaran dan semua database hijau, lalu membuatnya kembali. | | Menyegarkan tampilan terwujud merusak replikasi. | Pemandangan terwujud yang menyegarkan di lingkungan biru memecah replikasi ke lingkungan hijau. Menahan diri dari menyegarkan pandangan terwujud di lingkungan biru. 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). | ## Batasan Aurora Global Database untuk penyebaran blue/green Selain batasan umum dan spesifik mesin yang disebutkan di atas, batasan berikut berlaku untuk blue/green penerapan untuk Aurora Global Database: + Semua operasi harus dimulai dari Wilayah yang sama dengan cluster penulis Database Global. + Melakukan peralihan global atau failover global akan menyebabkan blue/green penyebaran aktif menjadi tidak valid. Penerapan biru-hijau perlu dihapus dan dibuat ulang dari wilayah primer baru. + Untuk Aurora PostgreSQL, jika Anda mengaktifkan penerusan penulisan global di lingkungan produksi dan membuat blue/green penerapan, penerusan tulis dinonaktifkan di klaster hijau. Ini diaktifkan di lingkungan hijau hanya setelah blue/green peralihan ketika lingkungan hijau menjadi lingkungan produksi baru. Setelah peralihan, penerusan tulis dinonaktifkan di cluster. `-old1` + Memodifikasi topologi database global setelah pembuatan penyebaran akan menyebabkan blue/green blue/green penyebaran aktif menjadi tidak valid. Penyebaran biru-hijau harus dihapus dan dibuat ulang dari wilayah primer baru. + Snapshot otomatis dipertahankan per hari retensi cadangan yang awalnya dikonfigurasi di lingkungan biru tua. Snapshot otomatis dari cluster biru tua tidak disalin ke hijau. + Failover global didukung blue/green selama peralihan tetapi peralihan global tidak didukung selama peralihan. blue/green + Pastikan cluster DB dan grup parameter DB untuk lingkungan hijau ada di semua wilayah sekunder dengan nama yang identik. Jika grup parameter di wilayah mana pun tidak tersedia, grup parameter default di wilayah digunakan. + Hindari menggunakan RDS Proxy pada setiap anggota database global selama peralihan blue/green penerapan. ## Pertimbangan untuk penerapan blue/green Amazon RDS melacak sumber daya dalam blue/green penerapan 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 ** *cluster* DB. Masing-masing tercantum dalam konfigurasi database di konsol RDS. Nama (ID klaster) sumber daya berubah saat Anda mengalihkan blue/green penerapan, 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 Anda mengganti sumber daya hijau menjadi sumber daya produksi baru, sumber daya mereka IDs tidak cocok dengan sumber daya biru IDs yang sebelumnya dalam produksi. Setelah Anda mengalihkan blue/green penerapan, pertimbangkan untuk memperbarui sumber daya IDs 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 RDS API dan sumber daya IDs, sesuaikan sumber daya yang IDs digunakan dalam pemfilteran setelah peralihan. + Jika Anda menggunakan CloudTrail untuk mengaudit sumber daya, sesuaikan konsumen CloudTrail untuk melacak sumber daya baru IDs setelah peralihan. Untuk informasi selengkapnya, lihat [Memantau panggilan Amazon Aurora API AWS CloudTrail](logging-using-cloudtrail.md). + 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 [Daerah yang Didukung dan mesin Aurora DB untuk aliran aktivitas database](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md). + Jika Anda menggunakan API Performance Insights, sesuaikan sumber daya IDs dalam panggilan ke API setelah peralihan. Untuk informasi selengkapnya, lihat [Memantau muatan DB dengan Wawasan Performa di Amazon Aurora](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 sumber daya IDs dalam kebijakan IAM, pastikan Anda menambahkan sumber daya sumber daya IDs yang baru dialihkan bila diperlukan. Untuk informasi selengkapnya, lihat [Manajemen identitas dan akses untuk Amazon Aurora](UsingWithRDS.IAM.md). + 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](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 ingin memulihkan snapshot cluster DB manual untuk cluster DB yang merupakan bagian dari blue/green penerapan, pastikan Anda memulihkan snapshot cluster DB yang benar dengan memeriksa waktu ketika snapshot diambil. Untuk informasi selengkapnya, lihat [Memulihkan dari snapshot klaster DB](aurora-restore-snapshot.md). + 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. + 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](Aurora.Managing.Clone.md). + 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 cluster DB di lingkungan hijau blue/green deployment, you can't create a new DB instance to replace it in the blue/green penerapan. 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. + 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 daya Amazon Aurora dan Amazon RDS](USER_Tagging.md). # Praktik terbaik untuk penerapan Amazon blue/green Aurora Berikut ini adalah praktik terbaik untuk blue/green penerapan. **Topics** + [Praktik terbaik umum untuk blue/green penerapan](#blue-green-deployments-best-practices-general) + [praktik terbaik untuk penerapan blue/green](#blue-green-deployments-best-practices-mysql) + [Praktik terbaik Aurora PostgreSQL untuk penerapan blue/green](#blue-green-deployments-best-practices-postgres) + [Aurora Global Database praktik terbaik untuk penerapan blue/green](#blue-green-deployments-best-practices-agd) ## Praktik terbaik umum untuk blue/green penerapan Pertimbangkan praktik terbaik umum berikut saat Anda membuat penerapan biru/hijau. + 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. + Jika Anda menggunakan blue/green penerapan untuk mengimplementasikan perubahan skema, buat hanya perubahan yang kompatibel dengan replikasi. Misalnya, Anda dapat menambahkan kolom baru di akhir tabel tanpa mengganggu replikasi dari penerapan biru ke penerapan 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](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) di dokumentasi MySQL dan [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) 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 blue/green penerapan, ikuti praktik terbaik peralihan. Untuk informasi selengkapnya, lihat [Praktik terbaik switchover](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices). ## praktik terbaik untuk penerapan blue/green Pertimbangkan praktik terbaik berikut saat Anda membuat blue/green penerapan dari . + Jika lingkungan hijau mengalami kelambatan replika, pertimbangkan hal berikut: + Nonaktifkan retensi log biner jika tidak diperlukan, atau nonaktifkan sementara hingga replikasi menyusul. Untuk melakukannya, atur kembali parameter cluster `binlog_format` DB `0` dan reboot instance DB penulis hijau. + Setel sementara `innodb_flush_log_at_trx_commit` parameter ke dalam kelompok parameter DB hijau. Setelah replikasi menyusul, kembalikan ke nilai default sebelum peralihan. `1` Jika terjadi shutdown atau crash yang tidak terduga dengan nilai parameter sementara, bangun kembali lingkungan hijau untuk menghindari kerusakan data yang tidak terdeteksi. Untuk informasi selengkapnya, lihat [Mengonfigurasi seberapa sering buffer log di-flush](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). ## Praktik terbaik Aurora PostgreSQL untuk penerapan blue/green Pertimbangkan praktik terbaik berikut saat Anda membuat blue/green penerapan dari klaster DB PostgreSQL Aurora. + Pantau cache penulisan replikasi logis Aurora PostgreSQL dan buat penyesuaian pada buffer cache jika perlu. Untuk informasi selengkapnya, lihat [Memantau cache tulis-melalui replikasi logis Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache). + Tingkatkan nilai parameter `logical_decoding_work_mem` DB di lingkungan biru. Tindakan ini memungkinkan lebih sedikit decoding pada disk, alih-alih menggunakan memori. Untuk informasi selengkapnya, lihat [Menyesuaikan memori kerja untuk pendekodean logis](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem). + Anda dapat memantau overflow transaksi yang ditulis ke disk menggunakan `ReplicationSlotDiskUsage` CloudWatch metrik. Metrik ini menawarkan wawasan tentang penggunaan disk slot replikasi, membantu mengidentifikasi kapan data transaksi melebihi kapasitas memori dan disimpan di disk. Anda dapat memantau memori yang dapat dibebaskan dengan `FreeableMemory` CloudWatch metrik. Untuk informasi selengkapnya, lihat [Metrik tingkat instans untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). + Di Aurora PostgreSQL versi 14 dan lebih tinggi, Anda dapat memantau ukuran file luapan logis menggunakan tampilan sistem. `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` + Perbarui semua ekstensi PostgreSQL Anda ke versi terbaru sebelum Anda membuat penerapan. blue/green Untuk informasi selengkapnya, lihat [Meningkatkan ekstensi PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). + Jika Anda menggunakan `aws_s3` ekstensi, berikan akses cluster 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](postgresql-s3-export-access-bucket.md). + Jika Anda menentukan versi engine yang lebih tinggi untuk lingkungan hijau, jalankan `ANALYZE` operasi di semua database untuk menyegarkan `pg_statistic` tabel. Statistik pengoptimal tidak ditransfer selama peningkatan versi utama, jadi Anda harus membuat ulang semua statistik untuk menghindari masalah kinerja. Untuk praktik terbaik tambahan selama peningkatan versi utama, lihat[Melakukan upgrade versi utama](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md). + Hindari mengonfigurasi pemicu sebagai `ENABLE REPLICA` atau `ENABLE ALWAYS` jika pemicu digunakan pada sumber untuk memanipulasi data. Jika tidak, sistem replikasi menyebarkan perubahan dan mengeksekusi pemicu, yang mengarah ke duplikasi. + Transaksi yang berjalan lama dapat menyebabkan kelambatan replika yang signifikan. Untuk mengurangi lag replika, pertimbangkan untuk melakukan hal berikut: + Kurangi transaksi jangka panjang dan subtransaksi yang dapat ditunda hingga setelah lingkungan hijau mengejar lingkungan biru. + Kurangi operasi massal di lingkungan biru sampai setelah lingkungan hijau mengejar lingkungan biru. + Memulai operasi pembekuan vakum manual pada tabel sibuk sebelum membuat blue/green penerapan. Untuk petunjuk, lihat [Melakukan pembekuan vakum manual](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html). + Dalam PostgreSQL versi 12 dan lebih tinggi, nonaktifkan parameter `index_cleanup` pada tabel besar atau sibuk untuk meningkatkan efisiensi pemeliharaan rutin pada database biru. Untuk informasi selengkapnya, lihat [Memvakum tabel secepat mungkin](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing). **catatan** Melewatkan pembersihan indeks secara teratur selama menyedot debu dapat menyebabkan indeks kembung, yang dapat menurunkan kinerja pemindaian. Sebagai praktik terbaik, gunakan pendekatan ini hanya saat menggunakan blue/green penerapan. Setelah penerapan selesai, kami sarankan untuk melanjutkan pemeliharaan dan pembersihan indeks reguler. + Replica lag dapat terjadi jika instance DB biru dan hijau berukuran terlalu kecil untuk beban kerja. Pastikan instans DB Anda tidak mencapai batas sumber dayanya untuk jenis instans. Untuk informasi selengkapnya, lihat [Menggunakan CloudWatch metrik Amazon untuk menganalisis penggunaan sumber daya untuk Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md). + Replikasi yang lambat dapat menyebabkan pengirim dan penerima sering memulai ulang, yang menunda sinkronisasi. Untuk memastikan bahwa mereka tetap aktif, nonaktifkan batas waktu dengan menyetel `wal_sender_timeout` parameter ke `0` dalam lingkungan biru, dan `wal_receiver_timeout` parameter ke `0` dalam lingkungan hijau. + Tinjau kinerja pernyataan UPDATE dan DELETE Anda dan evaluasi apakah membuat indeks pada kolom yang digunakan dalam klausa WHERE dapat mengoptimalkan kueri ini. Ini dapat meningkatkan kinerja saat operasi diputar ulang di lingkungan hijau. Untuk informasi selengkapnya, lihat [Memeriksa filter predikat untuk kueri yang menghasilkan peristiwa tunggu](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters). + Jika Anda menggunakan pemicu, pastikan mereka tidak mengganggu pembuatan, pembaruan, dan penghapusan, `pg_catalog.pg_publication``pg_catalog.pg_subscription`, dan `pg_catalog.pg_replication_slots` objek yang namanya dimulai dengan 'rds'. + Jika Babelfish diaktifkan pada cluster DB sumber, parameter berikut harus memiliki pengaturan yang sama di grup parameter cluster DB target untuk lingkungan hijau seperti pada grup parameter cluster DB sumber: + rds.babelfish\$1status + babelfishpg\$1tds.tds\$1default\$1numeric\$1precision + babelfishpg\$1tds.tds\$1default\$1numeric\$1scale + babelfishpg\$1tsql.default\$1locale + babelfishpg\$1tsql.migration\$1mode + babelfishpg\$1tsql.server\$1collation\$1name Untuk informasi selengkapnya tentang parameter ini, lihat [Pengaturan grup parameter klaster DB untuk Babelfish](babelfish-configuration.md). ## Aurora Global Database praktik terbaik untuk penerapan blue/green Selain praktik terbaik umum dan khusus mesin yang tercantum di atas, pertimbangkan praktik terbaik berikut untuk Aurora Global Database. + Pantau CloudWatch metrik berikut untuk mengidentifikasi periode aktivitas rendah di lingkungan produksi Anda: + `DatabaseConnections` + `ActiveTransactions` Jadwalkan blue/green peralihan selama jendela pemeliharaan yang direncanakan atau selama periode aktivitas rendah. + Blue/Green switchover duration varies based on your workload and the number of secondary regions. When you initiate a blue/greenswitchover, layanan menunggu lag replika mencapai nol sebelum melanjutkan. Kami merekomendasikan untuk memeriksa lag replika sebelum memulai peralihan. + Jika Anda bermaksud menggunakan parameter DB atau grup parameter Cluster DB selain yang default untuk lingkungan hijau Anda, buat grup parameter yang diinginkan dengan nama yang sama di semua wilayah sekunder sebelum memulai blue/green penerapan.