Hoy vamos con otra de las entradas para dummies, viendo un poco el funcionamiento del redo en el RAC.
\nCada instancia dentro del RAC debe de tener su propio espacio de redo (que se corresponder\u00e1 con un n\u00famero \u00fanico de thread<\/i> para toda la instancia) y undo.<\/p>\n
Pero que ocurre si muere un nodo?
\n\u00bfQue pasa con los datos que est\u00e1n en esos redos?<\/p>\n
En un entorno de RAC, todas las instancias de la base de datos tienen acceso a todos los redo logs<\/i> de todos los nodos, de esta manera, si uno de los nodos muere, uno de los nodos vivos acceder\u00e1 a el redo de la instancia ca\u00edda y aplicar\u00e1 de manera autom\u00e1tica los cambios de la misma manera que se har\u00eda un instance recovery<\/i> a la hora de arrancar la base de datos. Con lo que los datos en disco siempre estar\u00e1n consistentes.<\/p>\n
\u00bfQue ocurre si caen todos a la vez?
\nSi todas las instancias cayeran el instance recovery<\/i> ser\u00eda llevado a cabo por la primera de las instancias que se levantara, esta ser\u00eda la encargad de hacer el instance recovery<\/i> de todos los redos de todas las instancias del rac.<\/p>\n
Como veis, a pesar de la complejidad del RAC, el funcionamiento no deja de ser muy sencillo, al menos, visto desde arriba \ud83d\ude09 <\/p>\n","protected":false},"excerpt":{"rendered":"
Hoy vamos con otra de las entradas para dummies, viendo un poco el funcionamiento del redo en el RAC. Cada instancia dentro del RAC debe de tener su propio espacio de redo (que se corresponder\u00e1 con un n\u00famero \u00fanico de … Sigue leyendo