WEBVTT

00:00:09.230 --> 00:00:11.010
Hola Keith, ¿qué tal? Buenas tardes.

00:00:11.050 --> 00:00:13.230
Hola, ¿qué tal? Bien, bien.

00:00:13.830 --> 00:00:20.850
Qué bien, qué bien. Por fin nos hablamos y
nos conocemos de la comunidad, de la comunidad

00:00:20.850 --> 00:00:23.610
de España de Osarios de Araclet.

00:00:24.650 --> 00:00:26.094
Sí, qué bien. ¿Cómo estás?

00:00:27.150 --> 00:00:29.730
Bien, bien. Aquí pasando
calor, aquí en Valencia.

00:00:29.770 --> 00:00:31.326
Sí, yo te decía en Valencia.

00:00:31.650 --> 00:00:37.140
¿Eres de café o de té? Hombre, soy
de café o sea, hay que tomar café.

00:00:37.220 --> 00:00:39.320
Lo que pasa es que, bueno, de
vez en cuando una infusión...

00:00:39.360 --> 00:00:45.780
Pero no soy un buen inglés en ese sentido
Muy bien, muy bien Vamos a hablar de MySQL

00:00:45.780 --> 00:00:52.840
Hoy tú eres la estrella Vas a contarnos
más de MySQL De lo que yo voy a

00:00:52.840 --> 00:00:57.080
aportar Sí, quiero que comparemos la parte
de clúster Ya que vamos a empezar hablando

00:00:57.120 --> 00:01:03.840
de clúster Los clústeres en condiciones de
Oracle Y los clústeres de Chichinabo Que hay

00:01:03.840 --> 00:01:10.140
en MySQL Los clústeres de Chichinabo
Que pueda tener MySQL Vamos a ver.

00:01:10.260 --> 00:01:13.360
Oye, oye, ten cuidado la
opción cara, la opción barata.

00:01:14.920 --> 00:01:16.864
Sí, claro no, eso sí que es cierto.

00:01:16.960 --> 00:01:19.660
No, cuidado, cuidado cuidado,
que eso sí que es verdad.

00:01:19.700 --> 00:01:23.800
Pero claro, a ver si vamos a tener que
hablar de todos esos clientes famosísimos que

00:01:23.840 --> 00:01:26.020
usan MySQL y soluciones de HA.

00:01:27.000 --> 00:01:31.860
Cuidado, eh, cuidado claro, cuidado porque
por aquí tenemos varias opciones, otras opciones

00:01:31.900 --> 00:01:38.960
baratas, ¿no? Está el Standard Edition
con el SEHA, el Standard Edition High

00:01:38.960 --> 00:01:44.900
Availability y en otro episodio estuvimos
hablando con Loles sobre postgreSQL, es decir,

00:01:44.980 --> 00:01:51.720
hablando de cosas gratuitas y de más o
menos disponibilidad, más alta, un poco más bajita,

00:01:51.760 --> 00:01:56.260
aquí tenemos muchas opciones
y muchas posibilidades, ¿no?

00:01:56.260 --> 00:02:02.770
No, no, totalmente de hecho, yo antes
estaba en Oracle, en la parte de SQL y antes de

00:02:02.770 --> 00:02:08.390
eso, en la parte de ACS, Advanced Customer
Services, con lo cual, pues, la base de Oracle,

00:02:08.550 --> 00:02:14.650
el tema RAC, cuando hacía pinging en la
versión 7, porque aún no tenía los discos compartidos

00:02:14.650 --> 00:02:19.050
y demás, eso era un nefasto de Oracle, pero
luego, o sea, lógicamente, parte de 8 .0

00:02:19.090 --> 00:02:20.670
en adelante, 8 .i ya estaba bien.

00:02:20.710 --> 00:02:27.870
Y yo ya a las más o menos ahora que 11 lo
dejé y luego me metí en el mundo más secuel

00:02:27.870 --> 00:02:32.830
entonces claro sé qué pasa que el claro
más secuel es entonces el diálogo es distinto

00:02:32.830 --> 00:02:37.770
el primero y ahora como no estoy en oracle
yo puedo decir lo que me da la gana entonces

00:02:37.770 --> 00:02:43.530
Y ahora que no patrocina episodios aquí.

00:02:43.990 --> 00:02:46.610
Ya lo sé, ya lo sé ni amigos ni enemigos.

00:02:47.990 --> 00:02:51.590
Eso es, a lo que realmente iba
es el tema de community, ¿no?

00:02:51.650 --> 00:02:58.410
En MySQL Community se desconoce por
completo la cantidad de MySQL que hay por allí, tanto

00:02:58.410 --> 00:03:05.650
en cloud como en on -premise, en PCs,
en servidores así pequeñitos por ahí y y

00:03:05.650 --> 00:03:14.190
funcionan es que eso es lo malo es
que es bueno es decir para montar una

00:03:14.190 --> 00:03:22.590
web con wordpress pues oye no linux
apache sql y tira que te va pero

00:03:22.840 --> 00:03:29.880
vamos a hablar de cluster porque esto
es muy muy fácil de hecho a eso iba a

00:03:29.880 --> 00:03:36.440
eso iba al tema de sql así puesto así pues
single instance vale fenómeno pero qué pasa

00:03:36.440 --> 00:03:41.540
que quiero replicar los datos quiero
duplicar quiero tener hacha y claro más sql de por

00:03:41.540 --> 00:03:46.320
sí tiene pues lo que es lo equivalente a
un data guard vale qué significa eso más iguales

00:03:46.360 --> 00:03:52.140
replication y dices pues claro puedo
replicó de un lado a otro eso es un un mecanismo

00:03:52.140 --> 00:03:58.560
pues donde pasó los logs todo de alta pues
lo que es la instancia que por temas de black

00:03:58.560 --> 00:04:03.160
lives matter ahora se llama secundario pero
lo que lo conocemos pues es master slate

00:04:03.200 --> 00:04:08.940
pero es primario secundario o source
secundario y demás vale pero el secundario se levanta

00:04:08.940 --> 00:04:14.880
copiando de primero y dices venga conéctate
a este ese es tu instancia primaria pero

00:04:14.880 --> 00:04:19.480
es que yo puedo tener todas las réplicas
que quiero y en cadena lejos no sé yo tengo

00:04:19.520 --> 00:04:25.920
puedo vamos 56 vamos A ir más despacio
vamos a ir más despacio y la replicación física

00:04:25.920 --> 00:04:32.750
o replicación lógica a esta es una buena
prueba en lo que no era que tendríamos en hora

00:04:32.750 --> 00:04:36.410
que tendríamos el data guard cuando has
dicho sería lo que sería el de atacar de atacares

00:04:36.450 --> 00:04:41.630
físico y la otra réplica es absolutamente
física y ahora ya te te empiezo a poner aquí

00:04:41.630 --> 00:04:43.010
y vamos a empezar a pelearnos.

00:04:43.050 --> 00:04:48.410
Una corrupción que podamos tener en una
Seatos primaria, por ejemplo, como el bloque

00:04:48.410 --> 00:04:54.650
físico de la réplica es idéntico, puede
servirnos para reparar, digamos, la corrupción

00:04:54.650 --> 00:05:00.210
primaria. MySQL tiene replicación
física o no, o lógica.

00:05:00.290 --> 00:05:01.957
Esas transacciones, ¿cómo van?

00:05:03.630 --> 00:05:09.650
Ahí está. Olvídate de la física,
porque ¿qué ocurre en MySQL?

00:05:09.830 --> 00:05:17.150
Pues la instancia primaria envía su
equivalente ArchiveLog, su BinLog y lo manda, o

00:05:17.150 --> 00:05:23.590
realmente lo recoge el cliente, el
secundario lo recoge, porque tiene permisos y lo recoge

00:05:23.590 --> 00:05:29.570
y manda ese log, con lo cual ya no es
física, porque si me dices, pues se corrompe un

00:05:29.570 --> 00:05:35.870
bloque pues ahí se queda, en la primaria
lo que yo llevo es la copia del BinLog, me llevo

00:05:35.870 --> 00:05:42.190
mi ArchiveLog, por lo tanto ese ArchiveLog
que contiene, pues Pues antiguamente era uno

00:05:42.190 --> 00:05:44.990
de tres. Uno era statement,
es decir, lógica.

00:05:45.010 --> 00:05:52.430
Yo hago un update all, si es date menos
uno, ya entra al mundo de corrupciones

00:05:52.430 --> 00:05:58.190
posibles. Porque claro, en cuanto me lleva
un segundo para llevar del primaria a cualquier

00:05:58.190 --> 00:06:03.250
réplica, ese statement,
esa lógica se rompía.

00:06:03.250 --> 00:06:09.810
Entonces dices vale bien vamos intentando
hacer las statement cuando pasa pues hacemos

00:06:09.810 --> 00:06:14.690
row dice vale pues en más secuelas se decía
inicialmente vamos a hacer pero claro la

00:06:14.690 --> 00:06:21.150
fila entera aunque yo modifique un byte sí
señor eso fue antes no antes de 56 pero y

00:06:21.150 --> 00:06:26.310
dice me llevo toda la fila que puedo tener
aquí pues en 100 columnas y por un byte pues

00:06:26.310 --> 00:06:31.890
dice pues no era práctico no se inventó lo
de mix dices vale pues ya tengo el pin log

00:06:31.890 --> 00:06:36.690
format igual a mix que cuando aplico
statement cuando puedo cuando está seguro bien Y

00:06:36.690 --> 00:06:41.190
si no pues aplicó rock pero eso no
funcionaba entonces qué pasa pues el versión de 56

00:06:41.230 --> 00:06:47.590
adelante era raw pero llévame lo que ha
cambiado tampoco me llevo el bloque se me llevó

