Copias de seguridad de MySQL sin tiempo de inactividad en un presupuesto

Mi escenario actual de copia de seguridad de MySQL es replicar nuestra base de datos en un segundo servidor y ejecutar mysqldump en ese servidor para eliminar cualquier tiempo de inactividad del bloqueo de tablas o filas. Esto funciona bien, pero cuesta $ 150 por mes para el segundo servidor (el alojamiento en Australia es mucho más caro que en Estados Unidos).

Leí muchas preguntas sobre esto, la mayoría de la gente necesita ayuda con las copias de seguridad programadas y lo que no es lo que necesito. Necesito mysqldump (preferiblemente cada 4 horas) sin tiempo de inactividad. La base de datos es de ~ 7 GB sin comprimir, por lo que mysqldump puede tardar un tiempo dependiendo del servidor.

He considerado replicarme en la misma máquina, pero no quería que el esclavo se comiera la memoria que tanto necesitaba. ¿No estoy seguro de poder restringir el uso de memoria por base de datos? De cualquier manera, esto pondrá carga en el servidor mientras descarga la base de datos.

Acabo de leer este http://www.zmanda.com/quick-mysql-backup.html y se ve bien, $ 300 por año está bien, eso me ahorra mucho.

Desafortunadamente, no puedo replicar a RDS de Amazon, pero podría replicar a una instancia micro RC2, pero la replicación se llevaría a cabo a través de la red y el ping es de ~ 220 ms.

Vi a algunas personas aquí hablando de instantáneas de LVM que podrían ser una buena opción. Aunque no sé mucho sobre esta opción.

Las opiniones serán muy apreciadas.

Si usa tablas innodb, puede usar

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Eso tomará un volcado de su base de datos que sus herramientas pueden importar también sin bloquear. Creo que si tienes mesas myisam las bloquea.

Si está usando innodb u otro backend que es completamente transaccional, puede usarlo mysqldump --single-transaction .... He usado esto en bases de datos bastante grandes (~ 100GB) con buenos resultados; Si la base de datos está bajo una carga pesada, puede llevar horas, pero funciona sin bloquear las tablas. La replicación es generalmente mejor, pero a veces quieres un buen archivo de volcado sólido. Tenga en cuenta que también puede volcar un esclavo de replicación mysql.

Desde la página mysqldump (tenga en cuenta las advertencias sobre las operaciones que se filtrarán en la transacción):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

No veo muchos problemas para replicar a través de una conexión de alta latencia a un VPS barato en los Estados Unidos. La alta latencia no debería ser realmente un gran problema. La replicación está diseñada para poder ponerse al día rápidamente incluso cuando un esclavo se atrasa horas , es decir, puede funcionar de forma asincrónica.

Siempre que pueda soportar tanto ancho de banda saliente en su plan de alojamiento australiano.

Aquí hay una respuesta mucho más detallada sobre si la alta latencia importaría

Siendo realistas, solo el tiempo que lleva exportar la base de datos será tiempo de inactividad. Hágalo durante un período de tiempo lo suficientemente lento y no debería haber NINGÚN problema. ¿Qué espera realmente un departamento de TI con ese presupuesto?

Debería poder mysqldump una base de datos de 7GB en 5-10 minutos MAX, quitar el bloqueo de lectura / escritura y el tiempo de inactividad terminará. Luego puede encontrar la forma más efectiva de ancho de banda para el archivo de 7GB al nuevo servidor (lea: ALTA COMPRESIÓN). Tiene tiempo de sobra para transferir e importar el archivo a MySQL en el nuevo servidor. Luego, ingrese la información del registro maestro y comience la replicación. Debería ser un pedazo de pastel!

La documentación de MySQL es fantástica : http://dev.mysql.com/doc/refman/5.0/en/replication.html

No estoy seguro de poder restringir el uso de memoria por base de datos

Por supuesto que puede, solo necesita ejecutar el esclavo con un /etc/my.cnf diferente

Incluso puede hacer cosas para manipular la prioridad de programación / afinidad de CPU en el maestro y el esclavo utilizando nice / renice y taskset (suponiendo que sea un servidor Linux).

pero la replicación se llevaría a cabo a través de la red y el ping es de ~ 220 ms

La latencia es prácticamente irrelevante, lo importante es el ancho de banda, y el ancho de banda de la base de datos (suponiendo que no esté replicando los datos de la sesión) es de varios órdenes de magnitud menos que el ancho de banda HTTP.

Necesito [crear una copia de seguridad coherente de la base de datos] (preferiblemente cada 4 horas) sin tiempo de inactividad

Pero las estrategias que discute no permiten la recuperación en ningún momento como ese.

Creo que la opción más barata sería un esclavo en la misma máquina, y si afecta negativamente el rendimiento más allá de lo que puede reconfigurar, actualice el paquete de alojamiento actual.

También puede considerar ejecutar un esclavo desconectado: habilite los registros de bin en el servidor actual. Obtenga una copia de seguridad, restaure la copia de seguridad en una máquina local, luego copie los registros del contenedor a medida que se rotan y avance en el DBMS local .

Mi sugerencia:

1 - mantenga su segunda cuenta / servidor e implemente la replicación a una base de datos en su cuenta / servidor original.

2: detener la replicación a la segunda cuenta / servidor.

3: supervise el rendimiento durante unos días. Asegúrese de monitorearlo el tiempo suficiente para incluir sus períodos de mayor actividad.

4: prepárese para cambiar a su configuración anterior si hay un problema importante de rendimiento. Esta es la razón por la que mantuvo la segunda cuenta.

5 - compre más capacidad / actualice el servidor en su cuenta original. Esto debería ser más barato que pagar por dos servidores, creo.

6 - cancelar la segunda cuenta.

¡Buena suerte!