Montar un sistema de replicación es sencillo y rápido. Nos ofrece muchas ventajas, siempre y cuando funcione correctamente y no fallen los equipos. Ahora imagina con las siguientes características:

• Dos equipos en maestro-maestro.
• 50 equipos esclavos, 25 colgando del maestro 1 y otros 25 del maestro 2.

Ahora imagina que el maestro 1 se cae. Bien, recuerda que todo esto está en tu imaginación, no te intentes suicidar, aunque he de admitir que sería la solución mas razonable. Con la caida de ese Master, 25 equipos esclavos se han quedado desincronizados. Tenemos usuarios que ni pueden escribir y lo que leen está posiblemente anticuado. Cuando pones de nuevo el servidor en marcha compruebas que no se replican correctamente ya que alguna transacción quedó a medías. Tienes 26 ordenadores desincronizados y tienes que entrar uno a uno parando el proceso Slave, ejecutando el change_master, arranco de …

La arquitectura Maestro/Maestro es muy sencilla tanto de entender como implementar. Cuando vimos anteriormente Maestro/Esclavo, vimos que el Maestro se utilizaba para escrituras, mientras que en lecturas teníamos N servidores. En ese caso la lectura no es problema, hay suficiente hardware procesando peticiones, pero ¿qué pasa con la escritura?. Según el número de usuarios aumente y la carga de escrituras sea mayor, dicho servidor terminará por no dar a basto ralentizando el buen funcionamiento de nuestras aplicaciones. Maestro/Maestro viene a solucionarnos este problema.

En este caso, H1 y H2 reciben las peticiones de escritura. Los dos deben tener los datos sincronizados, para ello se sigue el siguiente esquema:

• H1 es maestro de H2 (por lo tanto H2 esclavo de H1)
• H2 es maestro de H1 (por lo tanto H1 es esclavo de H2)

De esta forma, todo lo escrito en H1 se replicará a H2 y viceversa. …

La cosa se pone interesante :P

The regulators see a major conflict of interest in the world's largest commercial database company owning its largest open source competitor.

A lo que Oracle responde:

It is well understood by those knowledgeable about open source software that because MySQL is open source, it cannot be controlled by anyone.

MySQL se esta convirtiendo en un problema para Oracle, retrasando infinitamente la fusión que Sun parece necesitar a gritos.

Lo que no deben saber, es que estas cosas se solucionan con un duelo de bailes.

Fuente con más información (que yo estoy vago)

Poco a poco todos vamos utilizando todas y cada una de las aplicaciones de Google y entregando todos nuestros datos, fotos, gustos, necesidades, etc. Yo me di cuenta cuando noté, que aún teniendo un VPS, leía los RSS en Google Reader, veía mis fotos en Picasa Web Album, leía mi correo en Gmail, subía mis ficheros a Google Docs, apuntaba mis tareas en iGoogle. Entonces, ¿para que cojones tengo un servidor dedicado?

Me propuse como tarea principal migrar todos esos servicios a algo que YO pueda controlar, así que me pasé una tarde bastante aburrida navegando por Freshmeat. Y encontré soluciones (todas ellas Php+Mysql) más que válidas:

PHPfileNavigator: interfaz web para la administración de ficheros. Se puede subir cualquier tipo de ficheros, comprimirlos, subdividirlos en carpetas, buscador, múltiples usuarios, soporte para miniaturas, etc. Al contrario que con …

Muchas veces ejecutamos queries cuyas salidas no entran en la pantalla, obligando a desplazarnos de arriba abajo una y otra vez para encontrar el contenido que nos interesa. En una shell la solución es sencilla, utilizar un pipe para a continuación enviar la salida a un comando de paginado como more o less. Bien, esto también es posible en MySQL.

mysql> pager more

Y listo. Ahora cada vez que hagas una querie, esta será enviada a more, mostrandote el resultado pantalla a pantalla. Pero si nos paramos a pensar podemos encontrar muchas mas utilidades a este comando. Por ejemplo:

mysql> pager md5sum

Con este tenemos un resumen md5 de la salida del comando, util para saber rápidamente si algún dato ha sido modificado.

mysql> pager mail -s "salida de mysql" direccion@dominio.com

Y con este la salida de un comando se enviará directamente por correo a la dirección indicada.

…

Nuevo: ¡¡¡Elige cualquier Paquete de certificación ‘Success’ en Java o MySQL (curso + voucher de certificación) y podrá volver a examinarse gratuitamente, en caso de que no apruebe. Promoción sólo hasta el 31 de diciembre!!! Reserve su curso ahora y obtenga un descuento del 10% + iPod Touch de regalo El próximo 30 de noviembre [...]

La diferencia salta a la vista ;)

Lista de parches aplicados

Original

Mysql tiene muchos posibles permisos a establecer. Algunos son globales, otros de tablas, otros de bases de datos... Recordar todos es dificil y además una perdida de tiempo. Un truquito para conocer todos los posibles permisos, descripción y ámbito de uso :)

mysql> show privileges\G
*************************** 1. row ***************************
Privilege: Alter
Context: Tables
Comment: To alter the table
*************************** 2. row ***************************
Privilege: Alter routine
Context: Functions,Procedures
Comment: To alter or drop stored functions/procedures
*************************** 3. row ***************************
Privilege: Create
Context: Databases,Tables,Indexes
Comment: To create new databases and tables
*************************** 4. row ***************************
Privilege: Create routine
Context: …

Imaginemos que tenemos una infraestructura Maestro/Esclavo y el esclavo lo usamos para lecturas, backup o simplemente para dar un servicio mínimo si el Maestro se cae. Imaginemos que dicha replicación lleva caída un mes y el Maestro se rompe. Cuando te das cuenta es demasiado tarde y entonces toca imaginarse como huir sin que te pillen :)

Monitorizar si la replicación es correcta es sencillo, ya que MySQL nos puede dar en segundos el desfase que existe entre un host y otro a la hora de replicar los cambios. Con "SHOW SLAVE STATUS\G" tendremos la información que necesitamos:

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.60.1.3
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000021
Read_Master_Log_Pos: 327326
Relay_Log_File: mysqld-relay-bin.000061
…

Esa frase, pronunciada por Ellison (CEO de Oracle), es una frase más propia del Capitán Obvio.

Ahora mismo la situación es algo incierta para SUN, con 100 millones de perdidas cada mes necesita la fusión cuanto antes de las dos empresas para dejar tirar dinero, pero para ello necesitan la aprobación de los tribunales tanto Estadounidenses como Europeos. Este recelo es lógico, ya que las dos empresas tienen como pilares básicos dos Bases de Datos, Oracle y MySQL. Pero algo que está claro, es que a pesar de ser lo mismo, no tiene ni el mismo enfoque ni el mismo mercado como objetivo, por lo tanto la frase de Ellison es de una lógica más que aplastante. MySQL no es competencia para ellos y no se desharán de el. Ni de Mysql ni de otras de las punteras tecnologías que SUN dispone, como SPARC, almacenamiento, virtualización, etc.

"We are keeping everything. We're keeping tape. We're keeping storage. We're keeping x86 …