00:06:47.590 --> 00:06:54.990
la lo que es el cambio a nivel de fila y
aplicó ese cambio y no no como una sentencia.

00:06:55.170 --> 00:07:02.100
Con lo cual ni es físico, ni es lógico, y
es como una pequeña, es como una lógica interna

00:07:02.100 --> 00:07:03.360
como quien podría decir, ¿no?

00:07:03.400 --> 00:07:07.560
No estamos aplicando bloques
de un lado a otro y ya está.

00:07:07.640 --> 00:07:09.540
Y si cambio el disco, se rompe.

00:07:09.620 --> 00:07:12.240
No es así, ¿vale? Punto para Oracne.

00:07:16.030 --> 00:07:21.230
Es que si me dices, por ejemplo, tienes
que pensar que la replicación así, el clúster,

00:07:21.370 --> 00:07:25.370
es como el Data Guard, si me lo comparas
con el Data Guard lógico, pues...

00:07:26.730 --> 00:07:33.990
Aquí Aquí la ventaja Me gusta
más Bien, bien Luego tenemos

00:07:33.990 --> 00:07:39.430
la posibilidad De hacer replicaciones Es
que estamos hablando de replicaciones Y quizás

00:07:39.430 --> 00:07:45.110
no de clasterización Como yo entiendo el
clúster de dos servidores En paralelo, procesando,

00:07:45.190 --> 00:07:50.910
digamos Interconectados Digamos, pero
procesando Ya llegaremos ahí, ¿vale?

00:07:50.990 --> 00:07:58.870
Venga Por la replicación No
es física Es lógica Vale,

00:07:58.950 --> 00:08:02.370
entonces, una cosa, por ejemplo
¿Cuál sería la diferencia?

00:08:02.690 --> 00:08:05.301
Por ejemplo, no sé si
conoces GoldenGate Claro,

00:08:06.500 --> 00:08:09.880
¿cuál sería la diferencia, digamos Entre,
porque en GoldenGate también hay GoldenGate

00:08:09.920 --> 00:08:17.410
Para MySQL Sí, sí GoldenGate es un
producto de Oracle Y tiene el heterogeneous

00:08:17.410 --> 00:08:20.750
services Para conectar Pues GoldenGate

00:08:21.770 --> 00:08:26.590
perdón, MySQL, Oracle y la casa que
quieras, ese Postgres, etcétera, etcétera.

00:08:26.610 --> 00:08:28.777
Eso también lo puedes hacer si quieres.

00:08:29.610 --> 00:08:34.090
Pero antes de eso, antes de GoldenGate,
en la parte de réplica yo puedo filtrar.

00:08:34.350 --> 00:08:40.570
Yo puedo generar en la primaria y si yo
tengo cinco esquemas, yo puedo tener cinco réplicas

00:08:40.570 --> 00:08:43.210
y cada uno replicando
exclusivamente el esquema.

00:08:43.250 --> 00:08:48.210
No me tengo por qué llevar
todo a cada secundaria, ¿no?

00:08:48.210 --> 00:08:53.630
Pero entonces, quiero decir, abandonamos
el streams, o sea, lo que es el data guard lógico

00:08:53.630 --> 00:08:58.630
de los streams, ¿vale? Nos olvidamos un
poco de esto y si, digamos, tendríamos una solución

00:08:58.670 --> 00:09:02.640
más o menos conjunta, pudiendo utilizar
GoldenGate en los dos casos, ¿no?

00:09:02.680 --> 00:09:09.840
Por ejemplo sí, sí, sí entonces, si yo
aplico en cada cinco de mis réplicas, pues,

00:09:09.860 --> 00:09:14.220
solamente los datos correspondientes
a esos esquemas, bien.

00:09:14.360 --> 00:09:16.860
Aplico filtros en los secundarios.

00:09:16.960 --> 00:09:18.480
Que también lo puede hacer en primaria.

00:09:18.520 --> 00:09:24.800
Es decir, si solo quisieras extraer
o bien un esquema o una tabla sola.

00:09:25.240 --> 00:09:27.400
O sea, que dice, mira, de
este esquema, esta tabla.

00:09:27.440 --> 00:09:31.020
O este grupo de tablas o no
me repliques este esquema.

00:09:31.100 --> 00:09:33.340
No me repliques o lo ignore o doom.

00:09:33.740 --> 00:09:37.860
Y eso se puede hacer o sea, que con lo
cual, pues eso es configurable tanto en la primaria

00:09:37.900 --> 00:09:42.580
como en secundaria. Con lo cual, dices,
vale, bueno, y eso se hace, lógicamente, para

00:09:42.620 --> 00:09:44.200
protección de datos, etc.

00:09:45.500 --> 00:09:48.500
Dices, bien, Eso es una opción, ¿vale?

00:09:48.520 --> 00:09:52.540
Antes de llegar a GoldenGate y
eso viene nativo de Maseweller.

00:09:55.020 --> 00:09:57.798
Estoy tomando el cafecito
con calma, escuchándote.

00:09:58.150 --> 00:10:05.130
Vale, Entonces dices, bien, pero
eso no es clúster, totalmente.

00:10:05.730 --> 00:10:13.230
Claro, es que para mí el clúster o
la solución de clúster es, primero,

00:10:13.270 --> 00:10:19.070
evidentemente, la alta disponibilidad a
nivel de nodo, a nivel de servidor pero también

00:10:19.070 --> 00:10:26.390
sobre todo la posibilidad de procesar en
paralelo que esa es quizá la gran gracia

00:10:26.390 --> 00:10:33.550
que a lo mejor puede tener cuando
tú tienes pues eso una gran base

00:10:33.550 --> 00:10:39.770
de datos con un volumen muy alto de
transacciones poder balancear o distribuir o digamos

00:10:39.770 --> 00:10:46.850
utilizar en una fase ya llegaréis
bueno Bueno, no, no, no,

00:10:46.850 --> 00:10:51.330
no, no, no, no, no, no, no, hoy, hoy os
comentaré, o sea, vamos a hablar hoy sobre las

00:10:51.370 --> 00:10:58.150
opciones que hay para eso, porque antes de
nada descartar lo que no es MySQL en MySQL

00:10:58.150 --> 00:11:03.690
Cluster, ¿vale? Porque si hablemos de
clúster como en Oracle, pues está el MySQL y no

00:11:03.690 --> 00:11:10.450
DB clúster, está el MySQL clúster, que es
NDB, tablas NDB, y luego están las opciones

00:11:10.450 --> 00:11:15.990
de MySQL en clúster, que no es clúster de
MySQL ni de Oracle, sino el clúster que hay

00:11:15.990 --> 00:11:19.810
por ahí. Muy bien eso es
como una cosa de RBD, ¿vale?

00:11:19.910 --> 00:11:23.670
Eso es un poco más lo que tú dices de
Gatagard, que me llevo los datos físicos, pero

00:11:23.710 --> 00:11:29.750
era totalmente activo -pasivo y dependía
de RBD, Distributed Roadblock Device, que me

00:11:29.750 --> 00:11:34.970
copiaba físicamente de disco a disco a
través de Pacemaker y Corosync y dice, vale, ya

00:11:34.970 --> 00:11:37.350
tengo Un MySQL en clúster ¿Qué pasa?

00:11:37.510 --> 00:11:43.050
Que bien, falla el primario y me tengo que
levantar, tengo que bailar todo hacia el otro

00:11:43.050 --> 00:11:50.390
lado y levantarlo. Dices, exacto, sí,
dices, a ver, eso primero y luego fail

00:11:50.420 --> 00:11:56.720
back o switch back. No no no paga vámonos
porque eso era dolorosa y eso se soportaba

00:11:56.720 --> 00:12:02.680
en hace años en mysql y lo dejamos de
soportar porque dices mira no se está más pegando

00:12:02.680 --> 00:12:07.580
aquí una leche con coro sin con pacemakers
y de remedio que no eran ni siquiera productos

00:12:07.620 --> 00:12:13.500
ni demás y cole de oracle ni de nadar open
source y había un grupo pequeño de gente decía

00:12:13.500 --> 00:12:20.140
mira no no no no o sea, que MySQL en
clúster era de RBD, etcétera y tal, y dicen, mira,

00:12:20.160 --> 00:12:24.420
no, no, entonces lo siguiente
que estaba que ya existía era

00:12:25.640 --> 00:12:28.400
NDB, MySQL NetWeb Database

00:12:29.340 --> 00:12:36.450
Vale, entonces esas tres soluciones de
clúster, vamos a ver y cuál o sea, aquí no

00:12:36.450 --> 00:12:40.810
estamos haciendo una charla de producto,
aquí estamos hablando como si fuésemos dos DBAs

00:12:40.850 --> 00:12:45.230
que estamos trabajando en la misma empresa
y yo te digo vamos a ver, de lo que me acabas

00:12:45.270 --> 00:12:50.630
de decir ¿qué te gusta?
¿o qué me recomiendas?

00:12:50.670 --> 00:12:53.370
¿o tú qué harías? ¿o
para qué es cada caso?

00:12:53.610 --> 00:12:56.650
Es decir ¿esto va bien para este caso?

00:12:56.790 --> 00:12:58.190
¿esto va mal para este caso?

00:12:58.230 --> 00:13:03.390
¿cuál de los clústeres? Mira, pues,
empresas pequeñas o grandes datos, o lo que sea para

00:13:03.390 --> 00:13:08.168
grandes volúmenes yo pondría tal cosa pero
tu opinión, aquí te estás mojando tú, o sea

00:13:09.590 --> 00:13:14.810
Aquí, después quedará grabado y diremos,
¿quién dijo que para grandes volúmenes de datos

00:13:14.810 --> 00:13:16.710
era esta solución de clúster.

