Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menggunakan solusi Neptunus Biru/Hijau untuk melakukan pembaruan biru-hijau
Peningkatan mesin Amazon Neptunus dapat memerlukan waktu henti aplikasi karena database tidak tersedia saat pembaruan sedang diinstal dan diverifikasi. Ini benar apakah mereka dimulai secara manual atau otomatis.
Neptunus menyediakan solusi penyebaran Biru/Hijau yang dapat Anda jalankan menggunakan AWS CloudFormation tumpukan dan yang sangat mengurangi waktu henti tersebut. Ini menciptakan lingkungan pementasan hijau yang disinkronkan dengan lingkungan produksi biru Anda. Anda kemudian dapat memperbarui lingkungan pementasan tersebut untuk melakukan peningkatan versi mesin kecil atau utama, perubahan model data grafik, atau pembaruan sistem operasi, dan menguji hasilnya. Akhirnya, Anda dapat mengubahnya dengan cepat untuk menjadi lingkungan produksi Anda, dengan waktu henti yang sangat sedikit.
Solusi Biru/Hijau Neptunus melewati dua fase, seperti yang diilustrasikan dalam diagram ini:
Fase 1 membuat cluster DB Hijau yang identik dengan cluster produksi Anda
Solusinya membuat cluster DB dengan pengidentifikasi penerapan biru/hijau yang unik dan dengan topologi cluster yang sama dengan cluster produksi Anda. Artinya, ia memiliki jumlah dan ukuran instans DB yang sama, grup parameter yang sama dan semua konfigurasi yang sama dengan cluster DB produksi (biru) kecuali bahwa itu telah ditingkatkan ke versi mesin target yang Anda tentukan, yang harus lebih tinggi dari versi mesin (biru) Anda saat ini. Anda dapat menentukan versi mesin minor dan utama untuk target. Jika perlu, solusi akan melakukan upgrade menengah yang diperlukan untuk mencapai versi mesin target yang ditentukan. Cluster baru ini menjadi lingkungan pementasan hijau.
Tahap 2 mengatur sinkronisasi data berkelanjutan
Setelah lingkungan hijau sepenuhnya disiapkan, solusinya mengatur replikasi berkelanjutan antara cluster sumber (biru) dan cluster target (hijau) menggunakan aliran Neptunus. Ketika perbedaan replikasi di antara mereka mencapai nol, lingkungan pementasan siap untuk pengujian. Pada saat itu Anda harus menjeda penulisan ke cluster biru untuk menghindari kelambatan replikasi lebih lanjut.
Versi mesin target Anda mungkin memiliki fitur atau dependensi baru yang memengaruhi aplikasi Anda. Periksa halaman rilis mesin target dan halaman rilis mesin intervensi di bawah Rilis mesin untuk melihat apa yang telah berubah sejak versi mesin Anda saat ini. Yang terbaik adalah menjalankan pengujian integrasi atau memverifikasi aplikasi Anda secara manual di klaster hijau sebelum mempromosikannya ke lingkungan produksi.
Setelah Anda menguji dan memenuhi syarat perubahan di cluster hijau, cukup alihkan titik akhir database dalam aplikasi Anda dari biru ke cluster hijau.
Setelah peralihan, solusi Neptunus Biru/Hijau tidak menghapus lingkungan produksi biru lama. Anda masih akan memiliki akses ke sana untuk validasi dan pengujian tambahan jika diperlukan. Biaya penagihan standar berlaku untuk instance-instancenya sampai Anda menghapusnya. Solusi Biru/Hijau juga menggunakan AWS layanan lain, yang biayanya ditagih dengan harga normal. Detail tentang menghapus solusi ketika Anda selesai dengan itu tercakup di bagian pembersihan.
Prasyarat untuk menjalankan tumpukan Neptunus Biru/Hijau
Sebelum meluncurkan tumpukan Neptunus Biru/Hijau:
Pastikan untuk mengaktifkan aliran Neptunus di cluster produksi (biru) Anda.
Semua instance di cluster biru Anda harus dalam keadaan tersedia. Anda dapat memeriksa status instance di konsol Neptunus
atau dengan menggunakan file. describe-db-instancesAPI Semua instance juga harus sinkron dengan grup parameter cluster DB.
Solusi Neptunus Biru/Hijau memerlukan titik akhir VPC DynamoDB di tempat cluster biru Anda berada. VPC Lihat Menggunakan VPC titik akhir Amazon untuk mengakses DynamoDB.
Pilih pada waktunya untuk menjalankan solusi ketika beban kerja tulis pada cluster DB produksi biru Anda akan seringan mungkin. Hindari, misalnya, menjalankan solusi ketika beban massal akan terjadi, atau ketika kemungkinan ada sejumlah besar operasi tulis karena alasan lain.
