Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Perilaku versi mesin utama dan perbedaan kompatibilitas dengan Redis OSS
penting
Halaman berikut disusun untuk menandakan semua perbedaan inkompatibilitas antarversi dan memberi tahu Anda tentang pertimbangan apa pun yang harus Anda buat saat meningkatkan ke versi yang lebih baru. Daftar ini termasuk masalah inkompatibilitas versi apa pun yang mungkin Anda temui saat melakukan peningkatan.
Anda dapat meningkatkan langsung dari versi Redis Anda saat ini ke OSS versi Redis OSS terbaru yang tersedia, tanpa perlu peningkatan berurutan. Misalnya, Anda dapat meningkatkan langsung dari Redis OSS versi 3.0 ke versi 7.0.
Versi Redis diidentifikasi dengan OSS versi semantik yang terdiri dariMAJOR,, MINOR dan komponen. PATCH Misalnya, di Redis OSS 4.0.10, versi utama adalah 4, versi minor 0, dan versi tambalan adalah 10. Nilai-nilai ini umumnya bertambah berdasarkan konvensi berikut:
-
MAJORversi untuk perubahan yang API tidak kompatibel
-
MINORversi untuk fungsionalitas baru yang ditambahkan dengan cara yang kompatibel ke belakang
-
PATCHversi untuk perbaikan bug yang kompatibel ke belakang dan perubahan non-fungsional
Kami menyarankan untuk selalu menggunakan versi patch terbaru dalam waktu tertentuMAJOR. MINORversi untuk memiliki peningkatan kinerja dan stabilitas terbaru. Dimulai dengan ElastiCache versi 6.0 untuk RedisOSS, ElastiCache akan menawarkan satu versi untuk setiap rilis OSS minor Redis daripada menawarkan beberapa versi patch. ElastiCacheakan secara otomatis mengelola versi patch dari cluster cache Anda yang sedang berjalan, memastikan peningkatan kinerja dan keamanan yang ditingkatkan.
Kami juga merekomendasikan melakukan peningkatan secara berkala ke versi utama terbaru, karena sebagian besar perbaikan utama tidak kembali dipindahkan ke versi lama. Karena ElastiCache memperluas ketersediaan ke AWS wilayah baru, ElastiCache untuk Redis OSS mendukung dua yang terbaru. MAJOR MINORversi pada saat itu untuk wilayah baru. Misalnya, jika AWS wilayah baru diluncurkan dan yang terbaruMAJOR. MINOR ElastiCache versi untuk Redis OSS adalah 7.0 dan 6.2, ElastiCache akan mendukung Redis OSS versi 7.0 dan 6.2 di wilayah baru. AWS Seperti yang lebih baruMAJOR. MINORversi ElastiCache untuk Redis OSS dirilis, ElastiCache akan terus menambahkan dukungan untuk versi yang baru dirilis. Untuk mempelajari selengkapnya tentang memilih wilayah ElastiCache, lihat Memilih wilayah dan zona ketersediaan.
Saat melakukan pemutakhiran yang mencakup versi mayor atau minor, harap pertimbangkan daftar berikut yang mencakup perilaku dan perubahan tidak kompatibel mundur yang dirilis dengan OSS Redis dari waktu ke waktu.
Perilaku Redis OSS 7.0 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 7.0
-
SCRIPT LOAD
danSCRIPT FLUSH
tidak lagi disebarkan ke replika. Jika Anda perlu memiliki daya tahan untuk skrip, kami sarankan Anda mempertimbangkan untuk menggunakan fungsi Redis OSS. -
Saluran Pubsub sekarang diblokir secara default untuk ACL pengguna baru.
-
Perintah
STRALGO
diganti dengan perintahLCS
. -
Format untuk
ACL GETUSER
telah berubah sehingga semua bidang menunjukkan pola string akses standar. Jika Anda menggunakan otomatisasiACL GETUSER
, Anda harus memverifikasi bahwa itu akan menangani salah satu format. -
ACLKategori untuk
SELECT
,,WAIT
,ROLE
LASTSAVE
,READONLY
,READWRITE
, danASKING
telah berubah. -
Perintah
INFO
sekarang menunjukkan statistik perintah per sub-perintah, bukan di perintah kontainer tingkat atas. -
Nilai pengembalian perintah
LPOP
,RPOP
,ZPOPMIN
danZPOPMAX
telah berubah dalam kasus ekstrem tertentu. Jika Anda menggunakan perintah ini, Anda harus memeriksa catatan rilis dan mengevaluasi apakah Anda terpengaruh. -
Perintah
SORT
danSORT_RO
sekarang memerlukan akses ke seluruh ruang kunci untuk menggunakan argumenGET
danBY
.
Perilaku Redis OSS 6.2 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 6.2
-
ACLBendera
TIME
,,ECHO
ROLE
, danLASTSAVE
perintah diubah. Hal ini dapat menyebabkan perintah yang sebelumnya diizinkan untuk ditolak dan sebaliknya.catatan
Tak satu pun dari perintah ini akan mengubah atau memberikan akses ke data.
-
Saat memutakhirkan dari Redis OSS 6.0, urutan pasangan kunci/nilai yang dikembalikan dari respons peta ke skrip lua diubah. Jika skrip Anda menggunakan
redis.setresp()
atau mengembalikan peta (baru di Redis OSS 6.0), pertimbangkan implikasi bahwa skrip dapat rusak pada peningkatan.
Perilaku Redis OSS 6.0 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 6.0
-
Jumlah maksimum basis data yang diizinkan telah dikurangi dari 1,2 juta menjadi 10 ribu. Nilai default-nya adalah 16, dan kami tidak menyarankan penggunaan nilai yang jauh lebih besar dari ini karena kami telah menemukan masalah performa dan memori.
-
Setel
AutoMinorVersionUpgrade
parameter ke ya, dan ElastiCache akan mengelola peningkatan versi minor melalui pembaruan layanan mandiri. Hal ini akan ditangani lewat saluran notifikasi pelanggan standar melalui kampanye pembaruan mandiri. Untuk informasi selengkapnya, lihat Pembaruan layanan mandiri di ElastiCache.
Perilaku Redis OSS 5.0 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 5.0
-
Skrip dengan direplikasi oleh efek bukannya mengeksekusi ulang skrip pada replika. Hal ini umumnya akan meningkatkan performa tetapi dapat meningkatkan jumlah data yang direplikasi antara primer dan replika. Ada opsi untuk kembali ke perilaku sebelumnya yang hanya tersedia di ElastiCache versi 5.0 untuk OSS Redis.
-
Jika Anda memutakhirkan dari Redis OSS 4.0, beberapa perintah dalam LUA skrip akan mengembalikan argumen dalam urutan yang berbeda dari yang mereka lakukan di versi sebelumnya. Dalam Redis OSS 4.0, Redis OSS akan memesan beberapa tanggapan secara leksografis untuk membuat respons deterministik, urutan ini tidak diterapkan ketika skrip direplikasi oleh efek.
-
Inn Redis OSS 5.0.3 dan yang lebih baru, ElastiCache karena Redis OSS akan menurunkan beberapa pekerjaan IO ke inti latar belakang pada tipe instans dengan lebih dari 4. VCPUs Ini dapat mengubah karakteristik kinerja Redis OSS dan mengubah nilai beberapa metrik. Untuk informasi selengkapnya, lihat Metrik Apa yang Harus Saya Pantau? untuk memahami apakah Anda perlu mengubah metrik yang Anda lihat.
Perilaku Redis OSS 4.0 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 4.0
-
Log lambat sekarang mencatat log dua argumen tambahan, nama klien dan alamat. Perubahan ini harus kompatibel dengan versi lama kecuali jika Anda secara eksplisit mengandalkan setiap entri log lambat yang berisi 3 nilai.
-
Perintah
CLUSTER NODES
sekarang mengembalikan format yang sedikit berbeda, yang tidak kompatibel dengan versi lama. Sebaiknya klien tidak menggunakan perintah ini untuk mempelajari simpul yang ada di klaster, dan sebagai gantinya harus menggunakanCLUSTER SLOTS
.
Masa lalu EOL
Perilaku Redis OSS 3.2 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 3.2
-
Tidak ada perubahan kompatibilitas untuk memanggil versi ini.
Untuk informasi selengkapnya, lihat ElastiCache versi untuk jadwal OSS akhir hidup Redis.
Perilaku Redis OSS 2.8 dan perubahan yang tidak kompatibel ke belakang
Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 2.8
-
Mulai Redis OSS 2.8.22, Redis tidak lagi didukung OSS AOF untuk Redis. ElastiCache OSS Sebaiknya gunakan MemoryDB jika data perlu dipertahankan tahan lama.
-
Mulai dari Redis OSS 2.8.22, ElastiCache untuk Redis OSS tidak lagi mendukung melampirkan replika ke pendahuluan yang dihosting di dalamnya. ElastiCache Saat melakukan peningkatan, replika eksternal akan terputus dan tidak akan dapat terhubung kembali. Sebaiknya gunakan caching sisi klien, tersedia di Redis OSS 6.0 sebagai alternatif replika eksternal.
-
Perintah
TTL
danPTTL
sekarang mengembalikan -2 jika kunci tidak ada dan -1 jika ada tetapi tidak memiliki kedaluwarsa terkait. Redis OSS 2.6 dan versi sebelumnya digunakan untuk mengembalikan -1 untuk kedua kondisi. -
SORT
denganALPHA
sekarang melakukan pengurutan berdasarkan lokal pengumpulan lokal jika tidak ada opsiSTORE
yang digunakan.
Untuk informasi selengkapnya, lihat ElastiCache versi untuk jadwal OSS akhir hidup Redis.