00:13:17.210 --> 00:13:21.830
Así que dueño de tus palabras,
¿cuál recomendarías por ejemplo?

00:13:24.970 --> 00:13:30.150
Venga voy a poner varios escenarios, una
grandes volúmenes de datos, otra grandes volúmenes

00:13:30.150 --> 00:13:36.770
de transacciones y otra pues bueno pues un
entorno a lo mejor como es activo o pasivo

00:13:36.770 --> 00:13:41.230
o como sería pues un entorno para hacer
transacciones y otro entorno que fuera solamente

00:13:41.270 --> 00:13:48.590
de lectura como simulando una
actividad agar o algo así en que en qué

00:13:48.590 --> 00:13:55.930
opciones te apoyaría es que sería
tu apuesta es y no debe clúster

00:13:55.930 --> 00:14:02.470
vale más secuela debe clúster porque es las
son las tablas y no deben que para quien

00:14:02.470 --> 00:14:06.750
conozca más escuela el distinto tipo de
tablas pero es la más parecida ahora que los

00:14:06.790 --> 00:14:13.910
transaccionales es acid y todo eso y no
debe clase son mínimo tres instancias no

00:14:13.910 --> 00:14:19.590
puedes montar con uno pero no tiene
sentido pero es como un activo lleva esta capa de

00:14:19.590 --> 00:14:26.950
comunicación adicional aparte de pasar los
logs y demás los datos hacia un lado de y

00:14:26.950 --> 00:14:32.310
realmente es una réplica con consistencia
eventual significa significa eso?

00:14:32.410 --> 00:14:38.710
Me aseguro que el dato está en dos
instancias de las tres o en la mayoría ante una situación...

00:14:38.710 --> 00:14:41.050
Consistencia eventual suena mal.

00:14:41.760 --> 00:14:47.140
Ya, ya, ya. Máxima
disponibilidad no tanto, ¿no?

00:14:48.620 --> 00:14:50.453
Es como si dijeras algo así, ¿no?

00:14:50.600 --> 00:14:52.960
Máxima protección desprotegida.

00:14:55.470 --> 00:14:56.590
Eventualmente desprotegida.

00:14:56.630 --> 00:15:00.640
Al rato no, no lo que pasa es que dice

00:15:01.880 --> 00:15:07.280
Nosotros actualizamos una fila dentro de
una tabla y dices, vale, esa fila se tiene que

00:15:07.280 --> 00:15:12.400
replicar. Pues si estoy solo, si me quedo
la instancia sola porque por lo que sea se

00:15:12.400 --> 00:15:15.178
han ido los demás, pues
el registro se queda aquí.

00:15:15.300 --> 00:15:18.580
Y el clúster empieza a decir,
vale, ¿qué leches ha pasado aquí?

00:15:18.620 --> 00:15:21.260
Y dices, vale, ¿que lo
copio a otra instancia?

00:15:21.400 --> 00:15:26.280
Y dices, bueno, pues tengo dos instancias
con esta fila ya registrada y la tercera que,

00:15:26.360 --> 00:15:28.200
dices, pues me da igual, lo he hecho.

00:15:28.240 --> 00:15:30.620
Es como una comunicación interna.

00:15:30.960 --> 00:15:36.400
Para el LRDB cluster permite ser
single primary o multi primary.

00:15:36.700 --> 00:15:41.920
Yo puedo escribir solo en una, por lo
tanto, esas otras dos que están replicando están

00:15:41.920 --> 00:15:45.180
esperando. Están en plan
pasivo, pero agresivo.

00:15:45.340 --> 00:15:47.460
Es decir, tienen los
datos, los últimos datos.

00:15:47.500 --> 00:15:54.180
Están disponibles para un read only, para
reporting o incluso para servidor backup, réplicas,

00:15:54.180 --> 00:15:59.420
etc. Y todo el failover, lo que
quisiéramos hacer en un momento dado, es todo online.

00:15:59.800 --> 00:16:05.280
No hay nada que desenchufar ni
desactivar, aparte que sea automático.

00:16:06.290 --> 00:16:10.770
Y luego dices, no, no, pero eso, por
ejemplo, para cualquier cosa tipo Drupal, Moodle,

00:16:10.810 --> 00:16:16.730
WordPress y demás, tú puedes montar un
InnoDB Cluster porque dentro de eso va como un

00:16:16.730 --> 00:16:18.630
mini proxy que se llama MySQL Router.

00:16:18.670 --> 00:16:25.370
Que la gente antes usaba o bueno sigue
usando el sql proxy o ancha proxy Que dice eso

00:16:25.370 --> 00:16:30.550
está muy bien con estos dos tipos maría y
como sql propio también con galera pero el

00:16:30.550 --> 00:16:36.050
grupo application dentro de y no debe
cluster es como lo resuelve todo y no hay bloqueos

00:16:36.050 --> 00:16:41.290
globales estos para que los que no lo conocen
ese bloqueo es que significa que si yo

00:16:41.290 --> 00:16:45.230
actualiza una tabla es bueno pues que que
voy a actualizar muchas tablas, tengo un batch

00:16:45.270 --> 00:16:50.490
y lo lanzo. Va la primaria y la primaria
dice, espera, yo soy multi -primer, yo puedo

00:16:50.490 --> 00:16:52.710
hacer bloqueos ahí a todas las instancias.

00:16:52.750 --> 00:16:58.010
Y dices, pues espérate, espérate, que voy
a congelar todo hasta que sepa que todo ha

00:16:58.010 --> 00:17:02.790
llegado a todos sitios. Pues eso no ocurre
en nubecluster, por lo tanto, es más como

00:17:02.790 --> 00:17:10.350
el MySQL de tala. Y dices, bueno,
yo puedo meter tablas gordas, pero

00:17:10.350 --> 00:17:16.310
es transaccional. Es el típico de decir
pues todo eso es lo que decía no sé tipo web

00:17:16.310 --> 00:17:21.030
tipo truco al moodle wordpress etcétera
todo eso pues lo puedo convertir en un heno de

00:17:21.070 --> 00:17:28.650
clúster con lo voy a decir con la boca
pequeño pero con matices porque ya

00:17:28.650 --> 00:17:35.310
es que siempre hay algo dice qué pasa que
en la página web o la esa web solución web

00:17:35.310 --> 00:17:42.330
antes usaba las tablas maya y sam
no y maya es antiguo y eso es lo que

00:17:42.330 --> 00:17:48.510
siguen usando algunos y se puede seguir
usando no pero es por legacy maya y sam era un

00:17:48.510 --> 00:17:56.110
tipo de una tabla que se escribía Muy
poquísimas pocas veces pero se leía mucho cuando

00:17:56.110 --> 00:18:00.870
se escribió se escribía al final de la
tabla normalmente eran inses no eran updates entonces

00:18:00.910 --> 00:18:06.110
eso por eso más se tiene el éxito que tiene,
pero luego dices, ya, pero ese barco ya

00:18:06.110 --> 00:18:11.010
zarpó. Nosotros queremos hacer updates,
entonces para eso las tablas y Node .js, transaccionales,

00:18:11.050 --> 00:18:15.939
roadblocking, etcétera. Y dices, bien, en
un entorno HA, pues eso es lo que me interesa.

00:18:16.530 --> 00:18:21.830
Me tiro de la Node .js Cluster con la
configuración que sea, tenga el router o el proxy

00:18:21.830 --> 00:18:26.730
o lo que sea delante, pero al fin y al cabo,
hay automatismos ahí que yo no me tengo

00:18:26.730 --> 00:18:32.710
que levantar a las 3 de la mañana a parar
un instancio o a hacer switch o a hacer failover.

00:18:32.710 --> 00:18:35.270
Vale, y tú le puedes meter
ahí tantos nodos como quieras.

00:18:35.310 --> 00:18:36.699
Esto es un cluster que...

00:18:37.670 --> 00:18:41.070
Hasta nueve, no, no, no, no, no, no, no,
no, no, no, no, no, no, no, no, no, no.

00:18:41.110 --> 00:18:47.410
Bueno, estamos poniendo a ver
que hasta dónde podemos ir, ¿no?

00:18:47.510 --> 00:18:49.810
Pero tranquilamente, ¿no?

00:18:49.890 --> 00:18:52.650
Hasta dónde podemos ir nueve
nodos, nueve nodos y a ese, ¿eh?

00:18:52.690 --> 00:18:56.700
Es decir pero no se suele
hacer, no se suele hacer.

00:18:56.920 --> 00:19:03.100
O sea, yo he visto entornos con cinco y
dices, vale, bueno, pero normalmente son tres

00:19:03.100 --> 00:19:10.320
o cinco y éstas no pasa nada que pase que
normalmente en el mundo más sql no es uno

00:19:10.320 --> 00:19:16.420
grande que lo hace todo se puede Hacer
puedes meter varias cosas ahí dentro pero lo típico

00:19:16.420 --> 00:19:24.060
es decir a ver más sql señor más sql que
quieres pues yo quiero 8 gigas o 64 gigas

00:19:24.060 --> 00:19:27.820
de Buffer Pool no necesito más.

00:19:28.180 --> 00:19:30.720
Y dices, oye, va, pero
¿cómo que no necesitas más?

00:19:30.760 --> 00:19:34.620
Venga, va, pónmelo en tres máquinas, pero
puedo aprovechar esas otras tres máquinas a

00:19:34.660 --> 00:19:39.740
hacer otro clúster. Bueno imagínate que
tengo un primario y demás con dos secundarios,

00:19:39.840 --> 00:19:43.900
pues donde están los otros dos secundarios
yo puedo meter otro clúster y decir, pues

00:19:43.940 --> 00:19:48.880
por otros puertos y que se comunique, pues
tengo dos clústeres tirando de tres nodos.

