Hola

A ver si me podéis dar algo de luz en este asunto. No sé si es el canal adecuado, pero es el que he creido mas apropiado.

Me han encomendado la taréa de investigar si en un cluster MySQL se pueden definir tablas que residan en disco.
Corregidme si me equivoco, pero por lo que estoy mirando, al usar el motor ClusterDB, las tablas permanecen en memoria para un mejor rendimiento. El problema vendría si de alguna manera hubiese alguna catastrofe y se apagasen las máquinas. Al estar la info en memoria, no se podría recuperar. Al menos eso

es lo que he entendido.
Pero al hacer pruebas, la impresión que tengo es que de vez en cuando sí se debe hacer una escritura en disco, porque he matado adrede todo el cluster MySQL y sí que los datos se han mantenido (al menos creo que todos).
Pero independientemente de esto, y por seguridad, ¿es posible definir tablas de

alguna forma para que siempre vayan a disco y no en memoria?. Estoy mirando y lo que he podido descubrir son respuestas (en ingles) del tipo "Si quieres mantener tablas en disco, ClusterDB no es tu elección" o "Deberías pensar en cambiar en motor de BBDD".

Y bueno, voy a seguir mirando (en ratos sueltos porque me tienen liado con una cabina de discos), pero prefería preguntar por aquí y ganar algo de tiempo, o al menos corroborar si lo que he investigado hasta ahora es cierto.

Cualquier ayuda/aclaración es bienvenida.

Gracias

--- Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
# Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hola Oscar!

Martes 10 Noviembre 2015 10:39, Oscar Acu¤a escribio a All:

Hola

A ver si me pod‚is dar algo de luz en este asunto. No s‚ si es el canal adecuado, pero es el que he creido mas apropiado.

Me han encomendado la tar‚a de investigar si en un cluster MySQL se pueden definir tablas que residan en disco. Corregidme si me equivoco, pero por

http://www.clusterdb.com/mysql-cluster/how-can-a-database-be-in-memory-and-dura

ble-at-the-same-time


Saludos
Javier

--- FPD v2.9.040207 GoldED+/W32-MINGW 1.1.5-b20070116
# Origin: Beholder , nuevo hogar (2:343/107.51)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hola

OA> Me han encomendado la taréa de investigar si en un cluster MySQL se

pueden

OA> definir tablas que residan en disco. Corregidme si me equivoco, pero

por

http://www.clusterdb.com/mysql-cluster/how-can-a-database-be-in-memory-and-dura
ble-at-the-same-time

Gracias!!! Era justo lo que buscaba. Sospechaba de ese funcionamiento, pero necesitaba demostrarlo. Me viene de perlas, porque no tenía tiempo para dedicarle a este asunto y lo tenía un poco parado.

Un saludo y gracias de nuevo

--- Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
# Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

­Hola Oscar!

El Martes 10 Noviembre 2015 a las 10:39, Oscar Acuña escribió a All:

Me han encomendado la taréa de investigar si en un cluster MySQL se
pueden definir tablas que residan en disco. Corregidme si me equivoco, pero por lo que estoy mirando, al usar el motor ClusterDB, las tablas permanecen en memoria para un mejor rendimiento. El problema vendría
si de alguna manera hubiese alguna catastrofe y se apagasen las
máquinas. Al estar la info en memoria, no se podría recuperar. Al
menos eso es lo que he entendido.

Ten en cuenta que, por encima de todo, estás hablando de un sistema de bbdd transaccional. Por tanto, cualquier cambio que efectúes en una tabla, lo bajarás a disco para asegurar la persistencia/durabilidad del dato.

Yo me muevo con el padrastro de MySQL, Oracle, y sus opciones de HA e In-Memory

hacen eso mismo (parecido)... la escalabilidad física de la base de datos y la subida a RAM de los datos que definamos... pero sin perder la transaccionalidad

y la persistencia de los datos.

Por tanto, no temas... ...mucho. :-D Pero ten presente que contra un power-off descontrolado y salvaje nadie está a salvo al 100%.


-
A reveure!!
Enric
__________________________________________________________________
FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

... La ciencia humana consiste más en destruir errores que en descubrir verdades.
--- crashmail + golded + binkd
# Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

­Hola Javier!

El Martes 17 Noviembre 2015 a las 17:06, Javier Prieto escribió a Oscar Acuña:

