Perilaku versi utama dan perbedaan kompatibilitas - Amazon ElastiCache (Redis) OSS

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perilaku versi utama dan perbedaan kompatibilitas

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 meng-upgrade langsung dari versi Redis OSS Anda saat ini ke versi Redis OSS terbaru yang tersedia, tanpa perlu upgrade berurutan. Misalnya, Anda dapat meng-upgrade langsung dari Redis OSS versi 3.0 ke versi 7.0.

Versi Redis OSS diidentifikasi dengan versi semantik yang terdiri dari komponen MAJOR, MINOR, dan PATCH. Misalnya, di Redis OSS 4.0.10, versi utama adalah 4, versi minor 0, dan versi patch adalah 10. Nilai-nilai ini umumnya bertambah berdasarkan konvensi berikut:

  • Versi UTAMA adalah untuk perubahan API yang tidak kompatibel

  • Versi MINOR adalah untuk fungsionalitas baru yang ditambahkan dengan cara yang kompatibel dengan versi lama

  • Versi PATCH adalah untuk perbaikan bug yang kompatibel dengan versi lama dan perubahan non-fungsional

Sebaiknya selalu gunakan versi patch terbaru dalam versi UTAMA.MINOR tertentu untuk mendapatkan peningkatan performa dan stabilitas terbaru. Dimulai dengan Redis OSS 6.0, ElastiCache (Redis OSS) akan menawarkan versi tunggal untuk setiap rilis minor Redis OSS, daripada menawarkan beberapa versi patch. ElastiCache (Redis OSS) akan secara otomatis mengelola versi patch dari cluster cache 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. Ketika ElastiCache memperluas ketersediaan ke AWS wilayah baru, ElastiCache (Redis OSS) mendukung dua versi MAJOR.MINOR terbaru pada waktu itu untuk wilayah baru. Misalnya, jika AWS wilayah baru diluncurkan dan versi MAJOR.MINOR ElastiCache (Redis OSS) terbaru adalah 7.0 dan 6.2, ElastiCache (Redis OSS) akan mendukung versi 7.0 dan 6.2 di wilayah baru. AWS Karena versi MAJOR.MINOR yang lebih baru dari ElastiCache (Redis OSS) dirilis, ElastiCache akan terus menambahkan dukungan untuk Versi yang baru dirilis ElastiCache (Redis OSS). 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 Redis OSS 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 dan SCRIPT FLUSH tidak lagi disebarkan ke replika. Jika Anda perlu memiliki beberapa daya tahan untuk skrip, kami sarankan Anda mempertimbangkan untuk menggunakan fungsi Redis OSS.

  • Saluran Pubsub sekarang diblokir secara default untuk pengguna ACL baru.

  • Perintah STRALGO diganti dengan perintah LCS.

  • Format untuk ACL GETUSER telah berubah sehingga semua bidang menunjukkan pola string akses standar. Jika Anda menggunakan otomatisasi ACL GETUSER, Anda harus memverifikasi bahwa itu akan menangani salah satu format.

  • Kategori ACL untuk SELECT, WAIT, ROLE, LASTSAVE, READONLY, READWRITE, dan ASKING telah berubah.

  • Perintah INFO sekarang menunjukkan statistik perintah per sub-perintah, bukan di perintah kontainer tingkat atas.

  • Nilai pengembalian perintah LPOP, RPOP, ZPOPMIN dan ZPOPMAX telah berubah dalam kasus ekstrem tertentu. Jika Anda menggunakan perintah ini, Anda harus memeriksa catatan rilis dan mengevaluasi apakah Anda terpengaruh.

  • Perintah SORT dan SORT_RO sekarang memerlukan akses ke seluruh ruang kunci untuk menggunakan argumen GET dan BY.

Redis OSS 6.2 perilaku dan perubahan mundur yang tidak kompatibel

Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 6.2.

  • Bendera ACL perintah TIME, ECHO, ROLE, dan LASTSAVE telah 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 (Redis OSS) 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 (Redis OSS) 5.0.

  • Jika Anda memutakhirkan dari Redis OSS 4.0, beberapa perintah dalam skrip LUA 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 (Redis OSS) akan menurunkan beberapa pekerjaan IO ke inti latar belakang pada tipe instance dengan lebih dari 4 vCPU. 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 menggunakan CLUSTER SLOTS.

EOL terdahulu

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 Jadwal akhir hidup versi Redis OSS.

Redis OSS 2.8 perilaku dan perubahan mundur yang tidak kompatibel

Untuk daftar lengkap perubahan, lihat Catatan rilis Redis OSS 2.8.

  • Mulai Redis OSS 2.8.22, Redis OSS AOF tidak lagi didukung di (Redis OSS). ElastiCache Sebaiknya gunakan MemoryDB jika data perlu dipertahankan tahan lama.

  • Mulai di Redis OSS 2.8.22, ElastiCache (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 dan PTTL 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 dengan ALPHA sekarang melakukan pengurutan berdasarkan lokal pengumpulan lokal jika tidak ada opsi STORE yang digunakan.

Untuk informasi selengkapnya, lihat Jadwal akhir hidup versi Redis OSS.