Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menjelaskan tugas seperti memulai ulang, menghapus cache, dan memperbarui saluran dan menjadwalkan pembaruan untuk instans Azure Cache for Redis Anda.
Mulai Ulang
Saat menggunakan tingkat Dasar, Standar, atau Premium Azure Cache for Redis, Anda akan melihat Reboot pada menu sumber daya. Gunakan Reboot untuk memulai ulang satu atau beberapa simpul cache Anda. Reboot memungkinkan Anda menguji aplikasi untuk ketahanan jika ada kegagalan node cache.
Penting
Reboot belum tersedia untuk tingkat Enterprise. Boot ulang tersedia untuk semua tingkatan lainnya.
Pilih simpul yang akan di-reboot, lalu pilih Reboot.
Jika Anda memiliki cache premium dengan pengklusteran diaktifkan, Anda dapat memilih shard cache mana yang akan di-boot ulang.
Untuk me-reboot satu atau beberapa simpul cache, pilih simpul yang diinginkan dan pilih Reboot. Jika Anda memiliki cache premium dengan pengklusteran diaktifkan, pilih shard yang akan di-boot ulang, lalu pilih Reboot. Setelah beberapa menit, simpul yang dipilih di-reboot, dan kembali online beberapa menit kemudian.
Efek pada aplikasi klien Anda bervariasi tergantung pada simpul yang di-reboot.
- Primer - Ketika simpul primer di-boot ulang, Azure Cache for Redis melakukan failover ke simpul replika dan mempromosikannya menjadi primer. Selama failover ini, mungkin ada interval singkat di mana koneksi ke cache mungkin gagal.
- Replika - Saat simpul replika di-reboot, biasanya tidak ada efek pada klien cache.
- Baik primer maupun replika - Ketika kedua node cache di-boot ulang, Azure Cache for Redis berusaha me-reboot kedua node secara bertahap, menunggu satu selesai sebelum me-reboot yang lainnya. Biasanya, kehilangan data tidak terjadi. Namun, kehilangan data masih dapat terjadi pada peristiwa pemeliharaan atau kegagalan yang tidak terduga. Me-reboot cache Anda berkali-kali berturut-turut meningkatkan peluang kehilangan data.
- Simpul cache premium dengan pengklusteran diaktifkan - Saat Anda me-reboot satu atau beberapa simpul cache premium dengan pengklusteran diaktifkan, perilaku untuk simpul yang dipilih sama seperti saat Anda me-reboot simpul atau simpul yang sesuai dari cache yang tidak dikluster.
FAQ tentang Reboot
- Simpul mana yang harus di-reboot untuk menguji aplikasi saya?
- Dapatkah saya me-reboot cache untuk menghapus koneksi klien?
- Apakah saya akan kehilangan data dari cache jika saya melakukan reboot?
- Dapatkah saya me-reboot cache menggunakan PowerShell, CLI, atau alat pengelolaan lainnya?
- Bisakah saya me-reboot cache Enterprise saya?
Simpul mana yang harus di-reboot untuk menguji aplikasi saya?
Untuk menguji ketahanan aplikasi Anda terhadap kegagalan node primer cache Anda, reboot node Primer. Untuk menguji ketahanan aplikasi Anda terhadap kegagalan simpul replika, reboot simpul Replika.
Dapatkah saya me-reboot cache untuk menghapus koneksi klien?
Ya, jika Anda me-reboot cache, semua koneksi klien akan dihapus. Reboot dapat berguna dalam kasus di mana semua koneksi klien digunakan karena kesalahan logika atau bug di aplikasi klien. Setiap tingkat harga memiliki batas koneksi klien yang berbeda untuk berbagai ukuran, dan setelah batas ini tercapai, tidak akan ada lagi koneksi klien yang diterima. Dengan me-reboot cache, semua koneksi klien dapat dihapus.
Penting
Jika Anda me-reboot cache untuk menghapus koneksi klien, StackExchange.Redis secara otomatis terhubung kembali setelah simpul Redis kembali online. Jika masalah yang mendasar tidak diselesaikan, koneksi klien mungkin tetap habis.
Apakah saya akan kehilangan data dari cache jika saya melakukan reboot?
Jika Anda me-reboot node Primer dan Replika , semua data dalam cache, atau semua data dalam shard tersebut saat Anda menggunakan cache premium dengan pengklusteran diaktifkan harus aman. Namun, data dapat hilang dalam beberapa kasus. Me-reboot kedua node harus diambil dengan hati-hati.
Jika Anda hanya me-reboot salah satu simpul, data biasanya tidak hilang, tetapi masih mungkin. Misalnya jika simpul utama di-boot ulang, dan penulisan cache sedang berlangsung, data dari penulisan cache hilang. Skenario lain untuk kehilangan data adalah jika Anda me-reboot satu simpul, dan simpul lain kebetulan turun karena kegagalan pada saat yang sama.
Anda juga harus tahu bahwa me-reboot kedua node tidak mengakibatkan flush data. Jika Anda ingin menghapus data, gunakan prosedur flush dari konsol portal.
Dapatkah saya me-reboot cache menggunakan PowerShell, CLI, atau alat pengelolaan lainnya?
Ya, untuk petunjuk PowerShell, lihat Me-reboot Azure Cache for Redis.
Bisakah saya me-reboot cache Enterprise saya?
Tidak. Reboot belum tersedia untuk tingkat Enterprise. Boot ulang tersedia untuk tingkat Dasar, Standar, dan Premium. Pengaturan yang Anda lihat pada menu Sumber Daya di bawah Administrasi bergantung pada tingkat cache Anda. Anda tidak melihat Reboot saat menggunakan cache dari tingkat Enterprise.
Menghapus data
Saat menggunakan tingkat Dasar, Standar, atau Premium Azure Cache for Redis, Anda akan melihat Membersihkan data pada menu sumber daya. Gunakan Hapus data untuk menghapus atau menghapus semua data di cache Anda. Pembilasan dapat dilakukan sebelum operasi penskalaan untuk mengurangi kemungkinan waktu yang diperlukan dalam menyelesaikan operasi tersebut pada cache Anda. Anda juga dapat mengonfigurasi untuk menjalankan operasi flush secara berkala pada cache dev/test Anda untuk menjaga penggunaan memori tetap terjaga.
Operasi flush , ketika dijalankan pada cache berkluster, menghapus data dari semua shard secara bersamaan.
Penting
Sebelumnya, operasi flush hanya tersedia untuk cache tingkat Enterprise yang direplikasi secara geografis. Sekarang, tersedia di tingkat Dasar, Standar, dan Premium.
Memperbarui pembaruan saluran dan jadwal
Saat menggunakan tingkat Dasar, Standar, atau Premium Azure Cache for Redis, Anda akan melihat Menjadwalkan pembaruan pada menu sumber daya. Gunakan pembaruan jadwal untuk memilih saluran pembaruan dan jendela pemeliharaan untuk instans cache Anda.
Instans cache apa pun yang menggunakan saluran Pembaruan stabil menerima pembaruan beberapa minggu lebih lambat dari instans cache menggunakan saluran pembaruan Pratinjau . Sebaiknya pilih saluran pembaruan Pratinjau untuk nonproduksi Anda dan beban kerja yang kurang penting. Pilih saluran Pembaruan stabil untuk beban kerja produksi Anda yang paling penting. Semua cache default ke saluran Pembaruan stabil secara default.
Penting
Mengubah saluran pembaruan pada instans cache Anda menghasilkan cache Anda yang menjalani peristiwa patching untuk menerapkan pembaruan yang tepat. Pertimbangkan untuk mengubah saluran pembaruan selama jendela pemeliharaan Anda.
Jendela pemeliharaan memungkinkan Anda mengontrol hari dan waktu seminggu di mana VM yang menghosting cache Anda dapat diperbarui. Azure Cache for Redis melakukan upaya terbaik untuk memulai dan menyelesaikan pembaruan perangkat lunak server Redis dalam jendela waktu yang ditentukan yang Anda tentukan.
Penting
Saluran pembaruan dan jendela pemeliharaan berlaku untuk pembaruan server Redis dan pembaruan pada Sistem Operasi VM yang menghosting cache. Saluran pembaruan dan jendela pemeliharaan tidak berlaku untuk pembaruan OS Host ke Host yang menghosting VM cache atau komponen Jaringan Azure lainnya. Dalam kasus yang jarang terjadi di mana cache dihosting pada model yang lebih lama, jendela pemeliharaan juga tidak berlaku untuk pembaruan OS Tamu. Anda dapat mengetahui apakah cache Anda berada pada model yang lebih lama jika nama DNS cache berakhir dengan akhiran cloudapp.net
, chinacloudapp.cn
, usgovcloudapi.net
, atau cloudapi.de
.
Saat ini, tidak ada opsi yang tersedia untuk mengonfigurasi saluran pembaruan atau pembaruan terjadwal untuk cache tingkat Perusahaan.
Untuk menentukan periode pemeliharaan, periksa hari yang diinginkan dan tentukan jam mulai periode pemeliharaan untuk setiap hari. Kemudian, pilih OK. Waktu jendela pemeliharaan dalam UTC dan hanya dapat dikonfigurasi setiap jam.
Periode pemeliharaan default dan minimum untuk pembaruan adalah lima jam. Nilai ini tidak dapat dikonfigurasi dari portal Azure, tetapi Anda dapat mengonfigurasinya di PowerShell menggunakan parameter MaintenanceWindow
cmdlet New-AzRedisCacheScheduleEntry. Untuk informasi selengkapnya, lihat Dapatkah saya mengelola pembaruan terjadwal menggunakan PowerShell, CLI, atau alat manajemen lainnya?
FAQ tentang pembaruan terjadwal
- Kapan pembaruan terjadi jika saya tidak menggunakan fitur pembaruan terjadwal?
- Jenis pembaruan apa yang dilakukan selama periode pemeliharaan terjadwal?
- Dapatkah saya mengelola pembaruan terjadwal menggunakan PowerShell, CLI, atau alat pengelolaan lainnya?
- Dapatkah pembaruan yang dicakup dan dikelola oleh fitur "Pembaruan Terjadwal" terjadi di luar periode "Pembaruan Terjadwal"?
Kapan pembaruan terjadi jika saya tidak menggunakan fitur pembaruan terjadwal?
Jika Anda tidak menentukan periode pemeliharaan, pembaruan dapat dilakukan kapan saja.
Jenis pembaruan apa yang dilakukan selama periode pemeliharaan terjadwal?
Hanya pembaruan server Redis yang dibuat selama periode pemeliharaan terjadwal. Jendela pemeliharaan tidak berlaku untuk pembaruan Azure atau pembaruan sistem operasi host.
Dapatkah saya mengelola pembaruan terjadwal menggunakan PowerShell, CLI, atau alat pengelolaan lainnya?
Ya, Anda dapat mengelola pembaruan terjadwal menggunakan cmdlet PowerShell berikut:
- Get-AzRedisCachePatchSchedule
- Jadwal PatchCache-AzRedisCache-Baru
- New-AzRedisCacheScheduleEntry
- Remove-AzRedisCachePatchSchedule (Hapus Jadwal Patch Cache Redis Az)
Dapatkah pembaruan yang dicakup dan dikelola oleh fitur Pembaruan Terjadwal terjadi di luar periode Pembaruan Terjadwal?
Ya. Secara umum, pembaruan tidak diterapkan di luar periode Pembaruan Terjadwal yang dikonfigurasi. Pembaruan keamanan penting yang langka dapat diterapkan di luar jadwal patching sebagai bagian dari kebijakan keamanan kami.
Konten terkait
Pelajari lebih lanjut tentang fitur Azure Cache for Redis.