00:19:49.260 --> 00:19:54.360
No es lo mejor, porque al fin y al cabo
serás tan fuerte como tu punto más débil, pero

00:19:54.360 --> 00:19:57.200
dices oye, pues, ¿qué no quiero hacer?

00:19:57.460 --> 00:20:01.940
Pero de ahí el tema cloud, los
entornos cloud, los compute, los

00:20:03.540 --> 00:20:09.360
VMs, se puede montar rápidamente con un
MySQL y normalmente se hace muchos, muchos clústercitos,

00:20:09.360 --> 00:20:10.920
¿no? Por ahí, en vez de hacer un...

00:20:10.960 --> 00:20:15.040
Vale, y una cosita también
así, plan curiosidad, ¿no?

00:20:15.140 --> 00:20:19.160
A ver, porque por poner un poquito en
escena, cuando estamos hablando de clúster, por

00:20:19.200 --> 00:20:26.440
ejemplo, en Oracle, pues ya empiezas
instalando un software de grid con una SM con

00:20:26.440 --> 00:20:32.240
un almacenamiento compartido, con unos
discos que tú le vas provisionando discos y todo

00:20:32.240 --> 00:20:34.620
el almacenamiento es común

00:20:35.660 --> 00:20:40.500
¿En MySQL esto hay alguna
forma de hacer algo así?

00:20:40.620 --> 00:20:47.060
¿O tienes que delegar en software de
terceros para tener almacenamiento en clúster también?

00:20:49.180 --> 00:20:52.069
No es almacenamiento en
clúster, no existe la opción

00:20:52.940 --> 00:20:58.600
En InnoDB Cluster Es lo que decía al
principio de réplica Por eso hablé de ello El réplica

00:20:58.600 --> 00:21:03.880
es lo mismo Realmente estoy mandando los
binlogs a los otros dos O X servidores Pero

00:21:03.880 --> 00:21:09.000
que además con la comunicación adicional
La capa de esto de group replication Que comento

00:21:09.000 --> 00:21:12.889
interno Que dice aplíquete eso y si
no me dices nada te pego Y te echo

00:21:14.680 --> 00:21:20.160
Pero no hay un Yo escribo en mi disco Y la
otra instancia escribe en el disco que tenga

00:21:20.160 --> 00:21:24.700
él y no tenemos nada que ver con esos
discos uno con el otro, es totalmente independiente

00:21:24.740 --> 00:21:28.520
y no es necesario. Bueno,
arquitecturas distintas ¿no?

00:21:30.280 --> 00:21:35.400
Eso es, eso es, por ejemplo para comparar
los que con el mundo no SQL, el tema

00:21:37.080 --> 00:21:41.440
CockroachDB el Couchbase y todo eso, al
fin y al cabo lo que ellos hacen pues es un poco

00:21:41.480 --> 00:21:48.240
del estilo donde van mandando, o sea donde
la tabla está como compartida entre varios

00:21:48.240 --> 00:21:50.340
nodos y ahí pueden tener
muchos muchos nodos.

00:21:50.380 --> 00:21:54.820
Entonces, claro, la tabla por detrás es el
que se va encargando de copiar los bloques

00:21:54.860 --> 00:21:56.300
allí, allá, tal, no sé qué.

00:21:56.340 --> 00:22:00.160
O sea, ya ni siquiera es la instancia,
pero es un poco más bajo nivel.

00:22:00.200 --> 00:22:06.740
Vale, entonces, resumiendo, para alta
concurrencia de usuarios haciendo manipulaciones,

00:22:06.740 --> 00:22:10.520
haciendo transacciones
concurrentes, ¿cuál sería la opción?

00:22:10.680 --> 00:22:16.060
Sí breve, tu apuesta favorita
de configuración de SQL.

00:22:16.340 --> 00:22:18.720
Vale ¿Grandes volúmenes de datos?

00:22:25.340 --> 00:22:33.520
Pues se puede llegar hasta terabytes y
bastantes terabytes con más SQL Cluster, pero

00:22:33.590 --> 00:22:41.070
se tiene que mirar, o sea, no es un
despliegue así como normal y luego dices,

00:22:41.110 --> 00:22:45.810
vale, pues porque si tengo que hacer
cargas batch cada dos por tres, todo eso tiene que

00:22:45.850 --> 00:22:52.390
volar por la red dentro de este cluster
y por lo tanto tengamos cuidado.

00:22:52.390 --> 00:22:59.530
Tengamos cuidado, el InnoDB Cluster
puede ser enorme, pero es más para

00:22:59.530 --> 00:23:02.490
transaccional, no es para data warehouse.

00:23:04.130 --> 00:23:13.210
Si te gusta mucho más SQL y
quieres ir al mundo de inteligencia

00:23:13.210 --> 00:23:18.950
artificial, tipo vector database y todo
eso, cosas así, hoy día la apuesta que tiene

00:23:18.950 --> 00:23:23.290
Oracle es lo de HitWave. De eso, Heatwave,
tenemos que hablar eso me lo tienes que contar

00:23:23.330 --> 00:23:31.100
pero... Otro día no,
No, es broma realmente

00:23:31.100 --> 00:23:38.440
Heatwave con calma Heatwave tomándote
un café ¿cómo contarías Heatwave

00:23:38.440 --> 00:23:45.810
tomándote un café? Pues es decir conozco

00:23:45.810 --> 00:23:52.910
más SQL para empezar dices, pues ¿sabes
esos cientos de terabytes que tengo allí que

00:23:52.910 --> 00:24:00.100
quiero Machacar la saco y tener
buena respuesta o el app dentro de y

00:24:00.100 --> 00:24:07.420
luego incluso usarlo con más sql pues hit
wave te hace eso dices espera pero pero hablamos

00:24:07.420 --> 00:24:14.640
de terabytes y terabytes hablamos primero
que está parados y si solamente lo hace y

00:24:15.820 --> 00:24:21.200
bueno pero originalmente
para oci y Y luego AWS, ¿no?

00:24:21.200 --> 00:24:22.740
Sí, claro, bueno cloud, entiendo.

00:24:22.780 --> 00:24:24.260
Cloud, o sea, en torno...

00:24:24.260 --> 00:24:25.871
Se puede desplegar, usar ahí.

00:24:26.360 --> 00:24:30.840
Cloud. Nada más que cloud, sí dime,
¿es que nos hicieron una charla?

00:24:31.320 --> 00:24:37.060
Nos dieron una charla sobre FeedWave y
tal, como que como que también están apostando

00:24:37.060 --> 00:24:41.180
mucho, es decir, aquí aunque estemos hablando
de Oracle versus MySQL, todo pertenece

00:24:41.220 --> 00:24:48.120
al mismo fabricante y no se van a pelear,
es decir, van a hacer siempre los productos

00:24:48.120 --> 00:24:55.380
que sean, entre comillas, No
compatibles, pero sí que se

00:24:55.380 --> 00:24:56.920
compensen unos con otros.

00:24:57.140 --> 00:25:01.900
Es decir, que ciertas soluciones se cubran
desde MySQL y que ciertas otras soluciones

00:25:01.900 --> 00:25:05.900
se cubran desde Standard
Edition o desde Oracle.

00:25:05.900 --> 00:25:10.120
¿No? Entiendo, desde Oracle,
desde las otras Oracle.

00:25:10.400 --> 00:25:15.620
Pero sí tenía muy buena pinta,
precisamente es lo que te dices, es decir, grandes volúmenes

00:25:15.620 --> 00:25:22.740
de datos, subirlos a la nube y con
MySQL Hardware, pues hacer OLAP y hacer

00:25:22.740 --> 00:25:28.420
procesamiento analítico y sacar ahí, es
decir, como que tenía ya como unos cuadros de

00:25:28.420 --> 00:25:30.680
mandos ya preparados y como...

00:25:30.680 --> 00:25:37.680
¡Tenía buena pinta! Sí sí

00:25:37.680 --> 00:25:43.960
y es fácil de usar es que es al fin y al
cabo es como un motor secundario o sea un storage

00:25:43.960 --> 00:25:49.120
engine secundario lo que te decía antes de
esto de my eyes a mí las tablas tipo y no

00:25:49.120 --> 00:25:55.220
debe pues dentro de un del mundo hit wave
lo que se hace la tabla dice vale tú eres una

00:25:55.220 --> 00:26:02.380
tabla y no debe bien vale puesto el motor
secundario es hit wave el rapid y dice a eso

00:26:02.380 --> 00:26:08.840
lo que hace que es, subes las columnas de
esa tabla enorme a HeatWave, entonces se mete

00:26:08.840 --> 00:26:14.160
memoria dentro de esos servidores que se
está usando por detrás y por eso va muy rápido

00:26:14.160 --> 00:26:21.620
y luego tiene otros algoritmos detrás o
sea que, por eso está muy bien porque usas,

00:26:21.620 --> 00:26:26.440
o sea, puedes usar la memoria que precisas,
no tienes que subir toda la tabla enorme

00:26:26.440 --> 00:26:32.840
solo porque dices, voy a sacar estas dos
columnas siempre pero para tipo hoy o la pibe

00:26:32.840 --> 00:26:38.260
y todo eso y de hecho las soluciones
vector database y todo eso para más sql va por hit

00:26:38.260 --> 00:26:44.740
white muy bien muy bien por recordar y por
ver el contexto estamos grabando esto en directo

00:26:44.740 --> 00:26:51.060
con audiencia en el en el servidor de
discos de café database lo estamos grabando y después

00:26:51.060 --> 00:26:56.860
de grabarlo lo subiremos a la spotify a
apple podcast eso quiere decir si lo estás escuchando

00:26:56.860 --> 00:27:02.320
en spotify o en Apple Podcast, no puedes
participar en directo, pero si la audiencia

