Gambaran Umum Deployment Blue/Green Amazon RDS

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.

rds:AddTagsToResource

rds:CreateDBInstanceReadReplica

rds:ModifyDBInstance

rds:PromoteReadReplica

rds:DeleteDBInstance

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 RDS di AWS CloudTrail.

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.

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 RDS.

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, 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 menggunakannya AWS Backup untuk mengelola pencadangan otomatis sumber daya dalam penerapan biru/hijau, sesuaikan ID sumber daya yang digunakan setelah peralihan. AWS Backup Untuk informasi selengkapnya, lihat Menggunakan AWS Backup untuk mengelola backup otomatis.

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

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 dengan waktu yang ditentukan.

Saat Anda menambahkan replika baca ke instans DB di lingkungan hijau dari deployment blue/green, replika baca baru tidak akan menggantikan replika baca di lingkungan biru saat Anda switch over. Namun, replika baca baru dipertahankan di lingkungan produksi baru setelah switchover.

Jika Anda menghapus instans 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 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:

Perilaku yang sama berlaku untuk instans DB dan replika baca.

Uji instans DB 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 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 di dokumentasi MySQL dan Restrictions dalam dokumentasi replikasi logis PostgreSQL.

Setelah Anda membuat deployment blue/green, tangani pemuatan lambat jika perlu. Pastikan pemuatan data selesai sebelum switchover. Untuk informasi selengkapnya, lihat Menangani pemuatan lambat saat Anda membuat deployment blue/green.

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

Hindari menggunakan mesin penyimpanan non-transaksional, seperti MyISAM, yang tidak dioptimalkan untuk replikasi.

Optimalkan replika baca untuk replikasi log biner.

Misalnya, jika versi mesin DB Anda mendukungnya, sebaiknya gunakan replikasi GTID, replikasi paralel, dan replikasi aman dari crash di lingkungan produksi Anda sebelum men-deploy deployment blue/green. Opsi ini mendukung konsistensi dan daya tahan data Anda sebelum switchover deployment blue/green. Untuk informasi selengkapnya tentang replikasi GTID untuk replika baca, lihat Penggunaan replikasi berbasis GTID.

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 Metrik CloudWatch tingkat instans Amazon untuk Amazon RDS.

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 instans 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.

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 Cara melakukan peningkatan versi mayor.

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:

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.

Untuk mencegah segmen write-ahead log (WAL) dihapus dari lingkungan biru, atur wal_keep_segments parameter ke 15625 untuk PostgreSQL versi 13 dan yang lebih rendah. Untuk versi 14 dan lebih tinggi, atur wal_keep_size parameternya juga 1 TiB, jika ada cukup ruang penyimpanan kosong.

MySQL versi 8.0.11 hingga 8.0.13 memiliki bug komunitas yang mencegahnya mendukung deployment blue/green.

Versi berikut dari RDS for PostgreSQL didukung sebagai versi target dan sumber peningkatan: 11.21 dan yang lebih tinggi, 12.16 dan yang lebih tinggi, 13.12 dan yang lebih tinggi, 14.9 dan yang lebih tinggi, serta 15.4 dan yang lebih tinggi. Untuk versi yang lebih rendah, Anda dapat melakukan peningkatan versi minor ke versi yang didukung.

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

Jika volume log khusus (DLV) diaktifkan pada database biru, itu harus diaktifkan pada semua instance DB, termasuk replika baca.

Untuk RDS for PostgreSQL, tabel yang tidak tercatat tidak direplikasi ke lingkungan hijau.

Untuk , instans DB lingkungan biru tidak dapat berupa sumber logis (penerbit) 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.

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:

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.

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.

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.

Anda tidak dapat mengubah instans DB yang tidak terenkripsi menjadi instans DB yang terenkripsi.

Anda tidak dapat mengubah instans DB yang terenkripsi menjadi instans DB yang tidak terenkripsi.

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

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

Untuk RDS for MySQL, jika basis data sumber dikaitkan dengan grup opsi kustom, Anda tidak dapat menentukan peningkatan versi mayor saat Anda membuat deployment blue/green.

Dalam hal ini, Anda dapat membuat deployment blue/green tanpa menentukan peningkatan versi mayor. Kemudian, Anda dapat meningkatkan basis data di lingkungan hijau. Untuk informasi selengkapnya, lihat Meningkatkan versi mesin instans DB.