El problema es que tienen que ser MyISAM porque la aplicacion tiene
unos 5 años, y la verdad que la mayor parte del tiempo solo se hacen
consultas, no se usan ni vistas, ni procedimientos almacenados, ni
transacciones ni nada,,,, es por ello que no esta mal la eleccion que
hicieron en su momento, la logica está ya implementada en la
aplicacion y esto no se va a cambiar en un par de minutos un trabajo
de tantos años.
Pero el caso es que no puedo hacer ese cambio tan drástico sobre la
base de datos donde tenemos mas de 200 tablas y con grandes cantidades
de datos... es mas facil de implementar la replicacion propia de mysql
y menos costasa para mi situacion y solo si se hace un rediseño entero
de la aplicacion ir a por innodb.
De todos modos gracias por echar una mano.
El día 5/06/07, *Alejandro Santos* <alejolp@alejolp.com
<mailto:alejolp@alejolp.com>> escribió:
El 5/06/07, Roberto Leon Lopez <i32lelor.debian@gmail.com
<mailto:i32lelor.debian@gmail.com>> escribió:
> Pues creo que no me vale, fijate:
>
> 28.14.3.2 <http://28.14.3.2>: What MySQL storage engines are
supported with DRBD?
>
> All of the MySQL transactional storage engines are supported by
DRBD,
> including InnoDB and Falcon. For archived or read-only data,
MyISAM or
> Archive can also be used.
>
> Y en mi caso el 98% de las tablas son MyISAM.
>
Buenisimo entonces! El 98% de las tablas van a funcionar. Lo único
que
tenés que hacer es convertir las tablas MyISAM a INNODB. La diferencia
entre estas dos es la forma interna de funcionamiento, y nada mas. El
cambio desde MyISAM a INNODB deberia ser totalmente compatible, y más
aún, InnoDB te trae transacciones cosa que MyISAM no.
Como siempre, sería bueno hacer algun experimento para ver si hay
algún problema.
>
> El día 5/06/07, Alejandro Santos < alejolp@alejolp.com
<mailto:alejolp@alejolp.com>> escribió:
> > Hola!
> >
> > El 5/06/07, Roberto Leon Lopez < i32lelor.debian@gmail.com
<mailto:i32lelor.debian@gmail.com>> escribió:
> > > Estamos estudiando la posibilidad de montar un cluster de alta
> > > disponibilidad.
> > >
> > > Heartbeat ya lo controlamos. Ahora el caso es que
intentaremos comprar
> un
> > > almacen externo con Raid 5.. esto vale una pasta pero es la
mejor opcion
> ya
> > > que tienes los mismo datos y no hay que replicarlos.
> > >
> > > Pero tambien hay que estudiar la posibilidad de que no haya
presupuesto
> para
> > > el almacen externo y entonces me planteo usar la tecnica de
replicacion
> > > maestro/esclavo propia de MySQL y no se si es mejor que drbd
que trabaja
> a
> > > nivel de bloques y lo que puede ocurrir ante una
interrupción a medio
> > > escribir un bloque, usamos ext3 con journaling claro está,
¿si hay corte
> es
> > > dicho journaling quien debe resolver el problema?.
> > >
> >
> > http://www.mysql.com/products/enterprise/drbd.html
<http://www.mysql.com/products/enterprise/drbd.html>
> >
> > ¿Te sirve eso? Por lo que veo, MySQL soporta DRBD.
> >
> > > Tambien tengo que replicar ficheros y para ello hasta ahora
la mejor
> opcion
> > > era unison que es bidireccional y no como rsync, pero no se
replica
> online
> > > sino cada x tiempo que se programe.
> > >
> >
> > No se cuales sean tus necesidades concretas, pero un cron cada
10 ó 15
> > minutos debería alcanzar, no?
> >
> > La otra opción es usar algun sistema de archivos distrubuido,
algo que
> > por cierto nunca usé.
> >
> > > Saludos al foro.
> > >
> >
> > Saludos,
> > Alejo
> >
>
>