View a markdown version of this page

Keterbatasan dan pertimbangan untuk Amazon Aurora blue/green penyebaran - Amazon Aurora
BatasanBatasan Database Global Aurora untuk pener blue/green apanPertimbangan-pertimbangan

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

Keterbatasan dan pertimbangan untuk Amazon Aurora blue/green penyebaran

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 Anda untuk memastikan waktu henti minimal, transisi yang mulus, dan pengelolaan lingkungan database yang efektif.

Batasan untuk pener blue/green apan

Batasan berikut berlaku untuk pener blue/green apan.

Batasan umum untuk pener blue/green apan

Batasan umum berikut berlaku untuk pener blue/green apan:

  • Anda tidak dapat menghentikan dan memulai cluster yang merupakan bagian dari blue/green penerapan.

  • Blue/green penerapan tidak mendukung pengelolaan kata sandi pengguna utama dengan. AWS Secrets Manager

  • Jika Anda mencoba memaksa backtrack pada cluster DB biru, penerapan akan terputus dan blue/green 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.

  • Event Scheduler (event_schedulerparameter) harus dinonaktifkan pada lingkungan hijau saat Anda membuat blue/green penerapan. Ini mencegah peristiwa dihasilkan di lingkungan hijau dan menyebabkan inkonsistensi.

  • Kebijakan Penskalaan Otomatis yang dikonfigurasi pada cluster DB biru tidak disalin ke lingkungan hijau. Anda harus mengonfigurasinya ulang setelah peralihan, terlepas dari apakah mereka awalnya diatur pada lingkungan biru atau hijau.

  • Anda tidak dapat mengubah klaster DB yang tidak terenkripsi menjadi klaster DB yang terenkripsi. Selain itu, Anda tidak dapat mengubah menjadi cluster instans DB yang tidak dien

  • Anda tidak dapat mengubah ke versi engine yang lebih tinggi daripada .

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

  • Jika Anda menggunakan Amazon RDS Proxy, Anda harus mendaftarkan cluster biru Anda dengan proxy sebelum membuat blue/green penerapan. Jika blue/green penerapan sudah ada untuk cluster biru tertentu, mendaftarkan cluster biru itu ke Amazon RDS Proxy akan diblokir.

  • Amazon RDS Proxy dengan blue/green penerapan tidak didukung untuk Database Global Aurora.

  • Blue/green penerapan tidak didukung untuk fitur-fitur berikut:

    • Cross-Region baca replika

    • Klaster DB Aurora Serverless v1

    • CloudFormation

  • Setelah Anda mengalihkan blue/green penerapan, riwayat pemulihan point-in-time (PITR) tidak terbawa ke cluster DB produksi baru. Cluster DB hijau menyimpan ID sumber dayanya sendiri. Waktu paling awal yang dapat dipulihkan dimulai ketika Anda menciptakan lingkungan hijau. Anda tidak dapat memulihkan cluster DB produksi baru ke titik waktu apa pun sebelum itu, termasuk kapan saja sebelum peralihan. Cluster DB biru menyimpan riwayat PITR sendiri dan cadangan otomatis sampai Anda menghapusnya. Untuk mengembalikan cluster DB biru setelah peralihan, gunakan ID sumber dayanya (SourceDbClusterResourceId), bukan namanya. Nama berubah selama peralihan. Untuk informasi selengkapnya, lihat Memulihkan klaster DB ke waktu tertentu.

penting

Rencanakan pengaturan ulang PITR ini jika Anda memiliki persyaratan retensi cadangan atau tujuan titik pemulihan (RPO). Cluster DB produksi baru tidak dapat mencapai titik pemulihan dari sebelum Anda membuat lingkungan hijau, dan jendela PITR-nya mencapai periode retensi cadangan penuh Anda hanya setelah cukup waktu berlalu.

