Actualizar entre versiones
En qué orden actualizar y qué cambia al subir de parche, de menor o de mayor.
Sube tu clúster de una versión de TeselaDB a otra sin dejar de servir. Siempre cambias el binario nodo a nodo. Solo si
la versión nueva anuncia una versión de MongoDB más reciente tienes que subir después featureCompatibilityVersion.
Requisitos
- Haber leído las notas de la versión de destino, sobre todo «Cambios incompatibles» y «Problemas conocidos».
- Que la versión de destino sea la siguiente menor de la tuya o un parche de tu misma menor. Si estás más atrás, actualiza a cada menor intermedia, una detrás de otra.
- Una copia de seguridad reciente.
Subir de parche o de menor
Cambia el binario nodo a nodo, como explica Actualizar de versión sin parada. Mientras haya nodos con las dos versiones, el clúster sigue sirviendo.
Subir de mayor
Adapta tu aplicación a los cambios incompatibles que enumeran las notas de la versión y después cambia el binario nodo a nodo como en una menor.
Activar una versión de MongoDB más reciente
featureCompatibilityVersion toma versiones de MongoDB, como 9.0. Cuando las notas dicen que la
versión nueva anuncia una versión de MongoDB más reciente, activa sus funciones en cuanto todos los nodos la tengan:
db.adminCommand({ setFeatureCompatibilityVersion: "<versión de MongoDB>", confirm: true });Comprobar
setFeatureCompatibilityVersion responde ok: 1 cuando todos los nodos admiten esa versión. Como en un mongos de
MongoDB, getParameter no devuelve featureCompatibilityVersion; esa respuesta es tu comprobación.
Problemas frecuentes
setFeatureCompatibilityVersionrechaza la versión porque algún nodo sigue con el binario anterior. Termina de cambiar el binario en todos los nodos y vuelve a lanzarlo.- Una función nueva no está disponible después de cambiar todos los binarios porque falta subir
featureCompatibilityVersion.