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 biru/hijau
Penerapan biru/hijau di RDS Amazon 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 penyebaran untuk memastikan waktu henti minimal, transisi yang mulus, dan pengelolaan lingkungan database Anda yang efektif.
Batasan untuk deployment blue/green
Batasan berikut berlaku untuk deployment blue/green.
Topik
Batasan umum untuk deployment blue/green
Batasan umum berikut berlaku untuk deployment blue/green:
-
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.
-
Jika Anda mencoba memaksa backtrack pada cluster DB biru, penerapan biru/hijau akan rusak dan peralihan diblokir.
-
Selama peralihan, lingkungan biru dan hijau tidak dapat memiliki ETL integrasi nol 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.
-
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 sama Akun AWS.
-
Deployment blue/green tidak didukung untuk fitur berikut:
-
RDSProksi Amazon
-
Replika baca Lintas Wilayah
-
Aurora Serverless v1 Klaster DB
-
Klaster DB yang merupakan bagian dari basis data global Aurora
-
AWS CloudFormation
-
Aurora My SQL RDS for My SQL
Batasan berikut berlaku untuk penerapan SQL biru/hijau saya:
-
Aurora SQL Versi saya 2.08 dan 2.09 tidak didukung sebagai sumber pemutakhiran atau versi target.
-
Cluster DB sumber tidak dapat berisi database apa pun yang 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 biru/hijau. Untuk informasi selengkapnya, lihat Melakukan backtracking klaster DB Aurora.
-
Penerapan biru/hijau tidak mendukung AWS JDBCSopir untuk sayaSQL. Untuk informasi selengkapnya, lihat Batasan yang Diketahui
pada GitHub.
Aurora Postgre SQL RDS untuk batasan Postgre untuk penerapan
Batasan berikut berlaku untuk penyebaran SQL biru/hijau Postgre:
-
Versi Aurora Postgre SQL berikut didukung sebagai sumber peningkatan dan versi target: 11.21 dan lebih tinggi, 12.16 dan lebih tinggi, 13.12 dan lebih tinggi, 14.9 dan lebih tinggi, 15.4 dan lebih tinggi, dan 16.1 dan lebih tinggi. Untuk versi yang lebih rendah, Anda dapat melakukan peningkatan versi minor ke versi yang didukung.
-
Tabel yang tidak tercatat
tidak direplikasi ke lingkungan hijau kecuali rds.logically_replicate_unlogged_tables
parameter disetel ke1
pada cluster DB biru. Sebaiknya Anda tidak mengubah nilai parameter ini setelah membuat deployment blue/green untuk menghindari kemungkinan kesalahan replikasi pada tabel yang tidak tercatat. -
Cluster DB biru tidak dapat berupa sumber logis yang dikelola sendiri (penerbit) atau replika (pelanggan).
-
Jika cluster DB biru dikonfigurasi sebagai server asing dari ekstensi pembungkus data asing (FDW), Anda harus menggunakan nama titik akhir cluster alih-alih alamat IP. Hal ini memungkinkan konfigurasi untuk tetap berfungsi setelah switchover.
-
Dalam penyebaran biru/hijau, 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.
-
Ekstensi
pg_partman
harus dinonaktifkan di lingkungan biru saat Anda membuat deployment blue/green. Ekstensi melakukan DDL operasi sepertiCREATE TABLE
, yang mematahkan 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 parameterapg_plan_mgmt.capture_plan_baselines
yang diatur keoff
di semua basis data hijau untuk menghindari konflik kunci primer jika rencana yang identik ditangkap di lingkungan biru. Untuk informasi selengkapnya, lihat Ikhtisar manajemen rencana kueri Aurora Postgre SQL.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 Menangkap rencana eksekusi Aurora SQL Postgre di Replika. Ekstensi
pgactive
danpglogical
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 pgAudit ekstensi.
Batasan replikasi SQL logis Postgre untuk penerapan biru/hijau
Deployment blue/green menggunakan replikasi logis agar lingkungan pementasan tetap sinkron dengan lingkungan produksi.
Batasan | Penjelasan |
---|---|
Pernyataan bahasa definisi data (DDL), seperti CREATE TABLE danCREATE SCHEMA , tidak direplikasi dari lingkungan biru ke lingkungan hijau. |
Jika Aurora mendeteksi DDL perubahan di lingkungan biru, database hijau Anda memasukkan status Replikasi terdegradasi. Anda menerima acara yang memberi tahu Anda bahwa DDL perubahan 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 peralihan, 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 modifikasi objek besar di lingkungan biru yang disimpan dalam tabel 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 peralihan, Anda dapat menyegarkannya secara manual menggunakan REFRESHMATERIALIZEDVIEW |
UPDATEdan DELETE operasi tidak diizinkan pada tabel yang tidak memiliki kunci utama. |
Sebelum Anda membuat deployment blue/green, pastikan semua tabel di klaster DB memiliki kunci primer. |
Untuk informasi selengkapnya, lihat Pembatasan
Pertimbangan untuk deployment blue/green
Amazon RDS melacak sumber daya dalam penerapan biru/hijau dengan DbiResourceId
dan DbClusterResourceId
dari setiap sumber daya. ID sumber daya ini adalah Wilayah AWS-unik, pengidentifikasi abadi untuk sumber daya.
ID sumber daya terpisah dari ID cluster DB. Masing-masing tercantum dalam konfigurasi database di RDS konsol.
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, sumber daya mereka IDs tidak cocok dengan sumber daya biru IDs yang sebelumnya dalam produksi.
Setelah Anda mengalihkan penerapan biru/hijau, pertimbangkan untuk memperbarui sumber daya IDs 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 sumber daya RDS API danIDs, 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 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 Daerah yang Didukung dan mesin Aurora DB untuk aliran aktivitas database.
-
Jika Anda menggunakan Performance InsightsAPI, sesuaikan sumber daya IDs dalam panggilan ke peralihan API setelah. Untuk informasi selengkapnya, lihat Memantau beban DB dengan Performance Insights di Amazon Aurora.
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 IAM kebijakan, pastikan Anda menambahkan sumber daya IDs sumber daya yang baru dipromosikan bila diperlukan. Untuk informasi selengkapnya, lihat Manajemen identitas dan akses untuk Aurora.
-
Jika Anda memiliki IAM peran yang terkait dengan Anda, pastikan untuk mengasosiasikannya kembali setelah peralihan. Peran terlampir tidak secara otomatis disalin ke lingkungan hijau.
-
Jika Anda mengautentikasi ke cluster DB menggunakan otentikasi IAM database, pastikan IAM kebijakan yang digunakan untuk akses database memiliki database biru dan hijau yang tercantum di bawah
Resource
elemen 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 yang sama dan ARN sebagai instans DB yang dihapus, itu memiliki yang berbeda
DbiResourceId
, jadi itu 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
-old
ke nama instans DB.n
-
Aplikasi apa pun yang menunjuk ke instans DB di lingkungan biru terus menggunakan instans DB yang sama setelah switchover.
-