Gracias Aldrin por tu respuesta. Para la solucion de las aplicaciones me parece bien si existe un solo servidor. En mi caso son tres servidores y no puedo tener 3 otras maquinas en espera.
Para el caso 2, cual respaldo en linea tu recomendarias ? Gracias una vez mas. Eduardo 2011/6/8 Aldrin Martoq <[email protected]> > > On Jun 6, 2011, at 5:47 PM, Ricardo Munoz wrote: > > El 6 de junio de 2011 16:02, Eduardo Mena <[email protected]> escribió: > >> Gracias Carlos por tu respuesta. > >> Mi preocupacion principal es si el S.O y disco duro con todas sus > >> particiones se danhan. > >> Mi idea es tener un plan de contingencia para que todo vuelva a la > >> normalidad inmediatamente. > >> Yo uso MySQL, pero no tendria problema con la base de datos. > > creo que MySQL Cluster es tu unica opcion. > > Hacer el respaldo al estilo "rsync" no es óptimo, y como dice Victor un > condoro en el servidor principal se replica en el servidor standby. > > Lo importante no es respaldar el tarro completo bit a bit con particiones, > sistema operativo y todo. Lo que debes respaldar es: > 1- las aplicaciones > 2- los datos > > Para el 1, arma servidores de espera que tengan el mismo software que el > original y los dejas al agüaite. Ojo que debes validar con cierta frecuencia > que el respaldo completo funciona acá. > > Si realmente necesitas disponibilidad 99.9999999999% como indicas, tienes > que usar alguna solución del estilo cluster tanto en la base de datos como > en las aplicaciones. Esto te garantiza que si hay una falla de red/hardware > o incluso software, otro tarro que no esté enfermo pueda atender clientes. > Hay sistemas que automatizan todo esto, lo malo es que es MUY complicado de > lograr bien y usualmente requieres ayuda del código de la aplicación para > que funcione de maravillas (o al contrario, una aplicación no > preparada/pensada para funcionar en un cluster es un dolor de cabeza). > Muchas veces uno no necesita esto o no tiene la capacidad para lograrlo. > > > Para el 2, lo que te recomienda es utilizar un respaldo "en línea" basado > en los registros o deltas que se hacen en la base de datos. Esto es: cada > vez que hay un INSERT, UPDATE o DELETE en la base de datos, esta información > viaja casi inmediatamente a un servidor remoto que ejecuta la misma > sentencia al otro lado. Esto te garantiza no solo que tienes la base de > datos casi en línea en un servidor remoto, sino que además puedes guardar el > historial de cambios y moverte en cualquier punto (por ejemplo, puedes > deshacer un DELETE). Si la data es importante (casi siempre lo es!) deberías > conseguir que dicho server esté en otro datacenter a varios Km del servidor > principal. > > > Cada base de datos tiene su terminología/nombre_vendedor para esto, por > ejemplo en oracle creo se llama DataGuard. Bueno, con replication en la base > de datos y servidores de espera es mucho más fácil levantarse de una caída > fea, yo prefiero esta ruta. > > > > Aldrin Martoq > http://aldrin.martoq.cl/ > > > > > >