Untuk menjaga kemampuan pemulihan ke waktu sebelum peralihan, jangan segera hapus cluster DB biru. Jaga agar cluster DB biru berjalan setidaknya selama jendela pemulihan yang Anda butuhkan. Cluster DB biru yang dipertahankan masih dikenakan biaya untuk instans DB dan penyimpanan sampai Anda menghapusnya.

Aurora MySQL batasan untuk pener blue/green apan

Batasan berikut berlaku untuk Aurora MySQL blue/green :

  • Cluster DB sumber tidak dapat berisi database apa pun yang diberi namatmp. Basis data dengan nama ini tidak akan disalin ke lingkungan hijau.

  • dapat 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 blue/green penerapan. Untuk informasi selengkapnya, lihat Melakukan backtracking klaster DB Aurora.

  • Blue/green penerapan tidak mendukung Driver AWS JDBC untuk MySQL. Untuk informasi selengkapnya, lihat Batasan yang Diketahui pada GitHub.

Aurora PostgreSQL batasan untuk pener blue/green apan

Batasan berikut berlaku untuk Aurora PostgreSQL blue/green.

  • Tabel yang tidak dicatat 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 dicatat.

  • 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 penerapan, setiap database memerlukan slot replikasi logis. Seiring bertambahnya jumlah database, overhead sumber daya meningkat dan berpotensi menyebabkan jeda replikasi, terutama jika instance DB cluster cukup diskalakan. Dampaknya tergantung pada faktor-faktor seperti beban kerja database dan jumlah koneksi. Untuk mengurangi hal ini, pertimbangkan untuk meningkatkan kelas instance DB Anda atau mengurangi jumlah database pada cluster sumber.

  • Blue/green penerapan 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.

  • Proses penerapan replik asi logis di lingkungan hijau adalah single-thread. Jika lingkungan biru menghasilkan volume lalu lintas tulis yang tinggi, lingkungan hijau mungkin tidak dapat mengikutinya. Hal ini dapat menyebabkan jeda atau kegagalan replikasi, terutama untuk beban kerja yang menghasilkan throughput tulis tinggi yang terus menerus. Pastikan untuk menguji beban kerja Anda secara menyeluruh. Untuk skenario yang memerlukan peningkatan versi utama dan penanganan beban kerja penulisan volume tinggi, pertimbangkan pendekatan alternatif seperti menggunakan AWS Database Migration Service (AWS DMS) atau replikasi logis yang dikelola sendiri.

  • Membuat partisi baru pada tabel yang dipartisi tidak didukung selama penerapan blue/green Aurora Membuat partisi baru melibatkan operasi bahasa definisi data (DDL) sepertiCREATE 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:

    • Ek pg_partman stensi 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.

    • Ek pg_cron stensi 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.

    • Ek pglogical sten pgactive si dan harus dinonaktifkan di lingkungan biru saat Anda membuat blue/green penerapan. Setelah Anda mengalihkan 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 kustom untuk instans DB biru dan hijau. Untuk informasi selengkapnya, lihat Menyiapkan ekstensi pgAudit.

Batasan spesifik replikasi logis untuk penerapan blue/green

PostgreSQL memiliki batasan tertentu yang terkait dengan replikasi logis, yang diterjemahkan menjadi batasan saat membuat penerapan untuk cluster

Tabel berikut menjelaskan batasan replikasi logis yang berlaku untuk penerapan Aurora PostgreSQL blue/green RDS untuk PostgreSQL Untuk informasi selengkapnya, lihat Restrictions 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 penerapan 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 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 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. 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.
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 penerapan.

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 penerapan dan semua database hijau, lalu membuatnya kembali.

Menyegarkan tampilan yang terwujud merusak replikasi.

Menyegarkan tampilan terwujud di lingkungan biru memecah replikasi ke lingkungan hijau. Menahan diri dari menyegarkan pandangan yang terwujud di lingkungan biru. Setelah peralihan, Anda dapat menyegarkannya secara manual menggunakan perintah REFRESH MATERIALIZED VIEW, atau menjadwalkan penye garan.

