Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memelihara Amazon DocumentDB
Amazon DocumentDB secara berkala melakukan dua jenis pemeliharaan:
-
Pemeliharaan cluster memperbarui mesin database. Pembaruan mesin membawa perbaikan keamanan, perbaikan bug, fitur baru, dan peningkatan mesin lainnya.
-
Pemeliharaan instans memperbarui sistem operasi (OS) pada instance.
Patch engine dan pembaruan OS menggunakan tiga kategori siklus hidup yang sama — opsional, wajib, dan paksa — dengan notifikasi yang sama dan perilaku penerapan untuk setiap kategori. Rilis mesin juga memiliki kategori keempat: versi minor, yang Anda tingkatkan secara manual. Kategorinya adalah:
-
Opsional —berisi peningkatan non-kritis. Tidak ada tanggal aplikasi otomatis dan tidak ada pemberitahuan AHD; terapkan saat cocok untuk Anda. (Untuk pembaruan OS, Anda dapat berlangganan
RDS-EVENT-0230untuk diberi tahu ketika tersedia.) -
Diperlukan —berisi keamanan dan perbaikan penting lainnya. Anda menerima pemberitahuan melalui Dasbor Health (AHD) dan email. Tindakan yang diperlukan diterapkan secara otomatis selama jendela pemeliharaan cluster atau instans setelahnya
AutoAppliedAfterDate. Anda dapat menunda dengan mengubah jendela pemeliharaan sebelum tanggal tersebut. -
Dip aksa—perbaikan yang langka dan sangat kritis. Auto-applies di luar jendela pemeliharaan Anda setelahnya
ForcedApplyDate. Amazon DocumentDB hanya menunjuk tindakan yang dipaksakan ketika tidak ada opsi lain yang tersedia. -
Versi minor (hanya rilis mesin) —rilis mesin bernomor di atas versi utama (misalnya,
5.0.1). User-driven: Anda memutakhirkan dengan memodifikasi versi mesin cluster. Jangan pernah menerapkan secara otomatis; tidak ada pemberitahuan AHD. Versi minor tidak dipublikasikan untuk versi utama yang lebih awal dari 5.0.
Patch mesin dirilis ke dalam satu kategori (opsional, wajib, atau dipaksa) dan tetap di sana. Kemajuan pembaruan OS: sebagian besar dimulai sebagai opsional dan, jika tidak diterapkan, transisi ke yang diperlukan dan akhirnya dipaksa. Waktu yang tepat tergantung pada patch dan dipublikasikan dalam pemberitahuan AHD dan bidang tanggal yang dikembalikan oleh describe-pending-maintenance-actions (lihatTerapkan tanggal). Catatan Rilis Amazon DocumentDB https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html menggunakan nama kategori ini saat mengumumkan perubahan mesin.
Menerapkan patch mesin apa pun membuat cluster offline sebentar. Sisa topik ini membahas cara kerja jendela pemeliharaan, cara menemukan pekerjaan yang tertunda, cara menerapkan patch mesin dan versi minor, cara kerja pembaruan OS, dan penanganan khusus untuk cluster global.
Tindakan pemeliharaan untuk Amazon DocumentDB
Tindakan pemeliharaan berikut berlaku untuk cluster Amazon DocumentDB:
-
system-update— Tingkatkan patch mesin untuk cluster Amazon DocumentDB. Untuk informasi selengkapnya, lihat Pembaruan mesin Amazon DocumentDB. -
os-upgrade— Perbarui sistem operasi semua instans DB di cluster Amazon DocumentDB, menggunakan peningkatan bergulir. Untuk informasi selengkapnya, lihat Pembaruan sistem operasi Amazon DocumentDB.
Tindakan pemeliharaan berikut berlaku untuk instans Amazon DocumentDB:
-
system-update— Tingkatkan sistem operasi instans Amazon DocumentDB. Sebaiknya gunakan tindakanos-upgradepemeliharaan tingkat cluster sebagai gantinya. Untuk informasi selengkapnya, lihat Pembaruan sistem operasi Amazon DocumentDB.
Penomoran versi mesin
Amazon DocumentDB menggunakan dua pengidentifikasi versi terpisah:
-
Versi mesin —nomor tiga bagian dalam bentuk
(misalnya,major.major.minor5.0.0atau5.0.1). Dua bagian pertama (5.0) adalah versi kompatibilitas MongoDB; bagian ketiga adalah versi minor, bertambah ketika Amazon DocumentDB menerbitkan rilis kecil yang berisi perbaikan bug dan perbaikan yang tidak merusak. Ini adalah versi yang Anda tentukan saat membuat atau memutakhirkan cluster. -
Versi patch engine —nomor tiga bagian terpisah dalam formulir
(misalnya,major.0.patch3.0.17983) yang mengidentifikasi level patch yang diterapkan ke cluster Anda. Digit tengah selalu0. Versi patch berisi perbaikan keamanan dan stabilitas kritis.
Anda dapat menentukan versi mesin dari awalan versi patch engine, seperti yang ditunjukkan pada tabel berikut.
| Awalan versi patch mesin | Versi mesin Amazon DocumentDB |
|---|---|
1.0. |
3.6 |
2.0. |
4.0 |
3.0. |
5.0 |
4.0. |
8.0 |
Untuk memeriksa versi patch cluster Anda berjalan, sambungkan dan jalankandb.runCommand({getEngineVersion: 1}).
Untuk daftar versi patch engine yang dirilis dan apa yang masing-masing berisi, lihatCatatan rilis.
Mengelola jendela pemeliharaan Amazon DocumentDB
Setiap cluster dan setiap instance memiliki jendela pemeliharaan mingguan 30 menit tersendiri—periode ketika modifikasi terjadwal dan tambalan perangkat lunak dijalankan. Sebagian besar acara selesai dalam 30 menit; yang lebih besar dapat berjalan lebih lama.
Jika Anda tidak memilih jendela saat membuat sumber daya, Amazon DocumentDB menetapkannya secara acak dalam blok harian 8 jam yang ditentukan untuk Wilayah, pada hari yang dipilih secara acak. Pilih jendela yang meminimalkan dampak pada aplikasi Anda—malam hari atau akhir pekan, misalnya.
Untuk peningkatan mesin database, Amazon DocumentDB menggunakan jendela cluster, bukan jendela instans individual.
Tabel berikut menunjukkan blok waktu default per Wilayah.
| Nama Wilayah | Region | Blok Waktu UTC |
|---|---|---|
| AS Timur (Ohio) | us-east-2 | 03:00-11:00 |
| US East (Northern Virginia) | us-east-1 | 03:00-11:00 |
| AS Barat (Oregon) | us-west-2 | 06:00-14:00 |
| Africa (Cape Town) | af-south-1 | 03:00 — 11:00 |
| Asia Pasifik (Hong Kong) | ap-east-1 | 06:00-14:00 |
| Asia Pasifik (Hyderabad) | ap-south-2 | 06:30 — 14:30 |
| Asia Pasifik (Malaysia) | ap-southeast-5 | 13:00-21:00 |
| Asia Pasifik (Mumbai) | ap-south-1 | 06:00-14:00 |
| Asia Pacific (Osaka) | ap-northeast-3 | 12:00-20:00 |
| Asia Pasifik (Seoul) | ap-northeast-2 | 13:00-21:00 |
| Asia Pasifik (Singapura) | ap-southeast-1 | 14:00-22:00 |
| Asia Pasifik (Sydney) | ap-southeast-2 | 12:00-20:00 |
| Asia Pasifik (Jakarta) | ap-southeast-3 | 08:00-16:00 |
| Asia Pacific (Melbourne) | ap-southeast-4 | 11:00-19:00 |
| Asia Pasifik (Thailand) | ap-Southeast-7 | 15:00-23:00 |
| Asia Pasifik (Tokyo) | ap-northeast-1 | 13:00-21:00 |
| Kanada (Pusat) | ca-central-1 | 03:00-11:00 |
| Kanada Barat (Calgary) | ca-west-1 | 18:00-02:00 |
| Tiongkok (Beijing) | cn-north-1 | 06:00-14:00 |
| Tiongkok (Ningxia) | cn-northwest-1 | 06:00-14:00 |
| Eropa (Frankfurt) | eu-central-1 | 21:00-05:00 |
| Europe (Zurich) | eu-central-2 | 02:00-10:00 |
| Eropa (Irlandia) | eu-west-1 | 22:00-06:00 |
| Eropa (London) | eu-west-2 | 22:00-06:00 |
| Europe (Milan) | eu-south-1 | 02:00-10:00 |
| Eropa (Paris) | eu-west-3 | 23:59 - 07:29 |
| Eropa (Spanyol) | eu-south-2 | 02:00 — 10:00 |
| Eropa (Stockholm) | eu-north-1 | 04:00 — 12:00 |
| Meksiko (Tengah) | mx-sentral-1 | 03:00-11:00 |
| Timur Tengah (UAE) | me-central-1 | 05:00 — 13:00 |
| Amerika Selatan (Sao Paulo) | sa-east-1 | 00:00-08:00 |
| Israel (Tel Aviv) | il-central-1 | 04:00-12:00 |
| AWS GovCloud (US-East) | us-gov-east-1 | 17:00-01:00 |
| AWS GovCloud (US-West) | us-gov-west-1 | 06:00-14:00 |
Mengubah jendela pemeliharaan Amazon DocumentDB
Pilih jendela lalu lintas terendah yang Anda bisa, dan sesuaikan seiring waktu saat pola lalu lintas Anda bergeser. Cluster atau instance tidak tersedia selama jendela hanya jika perubahan sistem—operasi penyimpanan skala atau perubahan kelas instance, misalnya—memerlukan pemadaman, dan hanya selama perubahan itu benar-benar diperlukan.
Mengubah waktu pemeliharaan
-
Untuk sebuah klaster, lihat Memodifikasi cluster Amazon DocumentDB.
-
Untuk sebuah instans, lihat Memodifikasi instance Amazon DocumentDB.
Pemberitahuan untuk patch mesin Amazon DocumentDB
Ketika patch mesin yang diperlukan tersedia di Wil AWS ayah, setiap AWS akun dengan cluster Amazon DocumentDB yang terpengaruh di Wilayah tersebut menerima pemberitahuan melalui Dasbor Health (AHD) dan melalui email (dikirim ke alamat pengguna root AWS akun). Satu pemberitahuan dikirimkan per versi mesin Amazon DocumentDB yang terpengaruh. Anda dapat menemukannya di bawah Perubahan terjadwal di AHD. Setiap notifikasi mencantumkan waktu ketersediaan patch, jadwal penerapan otomatis, cluster yang terpengaruh, dan catatan rilis.
Patch mesin yang diperlukan mengikuti satu waktu tunggu sekitar 30 hari. Saat patch tersedia di Wilayah Anda, Amazon DocumentDB mengirimkan pemberitahuan yang dijelaskan di atas. Pada titik itu, patch AutoAppliedAfterDate diatur ke sekitar 30 hari kemudian. Hingga tanggal tersebut, patch tetap tertunda: Anda dapat menerapkannya kapan saja, atau menundanya dengan memindahkan jendela pemeliharaan cluster Anda ke hari berikutnya. Pada atau setelahAutoAppliedAfterDate, patch diterapkan secara otomatis selama jendela pemeliharaan cluster berikutnya.
Misalnya, patch yang diperlukan yang tersedia pada 1 Juni 2026 memiliki AutoAppliedAfterDate tanggal sekitar 1 Juli 2026. Anda menerima pemberitahuan pada 1 Juni 2026, dan jika Anda tidak mengambil tindakan, patch akan diterapkan secara otomatis selama jendela pemeliharaan pertama cluster Anda pada atau setelah 1 Juli 2026.
Anda memiliki dua opsi setelah menerima pemberitahuan: menerapkan sendiri patch sebelum tanggal penerapan otomatis, atau tunggu hingga diterapkan secara otomatis selama jendela pemeliharaan yang akan datang (default). Untuk menerapkan sendiri, buka tab Maintenance & backup cluster dan cari entri jenissystem-update.
catatan
Status notifikasi di AHD tetap Berlangsung sampai Amazon DocumentDB merilis patch mesin lain dengan versi patch baru.
Setelah patch diterapkan, versi patch engine cluster diperbarui agar sesuai dengan versi dalam notifikasi. Verifikasi versi baru dengan menjalankandb.runCommand({getEngineVersion: 1}).
Patch opsional dan versi minor baru tidak menghasilkan pemberitahuan AHD atau email. Untuk melacaknya, tonton catatan https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html rilis Amazon DocumentDB.
Patch paksa (kategori paling langka, disediakan untuk perbaikan keamanan paling kritis) juga diumumkan melalui AHD dan email. Tidak seperti patch yang diperlukan, mereka berlaku di luar jendela pemeliharaan Anda, jadi contoh waktu penerapan otomatis di atas tidak berlaku.
Bereaksi terhadap pemberitahuan patch secara terprogram
AWS Health terintegrasi dengan Amazon EventBridge, yang memungkinkan Anda membangun aplikasi berbasis peristiwa di lebih dari 20 target, termasuk AWS Lambda dan Amazon Simple Queue Service (SQS). Untuk bereaksi terhadap ketersediaan patch engine secara terprogram, konfigur EventBridge asikan terhadap peristiwa tersebut. AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED Dari sana Anda dapat menangkap data acara, meningkatkan acara tambahan, mengirim pemberitahuan push melalui AWS Console Mobile Application, atau mengambil tindakan lain yang Anda butuhkan.
Jika Amazon DocumentDB membatalkan patch (jarang), Anda menerima pemberitahuan AHD dan email tentang pembatalan tersebut. Gunakan kode AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED acara dengan Amazon EventBridge untuk menangani kasus ini. Untuk selengkapnya tentang aturan penulisan, lihat Panduan EventBridge Pengguna Amazon.
Melihat tindakan pemeliharaan Amazon DocumentDB yang tertunda
Gunakan Konsol Manajemen AWS atau AWS CLI untuk memeriksa pemeliharaan apa yang tertunda untuk cluster atau instance.
Pembaruan yang tertunda muncul dengan jenis tindakansystem-update, yang mencakup patch engine dan pembaruan OS.
Saat pembaruan tertunda, Anda dapat:
-
Terapkan segera.
-
Jadwalkan untuk jendela pemeliharaan berikutnya.
-
Tunda (patch mesin dan pembaruan OS saja) dengan mengubah jendela pemeliharaan Anda sebelumnya
AutoAppliedAfterDate. Setelah tanggal tersebut berlalu, tindakan akan diterapkan secara otomatis selama jendela pemeliharaan berikutnya. SetelahForcedApplyDateberlalu, tidak ada penangguhan lebih lanjut yang mungkin dilakukan.
catatan
Jika Anda tidak mengambil tindakan, tindakan pemeliharaan yang diperlukan seperti patch mesin yang diperlukan akan diterapkan secara otomatis selama jendela pemeliharaan yang akan datang. Tambalan opsional dan versi minor tidak pernah diterapkan secara otomatis.
Jendela pemeliharaan mengontrol kapan operasi yang tertunda dimulai, bukan berapa lama waktu yang dibutuhkan untuk menyelesaikannya.
Terapkan tanggal
Setiap tindakan pemeliharaan yang tertunda membawa hingga tiga tanggal penerapan. Mereka muncul di AWS CLI output untuk describe-pending-maintenance-actions dan menunjukkan kapan tindakan akan berjalan. Bidang adalah null untuk pemeliharaan opsional.
-
CurrentApplyDate—ketika tindakan dijadwalkan untuk dijalankan, baik sekarang atau di jendela pemeliharaan berikutnya. Dihuni untuk tindakan yang diperlukan dan dipaksakan. -
AutoAppliedAfterDate—tanggal setelah penerapan otomatis dimulai selama jendela pemeliharaan cluster atau instance. Diisi untuk tindakan yang diperlukan. -
ForcedApplyDatetenggat waktu yang sulit. Setelah tanggal ini tindakan berjalan secara otomatis, terlepas dari jendela pemeliharaan Anda. Dihuni untuk tindakan paksa.
Untuk menunda tindakan yang tertunda, pindahkan jendela pemeliharaan Anda ke hari berikutnya sebelumnyaAutoAppliedAfterDate. Setelah AutoAppliedAfterDate berlalu, tindakan akan diterapkan secara otomatis selama jendela pemeliharaan berikutnya. Setelah ForcedApplyDate berlalu, tidak ada penangguhan lebih lanjut yang mungkin dilakukan. Jendela penangguhan yang tepat bervariasi per patch; tanggal dipublikasikan dalam pemberitahuan AHD dan output. AWS CLI
Pembaruan mesin Amazon DocumentDB
Setelah mengidentifikasi patch engine yang tertunda, gunakan salah satu prosedur berikut untuk menerapkan atau menjadwalkannya. Anda dapat menjalankan prosedur ini dari Konsol Manajemen AWS atau AWS CLI.
Baca ketersediaan selama tambalan
Mesin Amazon DocumentDB 5.0 dan 8.0 mempertahankan ketersediaan baca selama menambal ketika cluster memiliki beberapa instans. Amazon DocumentDB menambal instance pembaca secara bergulir, dalam tiga grup, sehingga pembaca yang tersisa terus melayani lalu lintas. Penulis sebentar tidak tersedia saat menambal. Untuk mencapai waktu henti baca nol, atur preferensi baca Anda sehingga pembacaan dapat kembali ke penulis: secondaryPreferred atau primaryPreferred berfungsi; primary atau secondary sendirian dapat menyebabkan waktu henti membaca.
| Baca mode preferensi | Selama peningkatan penulis | Selama pemutakhiran pembaca | Jumlah minimum pembaca yang dibutuhkan untuk waktu henti baca nol |
|---|---|---|---|
primary |
Read/write waktu henti | Tidak ada dampak | N/A |
primaryPreferred |
Menulis waktu henti | Tidak ada dampak | 1 |
secondary |
Menulis waktu henti | Waktu henti membaca (jika hanya satu pembaca) | 2 |
secondaryPreferred |
Menulis waktu henti | Tidak ada dampak | 1 |
nearest |
Menulis waktu henti | Tidak ada dampak | 1 |
Saat pembaca menambal, throughput pembacaan cluster secara keseluruhan turun sementara. Agar throughput tetap stabil, sediakan pembaca tambahan sebelum peningkatan dan hapus setelah selesai.
Pada engine 3.6 dan 4.0, fitur ketersediaan baca ini tidak berlaku: patch engine menyebabkan downtime yang lebih lama yang memengaruhi pembacaan dan penulisan. Untuk memutakhirkan ke versi utama yang melakukannya, lihatAmazon DocumentDB upgrade versi utama di tempat.
Panjang downtime patch
Engine-patch downtime bervariasi. Faktor terbesar adalah pemanfaatan CPU dan tekanan memori pada instance pada saat patch, jadi menentukan ukuran instans yang tepat penting. Untuk meminimalkan waktu henti, jalankan versi engine utama Amazon DocumentDB terbaru dan sebarkan instans di beberapa Zona Ketersediaan.
Pembaruan dan penggantian patch
Amazon DocumentDB memantau patch setelah rilis. Dalam kasus yang jarang terjadi ketika masalah teridentifikasi, Amazon DocumentDB menjeda peluncuran saat menyiapkan versi yang diperbarui. Ketika ini terjadi, cluster yang belum menerima patch tidak lagi melihatnya sebagai tindakan pemeliharaan yang tersedia, dan pemberitahuan perubahan terjadwal terkait di patch Dasbor Health ditarik. Cluster yang sudah menjalankan versi yang terpengaruh terus beroperasi secara normal dan tidak memerlukan tindakan dari Anda.
Patch yang diperbarui segera menyusul. Ketika tersedia di Wilayah Anda, Anda menerima pemberitahuan baru melalui e-mail Dasbor Health dan, seperti yang dijelaskan diPemberitahuan untuk patch mesin Amazon DocumentDB.
Peningkatan versi minor
Amazon DocumentDB menerbitkan versi minor di atas versi utama 5.0 dan yang lebih baru (misalnya,5.0.1). Versi minor tidak dipublikasikan untuk versi utama yang lebih awal dari 5.0. Versi minor berperilaku berbeda dari patch mesin yang diperlukan dan opsional:
-
Mereka tidak muncul sebagai tindakan pemeliharaan yang tertunda dan tidak pernah diterapkan secara otomatis.
-
Mereka tidak menghasilkan pemberitahuan AHD atau email. Versi minor baru diumumkan dalam catatan https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html rilis Amazon DocumentDB.
-
Untuk memutakhirkan, Anda memodifikasi versi mesin cluster (segera atau selama jendela pemeliharaan berikutnya). Upgrade versi minor memerlukan waktu henti singkat dan bersifat satu arah — Anda tidak dapat menurunkan versi ke versi minor sebelumnya. Untuk cluster global, tingkatkan cluster sekunder sebelum cluster primer.
Baca lebih lanjut:Peningkatan versi minor Amazon DocumentDB.
Pembaruan sistem operasi Amazon DocumentDB
Instans terkadang membutuhkan pembaruan OS. Amazon DocumentDB memperbarui OS untuk meningkatkan kinerja dan memperketat keamanan. Pembaruan OS membuat versi mesin cluster dan kelas instance tidak berubah. Seperti patch mesin, pembaruan OS menggunakan siklus hidup opsional/wajib/paksa yang dijelaskan di bagian atas topik ini; tidak seperti patch mesin, pembaruan OS dapat beralih melalui kategori ini dari waktu ke waktu jika Anda menundanya. Terapkan pembaruan OS segera setelah tersedia, dan atur jendela pemeliharaan cluster dan instans Anda ke waktu yang sesuai dengan kebutuhan bisnis Anda.
Gunakan tindakan os-upgrade pemeliharaan tingkat cluster untuk menerapkan pembaruan OS di semua instans dalam cluster. Amazon DocumentDB memperbarui instans secara bergulir, beberapa pada satu waktu, dan memperbarui instans utama terakhir untuk meminimalkan failover. Pembaruan berjalan selama jendela pemeliharaan kluster—bukan jendela pemeliharaan instans individu—yang Anda konfigurasikan.
Setelah instance menerima pembaruan OS, cache buffernya mulai kosong. Sampai kumpulan kerja diisi ulang dari volume penyimpanan, kueri pada instance tersebut dapat mengalami latensi yang lebih tinggi dan lebih rendahBufferCacheHitRatio.
Saat Amazon DocumentDB memperbarui instance utama, failover mempromosikan replika menjadi primer baru. Gunakan titik akhir cluster sehingga aplikasi Anda menangani ini secara transparan. Untuk mempertahankan ketersediaan baca saat instans sedang diperbarui, setel preferensi baca Anda ke secondaryPreferred atau primaryPreferred agar pembacaan dapat kembali ke instance yang tersedia. Simpan target failover potensial (replika dengan tingkat prioritas tertinggi) pada kelas instans yang sama dengan yang utama. Ini menghindari penurunan kinerja tulis setelah promosi. Lihat perinciannya di Failover Amazon DocumentDB.
Tindakan tingkat cluster os-upgrade dan tingkat instance mungkin muncul secara bersamaan system-update sebagai tindakan yang tersedia. describe-pending-maintenance-actions Namun, Anda tidak dapat menjadwalkan keduanya secara bersamaan. Jika system-update tindakan tingkat instance dijadwalkan secara aktif pada instans apa pun, Anda harus membatalkan atau menyelesaikannya sebelum menjadwalkan os-upgrade tindakan tingkat cluster, dan sebaliknya.
penting
Instans Amazon DocumentDB Anda akan offline untuk pembaruan OS. Multi-instance cluster meminimalkan dampaknya. Jika Anda menjalankan cluster instans tunggal, Anda dapat menambahkan sementara sekunder untuk pembaruan dan menghapusnya setelahnya. Yang sekunder menimbulkan biaya biasa saat ada.
catatan
Tindakan tingkat instance system-update masih tersedia untuk kompatibilitas mundur. Jika Anda harus menggunakannya, perbarui replika terlebih dahulu dan yang utama terakhir—hindari menambal secara bersamaan, karena failover selama patch dapat memperpanjang waktu henti.
Untuk mendapatkan acara saat pembaruan OS opsional baru tiba, berlangganan RDS-EVENT-0230 di kategori acara tambalan keamanan. Untuk informasi selengkapnya, lihat Berlangganan acara Amazon DocumentDB.
catatan
Tetap terkini tentang pembaruan opsional dan wajib mungkin diperlukan untuk kepatuhan. Terapkan os-upgrade tindakan secara rutin selama jendela pemeliharaan Anda.
Pembaruan OS terkait dengan kelas instance tertentu, sehingga instans yang berbeda menjadi memenuhi syarat pada waktu yang berbeda. Jika cluster Anda tidak menggunakan patch engine terbaru, pembaruan OS mungkin tidak muncul — terapkan patch engine terbaru terlebih dahulu (lihatPembaruan mesin Amazon DocumentDB).
Gunakan Konsol Manajemen AWS atau AWS CLI untuk memeriksa apakah pembaruan tersedia.
User-initiated pembaruan
Beberapa perubahan Anda mulai sendiri—misalnya, menukar kelas instance dengan kelas dengan memori lebih banyak atau lebih sedikit, atau mengubah grup parameter cluster. Amazon DocumentDB memperlakukan ini secara berbeda dari pembaruan yang dimulainya. Untuk detailnya, lihat:
Untuk membuat daftar perubahan yang diprakarsai pengguna yang masih tertunda:
contoh
Untuk membuat daftar perubahan yang diprakarsai pengguna yang tertunda untuk instans Anda
Untuk Linux, macOS, atau Unix:
aws docdb describe-db-instances \ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
Untuk Windows:
aws docdb describe-db-instances ^ --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
Dalam contoh ini, sample-cluster-instance memiliki perubahan yang tertunda kedb.r5.xlarge; sample-cluster-instance-2 has none.
[
[
"sample-cluster",
"sample-cluster-instance",
{
"DBInstanceClass": "db.r5.xlarge"
}
],
[
"sample-cluster",
"sample-cluster-instance-2",
{}
]
]Penambalan klaster global
Dalam cluster global, setiap cluster anggota—primer dan sekunder—melakukan upgrade selama jendela pemeliharaannya sendiri. Ketika patch mesin yang diperlukan tersedia di setiap Wilayah, Anda menerima pemberitahuan AHD dan email. Patch opsional dan versi minor baru tidak menghasilkan pemberitahuan; periksa catatan rilis Amazon DocumentDB untuk itu.
Jika Anda mendaftar sendiri, selalu tambal sekunder terlebih dahulu dan yang utama terakhir. Pesanan ini membuat failover dan switchover tersedia selama peluncuran.
penting
Jika Anda menambal yang utama terlebih dahulu secara tidak sengaja, bawa semua sekunder ke versi yang sama sesegera mungkin. Failover dan switchover tetap dinonaktifkan sampai setiap cluster berada pada versi yang sama.
Jika Anda tidak mengambil tindakan, patch akan diterapkan secara otomatis selama jendela pemeliharaan berikutnya setiap cluster: sekunder terlebih dahulu, lalu primer di jendelanya setelah sekunder selesai.
Pertahankan cluster DB primer dan sekunder pada versi yang sama. Failover lintas wilayah yang dikelola hanya berfungsi pada database global ketika setiap cluster berbagi versi engine dan tingkat patch yang sama. Hal yang sama berlaku jika Anda menambahkan sekunder baru yang menggunakan versi engine yang lebih baru daripada versi primer — buat sekunder baru pada versi primer sebelum menggabungkannya ke database global.
Setelah pemberitahuan patch, tingkatkan versi primer dan sekunder ke versi terbaru sesegera mungkin agar failover dan switchover tetap berfungsi. Jika permintaan failover atau switchover ditolak, bandingkan versi patch engine di seluruh cluster; jika tidak cocok, terapkan patch yang tersedia pada cluster yang tertinggal.