00:27:02.320 --> 00:27:05.940
que tenemos Si tiene alguna pregunta, te
quiere hacer alguna pregunta aquí, pues se puede

00:27:05.980 --> 00:27:10.960
unir nos puede escribir en el chat o puede
levantar la mano y podemos subirla a la audiencia

00:27:11.000 --> 00:27:16.980
y que hable con nosotros y que si te
quieren preguntar algo, ya que de MySQL me rindo

00:27:16.980 --> 00:27:22.340
a tus pies, a tu conocimiento pues estamos
abiertos a que la audiencia pueda participar,

00:27:22.680 --> 00:27:25.760
si quieren ¿Qué tal? ¿Cómo lo ves?

00:27:26.020 --> 00:27:29.464
¿Quién va ganando? En tema
clúster, ¿Oracle o MySQL por ahora?

00:27:30.740 --> 00:27:33.018
Espera, yo no he acabado Yo no he acabado

00:27:33.600 --> 00:27:39.660
Espera, yo no he acabado Porque claro,
hemos hablado de la parte Réplica, de hecho, perdóname

00:27:39.660 --> 00:27:46.840
Pero réplica es la feature De MySQL más
usado O sea, todo el mundo que usa MySQL y

00:27:46.840 --> 00:27:52.420
dice de repente Uf, esto se está volviendo
un poco grande Réplica Booking tiene, no sé

00:27:52.420 --> 00:27:59.340
si eran 5 .000 servidores MySQL replicados
entre sí inditex tienen anillos de 300 o tenían

00:27:59.340 --> 00:28:04.680
anillos de 300 y pico de réplicas y digo
más sql pero también vale para maría y de marjorie

00:28:04.680 --> 00:28:11.120
que usa el código pero lo que es la
réplica es que funciona y va bien y hay distintas

00:28:11.120 --> 00:28:17.580
soluciones lo cual vale bien réplica y no
más y no debe cluster que como eso está muy

00:28:17.580 --> 00:28:24.580
bien para soluciones automatizados con
router que pues hace cosas online a mí

00:28:24.580 --> 00:28:27.420
me me gusta, yo lo
despliego y demás, disfruto.

00:28:28.640 --> 00:28:32.320
Y HeatWave, lo hemos comentado, pero eso
es OCI, eso es en cloud, eso es para OLAV.

00:28:32.360 --> 00:28:39.480
Y dices, no es tanto HA, Pero
es HA la nube ya te está dando

00:28:39.480 --> 00:28:45.440
ahí, digamos, ya estás protegido, ya te
está dando redundancia física y te está dando,

00:28:45.540 --> 00:28:50.460
bueno, esa, esa, claro. Y
luego está el bicho raro.

00:28:50.760 --> 00:28:54.660
El bicho raro de MySQL es el NDB, ¿vale?

00:28:54.740 --> 00:29:00.880
MySQL Cluster y me acuerdo mucho de gente
que dice, oye, yo quiero MySQL Cluster y la

00:29:00.880 --> 00:29:05.340
cantidad de veces que le decían, no, no lo
quieres y dicen, espérate, espérate pero tú

00:29:05.380 --> 00:29:09.500
no me estás haciendo de pre -sales no
tienes que decir que sí, bueno, todo y lo que sea

00:29:09.540 --> 00:29:11.260
y dicen, ¿qué no? ¿qué no lo quieres?

00:29:11.300 --> 00:29:16.020
Y me dicen, pero si yo quiero un clúster
yo quiero HA y dicen, vale, espera MySQL Cluster

00:29:16.060 --> 00:29:21.940
es el bicho raro donde nos apartamos todo
cogemos un ojo grande y un lápiz y empezamos

00:29:21.940 --> 00:29:29.100
a dibujar ¿por qué? Porque es Es especial,
es una tabla que está partida entre n

00:29:29.100 --> 00:29:36.840
nodos, pues hasta la versión
8, no, 7 y 2 eran 250

00:29:36.840 --> 00:29:44.100
nodos en un clúster y a
partir, no, perdón, 255

00:29:44.100 --> 00:29:49.420
nodos en un clúster que un
nodo ya los abstraemos, ¿no?

00:29:49.420 --> 00:29:52.160
O sea, la parte de parseo es MySQL, ¿no?

00:29:52.200 --> 00:29:58.920
La instancia es MySQLD cuando montamos la
instancia, pues eso es donde se parsea el código,

00:29:59.060 --> 00:30:01.140
¿no? Pero los datos
estaban en otro servidor.

00:30:01.180 --> 00:30:04.236
La parte de manejar las tablas
estaba en otro servidor.

00:30:04.380 --> 00:30:07.160
Y luego tengo mi manager
que está en otro servidor.

00:30:07.200 --> 00:30:08.420
Y dice, ay madre, ay madre.

00:30:08.460 --> 00:30:09.960
O sea, esto Era como un poco raro, ¿no?

00:30:10.000 --> 00:30:15.940
Y dices, la tabla realmente, una tabla
está partida entre dos nodos, cinco nodos, o sea,

00:30:16.020 --> 00:30:21.820
un pares de nodos y tal. Y puede estar hasta
los datos, los datos podían estar hasta

00:30:21.820 --> 00:30:24.580
48, creo que era, y ahora ya se ha ido...

00:30:24.580 --> 00:30:26.320
¿Te refieres partida? ¿Qué te refieres?

00:30:26.360 --> 00:30:33.540
¿Particionamiento? Sí, un table partition
entre nodos, pero que está en memoria.

00:30:34.280 --> 00:30:38.620
Madre de mi vida no sé
si alegrarme o asustarme.

00:30:42.160 --> 00:30:47.320
Imagínate que tienes una tabla que desde,
por ejemplo, los SQL nodes, que son los MySQL,

00:30:47.460 --> 00:30:54.760
tú te conectas a 200 MySQL y
dices, yo lanzo y me conecto y

00:30:54.760 --> 00:30:59.960
voy a leer el dato. Pero la mitad de mi
centro de datos se ha pirado y tenía 8 servidores

00:30:59.960 --> 00:31:05.740
de datos. Y dices, es que se hace un
sharding automático interno, se mantiene dos copias.

00:31:05.740 --> 00:31:12.820
Es como un to face commit detrás
vale 2 pc donde escribo un update y

00:31:12.820 --> 00:31:18.840
son dos estilos adultos como alguien dice
por ahí dice vale si tengo mi jardín por ahí

00:31:18.840 --> 00:31:25.740
pero esto es como alto concurrencia porque
porque dices en cada data note están los datos

00:31:25.740 --> 00:31:29.760
en memoria primero y
luego se copia a disco

00:31:31.570 --> 00:31:37.690
Cuando se copia disco eso es como un
checkpoint pero yo los procesos en cada data note

00:31:37.690 --> 00:31:44.110
lejos del sql vale eso se puede asignar a
un core o un grupo de coreas de que es muy

00:31:44.110 --> 00:31:50.370
es un trabajo muy fino para optimizarlo el
mundo ndv vale en el de bens a que es decir

00:31:50.370 --> 00:31:56.890
más sql y cluster la n de bernat nació
para el mundo telco pero claro y ahora me viene

00:31:56.890 --> 00:32:03.190
me vas a preguntar y para qué base de
datos o qué uso tiene eso pues ni almacenamiento

00:32:03.190 --> 00:32:10.190
porque es memoria entonces el ram es lo
que hay dependerá de tu servidor y dices entonces

00:32:10.190 --> 00:32:17.110
es alta concurrencia y transacciones vamos
la más pequeña cuanto más pequeña es mejor

00:32:17.110 --> 00:32:24.720
dividir y conquistar nada de
paralelo lo digamos para el cual

00:32:24.720 --> 00:32:31.720
no consultar lectura paralela y no son le

00:32:31.720 --> 00:32:37.560
matas eso le matas porque estás diciendo
si estás bailando entre los datos y le matas

00:32:37.560 --> 00:32:40.640
o si no es tipo telco tipo

00:32:42.900 --> 00:32:49.860
Hlr sdp a todo esto del mundo dentro salvo
entre salvo por ejemplo una solución que era

00:32:49.860 --> 00:32:56.920
bueno era streaming de vídeos
en bytes de 14K y metes

00:32:56.920 --> 00:33:02.180
ahí y va a saco, porque siempre está
disponible ese sí que es 5 nueves o incluso 6 nueves,

00:33:02.220 --> 00:33:08.840
porque tiene réplica geográfica, pero a
saco los telcos grandes telcos como Ericsson

00:33:08.840 --> 00:33:17.610
como Nokia y demás, usaban esto para
muchas soluciones totalmente escondido

00:33:17.610 --> 00:33:24.660
nadie sabía que se usaba Y ha
funcionado muy bien cuando lo hacías

00:33:24.660 --> 00:33:29.140
funcionar, porque eso
sí que es otro mundo.

00:33:29.340 --> 00:33:36.060
Es muy particular por lo tanto, por eso yo
decía, importa el byte, el tamaño de la tabla,

00:33:36.100 --> 00:33:41.120
de la definición de las columnas que tengas
en cada tabla que vas a subir a memoria,

00:33:41.180 --> 00:33:47.040
importa, claro. Claro, porque si tú tienes
100 millones de filas en una tabla que lo

00:33:47.040 --> 00:33:51.440
estás guardando en memoria y a alguien se
le ocurre hacer un full scan, ya no es la memoria

00:33:51.480 --> 00:33:54.780
otra vez, dices, ostras, pues si
estoy en un char o un bar char.

00:33:54.820 --> 00:34:01.860
El char este de 3 no podría ser un integer
de 1, porque al fin y al cabo el sistema

00:34:01.860 --> 00:34:03.471
binario me funciona muy bien.