http://www.clusterdb.com/mysql-cluster/how-can-a-database-be-in-memory -and-dura ble-at-the-same-time

Eso mismo. :-)

-
A reveure!!
Enric
__________________________________________________________________
FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

... Los principios siempre tienen sentido hasta que la cosa se vuelve personal. --- crashmail + golded + binkd
# Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hola

Ten en cuenta que, por encima de todo, estás hablando de un sistema de
bbdd transaccional. Por tanto, cualquier cambio que efectúes en una
tabla, lo bajarás a disco para asegurar la persistencia/durabilidad del dato.

Con esa premisa no pueden quedar dudas. A ver si no me ponen mas pegas

Por tanto, no temas... ...mucho. :-D Pero ten presente que contra un power-off descontrolado y salvaje nadie está a salvo al 100%.

Si :-DD ante eso poco se puede hacer

Gracias enric

--- Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
# Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hola Enric!

Viernes 20 Noviembre 2015 08:31, Enric Lleal Serra escribio a Oscar Acu¤a:

Por tanto, no temas... ...mucho. :-D Pero ten presente que contra un power-off descontrolado y salvaje nadie est  a salvo al 100%.

Las memorias persistentes de las cabinas de discos pueden ayudar... pero ya es otra liga alomejor....


Javier

--- FPD v2.9.040207 GoldED+/W32-MINGW 1.1.5-b20070116
# Origin: Beholder , nuevo hogar (2:343/107.51)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

­Hola Oscar!

El Lunes 23 Noviembre 2015 a las 09:10, Oscar Acuña escribió a Enric Lleal Serra:

una tabla, lo bajarás a disco para asegurar la
persistencia/durabilidad del dato.

Con esa premisa no pueden quedar dudas. A ver si no me ponen mas pegas

Ya contarás. :-) Y si necesitas referencias, tira de aquí[1] y si no, avísame y

hablo con quien sea... ;-)

[1]https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html


-
A reveure!!
Enric
__________________________________________________________________
FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

... Vayamos por partes, dijo el forense.
--- crashmail + golded + binkd
# Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

­Hola Javier!

El Lunes 23 Noviembre 2015 a las 12:57, Javier Prieto escribió a Enric Lleal Serra:

Las memorias persistentes de las cabinas de discos pueden ayudar...
pero ya es otra liga alomejor....

Dependerá del nivel de cache que tengan las controladoras y los discos.

Pero sí, tienes razón, por precios ya estamos hablando de ligas distintas (cuando miras dos componentes parecidos con precios muy distintos, fíjate que el caro es el que tiene mejor cache).


-
A reveure!!
Enric
__________________________________________________________________
FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

... La cifra que parece más correcta... es la equivocada.
--- crashmail + golded + binkd
# Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hola

>> una tabla, lo bajarás a disco para asegurar la
>> persistencia/durabilidad del dato.
OA> Con esa premisa no pueden quedar dudas. A ver si no me ponen mas pegas

Ya contarás. :-) Y si necesitas referencias, tira de aquí[1] y si no,
avísame y hablo con quien sea... ;-)

Gracias por la info y el interes mostrado :-)
Al final ha ido bien. Nos dieron un poco la paliza con que demostrásemos con pruebas que era así, y finalmente conseguimos que nos diesen el OK.

A ver si le doy una ojeada a la info que me indicas, que siempre vendrá bien, pero vamos, que en principio, todo OK

Venga Enric, un saludo y gracias

--- Claws Mail 3.13.0 (GTK+ 2.24.29; x86_64-pc-linux-gnu)
# Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

­Hola Oscar!

El Viernes 01 Enero 2016 a las 20:09, Oscar Acuña escribió a Enric Lleal Serra:

Al final ha ido bien. Nos dieron un poco la paliza con que
demostrásemos con pruebas que era así, y finalmente conseguimos que
nos diesen el OK.

:-) Pues me alegro.

Yo tengo la suerte/desgracia que más que justificar la tecnología tengo que justificar los costes, y eso sí que es un peñazo. Con la técnica, al menos aprendes y te diviertes cuando te documentas o cuando montas una prueba de concepto... Con lo otro, un caso de negocio te hunde en la miseria anímica. ;-)


-
A reveure!!
Enric
__________________________________________________________________
FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

... La gracia de ser escritor es poder crear un personaje más atractivo que tú. --- crashmail + golded + binkd
# Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)