View a markdown version of this page

Praktik terbaik untuk penerapan Amazon blue/green Aurora - Amazon Aurora
Praktik terbaik umum untuk blue/green penerapan praktik terbaik untuk penerapan blue/greenPraktik terbaik Aurora PostgreSQL untuk penerapan blue/green Aurora Global Database praktik terbaik untuk penerapan blue/green

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

Praktik terbaik untuk penerapan Amazon blue/green Aurora

Berikut ini adalah praktik terbaik untuk blue/green penerapan.

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 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 blue/green penerapan, ikuti praktik terbaik peralihan. Untuk informasi selengkapnya, lihat Praktik terbaik switchover.

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.

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.

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

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

    • Di Aurora PostgreSQL versi 14 dan lebih tinggi, Anda dapat memantau ukuran file luapan logis menggunakan tampilan sistem. pg_stat_replication_slots

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

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

  • 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, lihatMelakukan upgrade versi utama.

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

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

      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.

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

  • Jika Anda menggunakan pemicu, pastikan mereka tidak mengganggu pembuatan, pembaruan, dan penghapusan, pg_catalog.pg_publicationpg_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_status

    • babelfishpg_tds.tds_default_numeric_precision

    • babelfishpg_tds.tds_default_numeric_scale

    • babelfishpg_tsql.default_locale

    • babelfishpg_tsql.migration_mode

    • babelfishpg_tsql.server_collation_name

    Untuk informasi selengkapnya tentang parameter ini, lihat Pengaturan grup parameter klaster DB untuk Babelfish.

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.