00:34:04.620 --> 00:34:10.820
Si es un sí, no, yo voy a esa parte de la
aplicación y guardo un 1 y un 0, porque te

00:34:10.820 --> 00:34:14.520
vas a ahorrar esos bytes multiplicados
por la cantidad de files que tienes.

00:34:14.560 --> 00:34:20.520
Y así y esos ejercicios los he hecho con
clientes para Decir bueno, en la 23C tenemos

00:34:20.520 --> 00:34:23.160
el nuevo tipo Bolean, para columnas.

00:34:25.120 --> 00:34:28.340
Novedades, novedades
que vendrán en la 23C.

00:34:28.960 --> 00:34:36.090
Bueno, me gustaría saber qué opinión
tienes tú de hacia dónde se dirige

00:34:36.090 --> 00:34:43.450
MySQL. Porque yo, mi opinión, desde mi
ignorancia, es que MySQL sobre todo se

00:34:43.450 --> 00:34:50.450
utiliza en aplicaciones web, sobre
todo en en hostings, digamos, no

00:34:50.480 --> 00:34:56.480
quiero decir pequeños, pero sí
aplicaciones diversas como muy abiertas, de código abierto,

00:34:56.500 --> 00:35:01.440
todo el mundo implementa, digamos, no
implementa una tecnología propietaria como Oracle,

00:35:01.560 --> 00:35:06.280
digamos, implementa MariaDB, MySQL, es como
mucho más abierto, más estándar, te vale

00:35:06.280 --> 00:35:09.780
para implantarlo en cualquier sitio.

00:35:10.650 --> 00:35:17.690
Y si me parece que, aparte de esto en
servidores y quien puede utilizar MySQL, por supuesto,

00:35:17.730 --> 00:35:22.990
en on -premise, si me parece que quizá la
apuesta que está haciendo Oracle más fuerte

00:35:22.990 --> 00:35:30.030
es subir MySQL a la nube, no solamente
como una de las datos que se pueda

00:35:30.030 --> 00:35:34.610
poner en servidores web,
sino como lo que dices tú.

00:35:34.610 --> 00:35:40.490
Es decir, cierto procesamiento analítico,
cierto volumen, ciertas cargas de datos o análisis

00:35:40.490 --> 00:35:42.070
de datos de grandes volúmenes.

00:35:42.110 --> 00:35:47.510
Es decir, no lo hagamos con Oracle quizá,
que a lo mejor en coste de licencias y en almacenamiento

00:35:47.550 --> 00:35:53.610
y en espacio y en volúmenes van a ser
soluciones muy caras y los competidores quizá pueden

00:35:53.610 --> 00:35:56.650
proponer una solución más asequible.

00:35:56.650 --> 00:36:01.850
Y sí, digamos, cubrir ese hueco Y decir,
vale, mira, pues tú puedes Irte Seguramente

00:36:01.850 --> 00:36:03.810
a la nube Para todos aquellos

00:36:05.270 --> 00:36:09.770
Todos aquellos datos que quieras
analizar Digamos, en Gran masa

00:36:10.850 --> 00:36:15.930
Y a la vez, pues Bueno, no sé, estaba viendo,
por ejemplo, en OCI Estaba mirando los

00:36:15.930 --> 00:36:22.490
tutoriales y tal Tienen el tutorial de
desplegarte Pues eso, un site De Wordpress, una

00:36:22.490 --> 00:36:28.490
tienda online Es decir, cosas muy, muy
versátiles Como muy abiertas Muy abiertas en el

00:36:28.490 --> 00:36:33.210
sentido de que cualquier aplicación
puede valer, se puede desplegar.

00:36:33.710 --> 00:36:35.970
¿Y hacia dónde crees que apuestan?

00:36:36.090 --> 00:36:38.970
¿Voy en lo cierto o tengo prejuicios?

00:36:39.930 --> 00:36:45.010
Yo diría que sí, no, no, no, o sea, yo
diría que sí, o sea, el mundo cloud, o sea, MySQL

00:36:45.010 --> 00:36:49.810
ha sido database de cloud desde que el mundo
es mundo, como el mundo cloud es cloud,

00:36:49.950 --> 00:36:56.990
¿no? Hasta dentro de los manuales de
MySQL había, pues, cómo usar el S3,

00:36:57.170 --> 00:37:03.130
¿no? Para guardar las réplicas y hacer
backups de las herramientas enterprise a S3.

00:37:03.130 --> 00:37:06.690
O sea que en ese sentido
totalmente diría que

00:37:08.050 --> 00:37:12.550
Imagínate que tienes un oracle pues este
tipo legacy, dices no sé qué hace con él, no

00:37:12.590 --> 00:37:19.730
lo quiero migrar Es algo sencillo
no lleva mucha complicación igual

00:37:19.730 --> 00:37:25.830
el dato lo puedo meter en un MySQL y lo
aparto o sea lo segmento o al revés, o tengo

00:37:25.830 --> 00:37:31.430
MySQL por ahí y digo mira pues los voy
troceando poco a poco, los voy sacando uno de

00:37:31.430 --> 00:37:36.510
aquí, otro de allá, lo llevo al cloud, este
sí, este no, o sea hay flexibilidad y es

00:37:36.510 --> 00:37:41.930
fácil una migración de datos más SQL de un
Maria más SQL, por ejemplo o viceversa, es

00:37:41.930 --> 00:37:48.370
muy sencillo en ese sentido es fácil
instalar lo puedo llevar como sea y tengo

00:37:49.530 --> 00:37:53.910
opciones si tengo que tratar datos
antiguos y tal, no es difícil no es difícil, no hay

00:37:53.950 --> 00:38:00.470
que ser maravilla para decir, mira lo
puedo hacer así yo, o sea que en ese sentido pero

00:38:00.470 --> 00:38:07.750
vamos, o sea es Es un string de conexión,
es un proceso, a fin y al cabo, en un cloud,

00:38:07.870 --> 00:38:10.930
hasta funciona en Docker y
en Kubernetes y todo eso.

00:38:10.990 --> 00:38:14.390
Muy bien y esa es otra charla, ¿no?

00:38:14.390 --> 00:38:16.779
Claro, esa es otra, la
que te iba a hablar.

00:38:16.890 --> 00:38:23.090
Es decir, otra cosa que veo en MySQL es la
versatilidad de desplegarlo en Kubernetes,

00:38:23.230 --> 00:38:28.710
tener rápidamente un motor pequeño,
levantarlo en cualquier sitio y funcionar.

00:38:28.710 --> 00:38:35.770
Pero como estamos hablando de clusters,
Keith, si te parece, aquí puedes tomarte tu

00:38:35.770 --> 00:38:42.450
tiempo en responder. Vamos a intentar ir
subiendo el nivel de alta disponibilidad hasta

00:38:42.450 --> 00:38:49.890
ver hasta dónde podemos llegar en MySQL
para montar una Máxima disponibilidad

00:38:49.890 --> 00:38:51.690
yo te cuento el escenario.

00:38:51.970 --> 00:38:59.110
Para mí, la configuración de máxima
disponibilidad es, empezando con

00:38:59.110 --> 00:39:06.160
un rack que tengamos replicado con un
Data Guard en otro rack, por supuesto, y

00:39:06.250 --> 00:39:10.530
un tercer nivel que pueda ser para
Disaster Recovery que sea otro rack.

00:39:10.530 --> 00:39:18.290
Es decir, esa cascada de tres
entornos sincronizados físicos, porque

00:39:18.290 --> 00:39:22.270
a mí me da mucha tranquilidad que la
replicación sea física, la replicación lógica, todos

00:39:22.310 --> 00:39:29.840
sabemos que tiene ahí sus
flequillos y es un poco dura cuando

00:39:29.840 --> 00:39:34.320
falla. Me gusta la replicación física.

00:39:34.560 --> 00:39:38.180
Que se cae un nodo, el rack lo aguanta.

00:39:38.280 --> 00:39:42.700
Que se cae un disco,
tenemos replicada cabina.

00:39:42.780 --> 00:39:48.900
Que se cae un clúster, tenemos
otro clúster en Data Guard.

00:39:48.900 --> 00:39:55.880
Y necesitamos parchear vamos a ir buscando
en MySQL cuál sería esa subida a la super

00:39:55.880 --> 00:40:00.500
mega máxima alta disponibilidad
que podríamos hacer con MySQL.

00:40:01.380 --> 00:40:08.000
Tranquilo, ¿eh? O sea, aquí piénsatelo en
plan, ¿cuál sería tu fórmula de, mira, para

00:40:08.000 --> 00:40:12.220
estar super, super, super mega
máximo cubiertos, lo haría así?

00:40:12.220 --> 00:40:19.390
Pues Es una cosa que
estoy en ello ahora llevo

00:40:19.390 --> 00:40:26.570
un tiempo así haciendo lo que decía de
más y con el InnoDB Cluster, que por eso

00:40:26.570 --> 00:40:32.310
también matices de decir mira, sabiendo que
no es réplica física sino es a través de

00:40:32.310 --> 00:40:40.050
los logs Tenemos el InnoDB Cluster
un grupo de tres un cluster de tres y

00:40:40.560 --> 00:40:46.440
imagínate que dices dices, pues yo quiero
también un tipo de atagar o un clúster en pasivo,

00:40:46.540 --> 00:40:50.000
pues esto es otro, y no debe
clúster, en otros sites, en otras

00:40:50.920 --> 00:40:54.240
máquinas, y eso lo hago un clúster set.

00:40:54.520 --> 00:41:00.300
Eso es como una nomenclatura que dices, en
mi clúster set tengo dos o tres o los clúster

00:41:00.300 --> 00:41:02.360
set que yo quiera. Es decir,

