View a markdown version of this page

Memelihara Amazon DocumentDB - Amazon DocumentDB

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-0230 untuk 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 setelahnyaAutoAppliedAfterDate. 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 setelahnyaForcedApplyDate. 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:

Tindakan pemeliharaan berikut berlaku untuk instans Amazon DocumentDB:

  • system-update— Tingkatkan sistem operasi instans Amazon DocumentDB. Sebaiknya gunakan tindakan os-upgrade pemeliharaan 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 major.major.minor (misalnya, 5.0.0 atau5.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 major.0.patch (misalnya,3.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.x 3.6
2.0.x 4.0
3.0.x 5.0
4.0.x 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

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.

Konsol Amazon DocumentDB menampilkan tab Perubahan terjadwal untuk peningkatan patch mesin.

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 sebelumnyaAutoAppliedAfterDate. Setelah tanggal tersebut berlalu, tindakan akan diterapkan secara otomatis selama jendela pemeliharaan berikutnya. Setelah ForcedApplyDate berlalu, 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.

Using the Konsol Manajemen AWS
  1. Masuk ke Konsol Manajemen AWS, dan buka konsol Amazon DocumentDB di https://console.aws.amazon.com/docdb.

  2. Pada panel navigasi, silakan pilih Klaster.

  3. Kolom Pem eliharaan cluster menampilkan Jen dela Ter sedia, Diper lukan, atau Ber ikutnya saat pembaruan tertunda.

    Konsol Amazon DocumentDB menampilkan kolom Pemeliharaan untuk klaster.
  4. Buka cluster, lalu pilih Maintenance & backup untuk melihat item Pending Main tenance dan menindaklanjutinya.

    Konsol Amazon DocumentDB menampilkan jendela Pemeliharaan cluster.
Using the AWS CLI

Jalan describe-pending-maintenance-actions kan untuk melihat apa yang tertunda. Contoh berikut menunjukkan akun tanpa tindakan yang tertunda.

aws docdb describe-pending-maintenance-actions

Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).

{ "PendingMaintenanceActions": [] }

Akun dengan tindakan tertunda mengembalikan output yang terlihat seperti ini:

{ "PendingMaintenanceActions": [ { "ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster", "PendingMaintenanceActionDetails": [ { "Action": "system-update", "Description": "db-version-upgrade", "CurrentApplyDate": "2026-05-15T03:01:00Z", "AutoAppliedAfterDate": "2026-05-15T03:01:00Z" } ] } ] }

Anda dapat menjangkau daftar ke cluster tertentu dengan--filters, dalam formulirName=filter-name,Values=resource-id,.... Filter yang diterima Name adalahdb-cluster-id, yang mengambil daftar pengidentifikasi cluster atau ARN.

contoh

Untuk Linux, macOS, atau Unix:

aws docdb describe-pending-maintenance-actions \ --filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2

Untuk Windows:

aws docdb describe-pending-maintenance-actions ^ --filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2

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.

Using the Konsol Manajemen AWS
Untuk mengelola pembaruan untuk cluster
  1. Masuk ke Konsol Manajemen AWS, dan buka konsol Amazon DocumentDB di https://console.aws.amazon.com/docdb.

  2. Pada panel navigasi, silakan pilih Klaster.

  3. Pilih cluster yang ingin Anda perbarui.

  4. Dari menu T indakan, pilih salah satu:

    • Tingkatkan sekarang —jalankan pemeliharaan yang tertunda segera.

    • Tingkatkan di jendela berikutnya —jalankan selama jendela pemeliharaan cluster berikutnya.

    Anda juga dapat menggunakan Terapkan sekarang atau Terapkan di jendela pemeliharaan berikutnya dari bagian Pemeliharaan Tertunda pada tab Pemeliharaan & cadangan cluster (lihatMelihat tindakan pemeliharaan Amazon DocumentDB yang tertunda).

    catatan

    Jika tidak ada yang tertunda, semua opsi ini tidak aktif.

Using the AWS CLI

Terapkan pembaruan yang tertunda denganapply-pending-maintenance-action.

Parameter
  • --resource-identifier—Amazon DocumentDB Amazon Resource Name (ARN) dari sumber daya yang ditargetkan tindakan tertunda.

  • --apply-action—tindakan pemeliharaan yang tertunda untuk diterapkan. Gunakan system-update untuk menerapkan patch mesin.

  • --opt-in-type—jenis permintaan opt-in, atau apakah akan membatalkannya. Nilai valid:

    • immediateAjukan permohonan sekarang. Tidak dapat dibatalkan setelah dikirimkan.

    • next-maintenance—terapkan selama jendela pemeliharaan sumber daya berikutnya.

    • undo-opt-in—membatalkan next-maintenance opt-in yang ada.

contoh

Untuk Linux, macOS, atau Unix:

aws docdb apply-pending-maintenance-action \ --resource-identifier arn:aws:rds:us-east-1:123456789012:db:sample-cluster-instance-1 \ --apply-action system-update \ --opt-in-type immediate

Untuk Windows:

aws docdb apply-pending-maintenance-action ^ --resource-identifier arn:aws:rds:us-east-1:123456789012:db:sample-cluster-instance-1 ^ --apply-action system-update ^ --opt-in-type immediate

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.

Using the Konsol Manajemen AWS

Untuk memeriksa pembaruan OS dari konsol:

  1. Masuk ke Konsol Manajemen AWS, dan buka konsol Amazon DocumentDB di https://console.aws.amazon.com/docdb.

  2. Di panel navigasi, pilih Cluster, lalu pilih nama cluster.

  3. Pilih tab Maintenance & backup.

  4. Di bawah Pemeliharaan Tertunda, os-upgrade tindakan muncul jika pembaruan OS tersedia.

    Tab Pemeliharaan dan cadangan Amazon DocumentDB menunjukkan tindakan pemeliharaan os-upgrade.
  5. Pilih os-upgrade tindakan dan pilih Ter apkan sekarang atau Ter apkan di jendela pemeliharaan berikutnya. Jika nilainya adalah jendela berikutnya, Anda dapat menunda dengan Tunda peningkatan selama tindakan belum dimulai.

Using the AWS CLI

Periksa pembaruan OS yang tertunda:

aws docdb describe-pending-maintenance-actions
{ "PendingMaintenanceActions": [ { "ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:cluster:sample-cluster", "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade", "Description": "New Operating System update is available" } ] }, { "ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-1", "PendingMaintenanceActionDetails": [ { "Action": "system-update", "Description": "New Operating System update is available" } ] }, { "ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-2", "PendingMaintenanceActionDetails": [ { "Action": "system-update", "Description": "New Operating System update is available" } ] } ] }

Pembaruan OS muncul di tingkat cluster sebagai os-upgrade dan pada tingkat instance sebagaisystem-update. Gunakan tindakan tingkat cluster. os-upgrade

contoh

Contoh berikut menerapkan pembaruan OS segera.

Untuk Linux, macOS, atau Unix:

aws docdb apply-pending-maintenance-action \ --resource-identifier arn:aws:rds:aa-example-1:111122223333:cluster:sample-cluster \ --apply-action os-upgrade \ --opt-in-type immediate

Untuk Windows:

aws docdb apply-pending-maintenance-action ^ --resource-identifier arn:aws:rds:aa-example-1:111122223333:cluster:sample-cluster ^ --apply-action os-upgrade ^ --opt-in-type immediate

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.