Operasi UPDATE dan DELETE tidak diizinkan pada tabel yang tidak memiliki kunci primer.

Sebelum membuat blue/green penerapan, pastikan semua tabel memiliki kunci utama atau penggunaanREPLICA IDENTITY FULL. Namun, gunakan hanya REPLICA IDENTITY FULL jika tidak ada kunci utama atau unik, karena ini mempengaruhi kinerja replikasi. Untuk informasi selengkapnya, lihat Dokumentasi PostgreSQL.

Batasan Database Global Aurora untuk pener blue/green apan

Selain batasan umum dan spesifik mesin yang dinyatakan di atas, batasan berikut berlaku untuk penerapan blue/green 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 penerapan aktif menjadi blue/green tidak valid. Penyebaran biru-hijau perlu dihapus dan dibuat ulang dari wilayah utama baru.

  • Untuk Aurora PostgreSQL, jika Anda mengaktifkan penerusan tulis global di lingkungan produksi Anda dan membuat penerapan, blue/green penerusan tulis dinonaktifkan pada cluster hijau. Ini diaktifkan di lingkungan hijau hanya setelah per blue/green alihan ketika lingkungan hijau menjadi lingkungan produksi baru. Setelah peralihan, penerusan tulis dinonaktifkan pada -old1 cluster.

  • Memodifikasi topologi database global setelah pembuatan penerapan blue/green akan menyebabkan penerapan aktif blue/green menjadi tidak valid. Penyebaran biru-hijau harus dihapus dan dibuat ulang dari wilayah utama baru.

  • Snapshot otomatis dipertahankan per hari penyimpanan cadangan yang awalnya dikonfigurasi di lingkungan biru tua. Snapshot otomatis dari cluster biru tua tidak disalin ke hijau.

  • Failover global didukung selama peral blue/green ihan 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 anggota database global apa pun selama peralihan blue/green penerapan.

Pertimbangan untuk blue/green penerapan

Amazon RDS melacak sumber daya dalam pener blue/green apan 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 cluster DB. Masing-masing terdaftar dalam konfigurasi database di konsol RDS.

Nama (ID cluster) sumber daya berubah saat Anda mengalihkan penerapan, tetapi setiap sumber daya menyimpan ID sumber daya yang sama. blue/green 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, saat Anda mengalihkan sumber daya hijau menjadi sumber daya produksi baru, ID sumber dayanya tidak cocok dengan ID sumber daya biru yang sebelumnya dalam produksi.

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 panggilan API Amazon Aurora 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 API Wawasan Performa, sesuaikan ID sumber daya dalam panggilan ke API setelah switchover. Untuk informasi selengkapnya, lihat Memantau beban DB dengan Amazon CloudWatch Database 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 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 Aurora.

  • Jika Anda memiliki peran IAM yang terkait dengan instans DB cluster , 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 cluster DB manual untuk cluster DB yang merupakan bagian dari blue/green penerapan, pastikan Anda mengembalikan snapshot cluster DB yang benar dengan memeriksa waktu pengambilan snapshot. Untuk informasi selengkapnya, lihat Memulihkan dari snapshot klaster DB.

  • Setelah Anda beralih, tugas replikasi AWS Database Migration Service (AWS DMS) 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.

  • Saat Anda menambahkan instance DB ke cluster DB di lingkungan hijau penerapan, instans DB baru tidak akan menggantikan instans DB di lingkungan biru saat Anda beralih. blue/green 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 penerapan, Anda tidak dapat membuat instance DB baru untuk menggantinya dalam blue/green penerapan. 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.

  • 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 beralih. Saat Anda membuat blue/green penerapan, tag dari lingkungan biru disalin ke lingkungan hijau. Setelah pembuatan, setiap modifikasi tag 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 terapkan kembali tag yang diperlukan ke lingkungan produksi baru setelah peralihan. Untuk informasi selengkapnya tentang tag, lihat Penandaan Amazon Aurora danSumber daya Amazon RDS.