00:41:03.450 --> 00:41:07.830
tres clústers, de tres nodos cada
uno, replicando de uno principal,

00:41:09.270 --> 00:41:15.090
Y estoy escribiendo a los routers, que que
son como los APIs, los endpoints, los interfaces,

00:41:15.410 --> 00:41:21.930
los routers que yo pueda tener donde sea y
me da igual en qué clúster está activo, cuál

00:41:21.930 --> 00:41:24.450
es el primario y cuál
es el secundario, etc.

00:41:24.730 --> 00:41:26.674
O sea, es como una capa por debajo.

00:41:27.220 --> 00:41:34.580
Eso es como yo diría que podemos tener un
clúster en cada esquina del globo con mis routers

00:41:34.580 --> 00:41:41.260
repartidos y puedo activar los filtros de
read -write a nivel de clúster, la última versión

00:41:41.260 --> 00:41:48.260
de 8 .3, Y primarios, secundarios,
puedo hacerlos bailar, puedo esconder

00:41:48.260 --> 00:41:52.380
instancias a través del router para decir,
mira, este lo vamos a parar un momento para

00:41:52.420 --> 00:41:57.700
parchear y puedo hacer un switchover
rápidamente en el primer clúster y dice, no pasa

00:41:57.700 --> 00:42:04.820
nada. Sí

00:42:04.820 --> 00:42:10.660
pero flexibilidad dice claro se está
pensado para eso se pensaba mundo cloud porque no

00:42:10.660 --> 00:42:15.400
nos engañemos el cloud está pero también a
veces no está y dices oye refresco la página

00:42:15.440 --> 00:42:21.920
a veces no va es la solución esos de tab
mi conexión esté constantemente siempre arriba

00:42:21.920 --> 00:42:27.200
y demás eso no lo lo hace más que con el
router, no lo puede hacer, eso necesitas un

00:42:27.200 --> 00:42:35.100
net scale o un punto para ahora,
estoy siendo honesto, porque

00:42:35.100 --> 00:42:42.040
al fin y al cabo es un router, es un proxy,
es un reenvío, es el cliente al fin y al

00:42:42.040 --> 00:42:49.070
cabo, pero claro, realmente lo que voy a
hacer es entrar y salir, más escueto, la

00:42:49.070 --> 00:42:55.930
convivencia, la sesión es mucho más ágil
en ese sentido, Pues bueno, eso no lo tienes

00:42:55.930 --> 00:43:02.310
con MySQL Router, pero hay soluciones ya
de terceros que nos tendríamos que ir.

00:43:02.430 --> 00:43:09.670
Vale, ¿cuánto dependo si tengo
MySQL de todas esas otras soluciones

00:43:09.670 --> 00:43:16.740
de terceros? Por lo menos el
escenario recomendable, ¿cuánto

00:43:16.740 --> 00:43:19.720
dependería de esos terceros?

00:43:19.720 --> 00:43:23.720
Es decir, para nada si no quieres nada.

00:43:24.160 --> 00:43:31.200
Si no quieres nada si tú tienes tu
balanceador de tu F5 o lo que sea y dices, vale, todo

00:43:31.200 --> 00:43:35.620
el mundo lo tendrá, cada organización lo
tendrá, pero no lo necesites si no quieres.

00:43:35.660 --> 00:43:42.840
Es porque el router puede hacer puede ser
ver de balanceador de software más o menos

00:43:42.840 --> 00:43:50.000
para configurar pesos y demás imagínate
que tenemos un cluster De multi prime lee y queremos

00:43:50.000 --> 00:43:53.860
que pues una instancia que sea la
principal pues le ponemos un peso de 60 y los otros

00:43:53.900 --> 00:43:58.940
220 por ciento y dices yo puedo configurar
eso para que oye pues al fin y al cabo se

00:43:58.940 --> 00:44:05.700
va repartiendo un poco la carga y demás o
si Si yo tengo tres nodos o cinco nodos, imaginamos

00:44:05.700 --> 00:44:11.540
que tenemos cinco nodos dentro del
clúster, yo puedo decir estos tres que cojan la prioridad

00:44:11.540 --> 00:44:18.520
de ser candidato a ser primario antes que
los otros dos que están en servidores antiguos

00:44:18.520 --> 00:44:23.140
o estoy pasándolos y todavía los tengo
ahí pero los voy a decomisionar y demás.

00:44:23.840 --> 00:44:27.720
Eso también lo puedes hacer y
es muy fácil, eso es código.

00:44:27.720 --> 00:44:32.120
Muy bien, muy bien recordamos a la
audiencia que si alguien quiere hacer una pregunta,

00:44:32.160 --> 00:44:33.980
que está invitado a subir.

00:44:34.220 --> 00:44:36.164
No morremos ni nos comemos a nadie.

00:44:36.360 --> 00:44:39.120
Somos dos personas muy
majas y muy cordiales.

00:44:39.280 --> 00:44:46.000
Y somos humanos la inteligencia artificial
aún no nos está guionizando los cafés.

00:44:47.420 --> 00:44:50.600
Oye y una cosita ya te
quería preguntar sobre

00:44:51.500 --> 00:44:57.960
MySQL MySQL respecto a Oracle por ejemplo,
porque yo si sigo por ejemplo muy de cerca,

00:44:58.040 --> 00:45:02.707
muchas veces por ejemplo los cambios en el
ANSI por ejemplo las funciones analíticas

00:45:03.300 --> 00:45:09.580
MySQL tardó un poquito en incorporarlas
pero parece que las SQL Windows, las Windows

00:45:09.580 --> 00:45:14.530
Functions ¿cuánto crees tú?

00:45:14.610 --> 00:45:20.190
Ya te voy a hacer una pregunta que a lo
mejor te va a ser no difícil pero controvertida

00:45:20.190 --> 00:45:28.230
¿cuánto crees tú que estamos en
distancia MySQL de Oracle en versiones

00:45:28.230 --> 00:45:33.150
o en años lo que tú
prefieras y segunda pregunta

00:45:35.660 --> 00:45:42.780
MySQL versus Postgres por ejemplo
comparar MySQL con otras bases de datos de

00:45:42.780 --> 00:45:46.380
código abierto y aquí
ya Ya, no es Oracle vs.

00:45:46.400 --> 00:45:49.320
MySQL, sino MySQL respecto a otros.

00:45:49.640 --> 00:45:57.830
¿Cómo ves tú la escena? Primero,

00:45:57.830 --> 00:46:00.590
la pregunta dolorosa de Oracle vs.

00:46:00.770 --> 00:46:01.630
MySQL ¿Qué distancia hay?

00:46:01.670 --> 00:46:08.910
Exacto, distancia...
De hecho, es muy fácil

00:46:09.950 --> 00:46:11.490
jamás, jamás va a llegar.

00:46:12.010 --> 00:46:13.930
O sea, vamos a ver, esto es clarísimo.

00:46:13.970 --> 00:46:15.450
Oracle es el dueño de los dos.

00:46:15.490 --> 00:46:16.934
¿Cómo se llama la empresa?

00:46:17.940 --> 00:46:24.940
No se llama MySQL Por lo tanto, MySQL
va a hacer catch up siempre Yo creo que

00:46:24.940 --> 00:46:26.773
las distancias se están acortando

00:46:30.060 --> 00:46:34.480
Sí, no De hecho, son
diferentes al fin y al cabo.

00:46:34.640 --> 00:46:39.440
El mundo open source no es el negocio de
Oracle, claro Entonces, lo que queremos hacer

00:46:39.440 --> 00:46:45.020
es soltar cosas al open source, poco a poco
pero no queremos cannibalizar el Oracle,

00:46:45.240 --> 00:46:47.640
el buen Oracle Entonces Entonces,

00:46:48.760 --> 00:46:51.593
NoSQL hace muchas cosas y
los puede hacer muy bien.

00:46:52.040 --> 00:46:55.980
El tema JSON y demás es ágil,
pero no llega a ser un NoSQL.

00:46:56.260 --> 00:46:58.440
Al fin y al cabo traduce el SQL.

00:46:58.540 --> 00:47:01.460
Pues mira, si quieres algo más...

00:47:01.460 --> 00:47:04.160
Te voy a echar un capote aquí.

00:47:05.100 --> 00:47:10.980
Acabo de entrar a devengines .com, donde
está el ranking de bases de datos respecto a

00:47:10.980 --> 00:47:15.860
su popularidad. En el
número uno tenemos a Oracle.

00:47:15.860 --> 00:47:18.360
Oracle y en el número 2 MySQL.

00:47:20.920 --> 00:47:26.980
Sí, pero lleva así SQL Server,
la tercera, porque digamos es la

00:47:28.000 --> 00:47:32.960
gran alternativa. Seguimos
con Postgres, posición 4.

00:47:33.720 --> 00:47:37.180
La cuarta es PostSQL y
la quinta tenemos Mongo.

00:47:37.400 --> 00:47:40.580
Y luego a partir de ahí
ya tenemos ya muchas más.

00:47:42.700 --> 00:47:49.880
Pero Oracle y MySQL, digamos como
cubriendo el ranking 1 y 2, el top 1, top

00:47:49.880 --> 00:47:55.590
2 como... Totalmente a ver,
por decirlo una cosa mal, ¿no?

00:47:55.670 --> 00:48:01.130
Aquí los de Postgres a lo mejor pueden
tener una opinión, pero como quizá digamos como

00:48:01.130 --> 00:48:03.770
en solución cara y solución barata...

00:48:05.590 --> 00:48:07.812
Así tal cual, nadie nos va a decir nada.

00:48:08.670 --> 00:48:10.710
Cubriéndolo más caro y
cubriéndolo más barato.

00:48:10.750 --> 00:48:12.270
No, para nada tenemos a...

00:48:12.270 --> 00:48:15.220
Y nunca mejor dicho sí, sí.

00:48:15.220 --> 00:48:20.580
Y de hecho las opciones de pago de MySQL
cuando yo hablaba con la gente que tenía basados

00:48:20.580 --> 00:48:24.620
Oracle, dice, yo quiero migrar a MySQL,
pero no quiero quedarme sin soporte, dice, pues

00:48:24.660 --> 00:48:29.880
5 .000 dice, ¿qué? Dice, 5 .000 por
servidor por año, y dices, pero no te he dicho ni

00:48:29.880 --> 00:48:33.602
tamaños ni nada, y dice, ya, da
igual son 5 .000, dices, ¿en serio?

00:48:34.100 --> 00:48:35.300
¿Soporte es lo que me cuesta?

00:48:35.340 --> 00:48:40.920
Y dices, encima, ya era gratis pero encima
me cobras, y dices, venga pues, dame 3 para

00:48:40.920 --> 00:48:47.760
llevar Y, pero Pero hay opciones de pago,
pero el mundo más SQL, o sea, sí, está tal.

00:48:47.860 --> 00:48:54.900
Pero para hacerla continuar con la otra
pregunta de versus Postgres y demás, Postgres

00:48:54.900 --> 00:49:01.100
lo está haciendo muy bien porque está
captando toda esa gente que está cansada, barra

00:49:01.100 --> 00:49:03.980
harta, barra necesita
algo más de mi oracle.

00:49:04.180 --> 00:49:08.060
Y entonces quiero ir a uno
que no tenga que pelear mucho.

00:49:08.760 --> 00:49:11.300
MySQL está ahí, pero lo
tengo que pelear mucho.

00:49:11.340 --> 00:49:18.060
Entonces quien me soporta muchas cosas
tipo oracle en nuevas datos no oracle pues crees

00:49:18.060 --> 00:49:24.040
es el campeón ya que en ese sentido pues
que se está llevando muchas cosas de esos tienen

00:49:24.040 --> 00:49:30.580
una cosa de él según creo que es un engine
de de pls ql que lo puedes usar o se tiene

00:49:30.580 --> 00:49:37.660
opciones también de ti por ser la de esta
opción es de ver y dices vale pues tengo

00:49:37.660 --> 00:49:42.620
las dos cosas entonces hay mucha gente que
está considerando postgres y está lo están

00:49:42.620 --> 00:49:47.980
haciendo muy bien tanto a nivel open
source a nivel comercial y a nivel cloud o sea que

00:49:47.980 --> 00:49:55.560
yo creo que está ahí lleva años
no sé si fácil 25 años o si se

00:49:55.560 --> 00:50:02.860
quita poquito viendo el
histórico de chart vale casi todo

00:50:02.860 --> 00:50:04.820
más o menos son es bastante homogéneo.

00:50:04.860 --> 00:50:08.860
Además voy a compartirlo en el
grupo por si alguien quiere verlo.

00:50:09.740 --> 00:50:15.520
La sorpresa, digamos, ya hablando
así de otros motores, es Snowflake.

00:50:15.960 --> 00:50:22.740
Snowflake es una base de datos, digamos,
Relativamente reciente aparece en julio de 2016.

00:50:24.240 --> 00:50:28.840
Los motores de base de datos
tienen mucha más antigüedad, ¿vale?

00:50:29.320 --> 00:50:36.020
Quizá Sequoia, Azuré, son nuevos evidentemente,
pero Snowflake aparece nuevo y en el

00:50:36.020 --> 00:50:41.160
2020 pega un petardazo hacia arriba, una
crecida de popularidad y se plantea, digamos,

00:50:41.240 --> 00:50:47.160
en el pelotón de acompañamiento y como dices
tú, es decir, pues ves, va creciendo en

00:50:47.160 --> 00:50:52.500
popularidad, va siendo pues
un camino lento, progresivo y

00:50:54.090 --> 00:50:55.970
No sé, bastante interesante.

00:50:55.970 --> 00:51:02.210
Bueno tampoco vamos a irnos ahora opciones
habría que ver qué opciones tenemos de de

00:51:02.210 --> 00:51:09.850
clúster o solución en otros entornos que
es lo que nos nos ocupa pero claro el tema

00:51:09.850 --> 00:51:16.150
de analítico y todo eso y todo lo que era
big data del remanente y todo eso es claro

00:51:16.150 --> 00:51:21.870
es no fe que lo ha hecho muy bien allí ha
cogido ese mundo y fenómeno pero claro no Snowflake,

00:51:21.870 --> 00:51:24.203
no lo vas a usar para tu MySQL controlada.

00:51:24.250 --> 00:51:29.790
Pero tú tienes la sensación de que MySQL,
o sea, de que Oracle está metiendo dinero a

00:51:29.790 --> 00:51:37.130
MySQL on -premise. No digamos fórmulas de
estas como Headway, pero que está continuando

00:51:37.130 --> 00:51:44.330
y que está acercando, acotando distancias
entre el motor de Oracle y el motor de MySQL.

00:51:44.610 --> 00:51:46.166
¿Crees que lo está haciendo?

00:51:47.390 --> 00:51:53.790
Yo creo que menos, o sea, en la la partida
que gana la mano aquí es Heatwave, entonces

00:51:53.790 --> 00:52:00.870
todo lo demás está como
venga, remolcón el tema del

00:52:02.050 --> 00:52:08.190
cluster, los cambios hay matices, se van
mejorando cosas se van añadiendo cosas, nuevas

00:52:08.190 --> 00:52:14.830
funcionalidades, pks invisibles cosas
estas para que puede funcionar, porque hay cosas

00:52:14.830 --> 00:52:21.930
que necesitan y eso son curiosidades pero
son cosillas Las herramientas enterprise y

00:52:21.930 --> 00:52:27.150
demás no han experimentado grandes cambios,
grandes inversiones en los últimos años,

00:52:27.310 --> 00:52:30.910
porque está centrado en el mundo
cloud, mundo heatwave, etc.

00:52:30.910 --> 00:52:36.590
Entonces yo diría que va más a
heatwave y lo que queda pues cosillas.

00:52:36.610 --> 00:52:43.890
Por ejemplo, la gran, como diría,
cambio en MySQL es el cambio de estilo

00:52:43.890 --> 00:52:51.870
de CI, CD, de Continuous
Development, Continuous

00:52:51.870 --> 00:52:56.450
Investigation, para decir, el tema de LTS.

00:52:56.450 --> 00:53:03.450
La versión, la última, H3, está como
cogiendo las novedades y demás, pero si queremos

00:53:03.450 --> 00:53:08.490
una versión soportada y demás, es
la 8 .0, no me acuerdo cuánto y tal.

00:53:08.610 --> 00:53:13.590
Es como en dos líneas para permitir que,
oye, pues voy tranquilo, voy estable con esta.

00:53:13.850 --> 00:53:18.590
Si quiero bleeding edge o
cutting edge, estoy con la 8 .3.

00:53:18.750 --> 00:53:22.990
O sea, eso ha sido el gran cambio, pero
eso ha sido más filosófico, más que producto,

00:53:23.030 --> 00:53:29.450
features y demás. Más o sea que en ese
sentido yo hit wave cloud bueno y luego hay de

00:53:29.450 --> 00:53:35.400
todo es como en botica Estamos bastante
bastante a la par no hay que comparar también

00:53:35.400 --> 00:53:42.420
evidentemente o sea oracle es oracle
pero vale lo que vale para cosas con con

00:53:42.420 --> 00:53:45.780
conciertos presupuestos
pero muy interesante

00:53:47.080 --> 00:53:52.140
Quiz nos estamos llegando ya al final
del episodio que tal has estado al

00:53:53.770 --> 00:53:56.690
Principio nervioso porque al al fin y al
cabo esto siempre son cosas nerviosas pero mira

00:53:56.730 --> 00:54:02.090
pues una charla no te son al café mira
fíjate que estamos curiosamente la misma ciudad

00:54:02.090 --> 00:54:06.730
valencia y decías tú que nos tomamos el
café en persona de hombre pero en persona vamos

00:54:06.770 --> 00:54:13.910
a estar con dos ordenadores grabando en
el disco era una opción en una acción que

00:54:13.910 --> 00:54:19.250
no porque no hay cara a la playa claro esta
es una opción buena una una opción buena

00:54:19.250 --> 00:54:27.130
pues si quieres añadir algo más te dejo
el cierre por mi nada solo gracias por

00:54:27.130 --> 00:54:32.230
estar aquí todos gracias por hacer que
esto sirva de algo y si los que estáis escuchando

00:54:32.230 --> 00:54:37.650
la grabación espero que haya sirve ha
servido algo para el mundo h a mundo cluster de

00:54:37.650 --> 00:54:45.350
ahora clima que bien pues yo voy a gracias
a ti que es un gustazo hablar contigo te

00:54:45.350 --> 00:54:51.750
dejo dejo solamente una mención tenemos en
el Discord de Café de Atavéis un canal para

00:54:51.750 --> 00:54:58.770
MySQL donde tú ya has puesto algún
blog, algún post estás en el Café

00:54:58.770 --> 00:55:05.790
de Atavéis para para charlar conmigo,
para que alguien charle contigo, te

00:55:05.790 --> 00:55:13.390
veo ahí es tu casa, así que un
placer conocernos más no chateando,

00:55:13.450 --> 00:55:18.110
sino sino más hablando y
compartiendo una charla.

00:55:18.190 --> 00:55:20.850
Y muchísimas gracias
muchísimas gracias por...

00:55:21.560 --> 00:55:23.290
A ti y a todos ...por estar aquí.

00:55:23.330 --> 00:55:28.290
Gracias a vosotros pues nada, corto
audio y hasta el siguiente Episodio.