MySQL - Backup para flojos

Harima · 17 Agosto 2017

Continuando con nuestra serie para flojos, hoy tenemos backup para flojos
El Script hace un backup de todas las BD en la ruta indicada (no recuerdo donde saque el script pero gracias al autor

)

Script

Código:

#!/bin/bash
USER="mysqladmin"
PASSWORD="mysqladminpass"
#OUTPUT="/home/manager/backup"

#rm "$OUTPUTDIR/*gz" > /dev/null 2>&1

databases=`mysql -u $USER -p$PASSWORD -e "SHOW DATABASES;" | tr -d "| " | grep -v Database`

for db in $databases; do
  if [[ "$db" != "information_schema" ]] && [[ "$db" != "performance_schema" ]] && [[ "$db" != "mysql" ]] && [[ "$db" != _* ]] ; then
  echo "Dumping database: $db"
  mysqldump -u $USER -p$PASSWORD --databases $db > `date +%Y%m%d`.$db.sql
  # gzip $OUTPUT/`date +%Y%m%d`.$db.sql
  fi
done

luego dar permisos de ejecución

Código:

chmod +x backup.sh

Zuljin · 17 Agosto 2017

Oye @Harima, ¿conoces algún software gratuito que permita centralizar y automatizar backups de mysql?

K3rnelpanic · 17 Agosto 2017

Zuljin dijo:
Oye @Harima, ¿conoces algún software gratuito que permita centralizar y automatizar backups de mysql?

Un buen cron :zippy

Harima · 17 Agosto 2017

Zuljin dijo:
Oye @Harima, ¿conoces algún software gratuito que permita centralizar y automatizar backups de mysql?

Recuerdo que desde phpmyadmin podrias manejar varios servers, pero el backup era manual, pero nunca me gusto ese sistema.

voy a ver si encuentro algo, por el momento puedes agarrar el scrip y meterlo al cron. voy a ver si se pueden meter los archivos a algun recurso de red también.

Soujiro · 17 Agosto 2017

yo aplique crontab + python + innobackupex para nuestros servidores debido a que nuestra db es una ballena.

Miguelwill · 17 Agosto 2017

por mi lado uso cron + script (el script lista todas las db's ) y aplica un dump completo + compresion en bz2 al vuelo para reducir el acceso a disco al escribir (hasta 2 al dia en algunos servers)

despues los archivos los dejo en una ruta que respaldo con backuppc para tener los historicos

el script siempre es el mismo, solo cambia la clave de root y asi mantengo la ruta estandar (incluso si la tabla esta con pifias, se la salta y continua con el resto de tablas)

unreal4u · 27 Agosto 2017

Zuljin dijo:
Oye @Harima, ¿conoces algún software gratuito que permita centralizar y automatizar backups de mysql?

Percona XtraBackup junto con la demás suite de Percona por detrás.

Ahora la pregunta del millón: porqué centralizar backups? No tienes un esquema de replicación o simplemente tienes varios clientes distintos con use-cases totalmente distintos y los quieres centralizar?

Saludos.

unreal4u · 27 Agosto 2017

Por nuestro lado btw, tenemos 1 master y ~8 slaves, donde hay 2 que pueden tomar la posición de master en cualquier minuto (una máquina en producción y otro que es el servidor en la empresa donde van a parar los backups). Todavía no tenemos configurado un proxy (HAProxy es por el momento la mejor opción) por detrás, así que no es automático, pero sí es la idea. Hasta el momento, nunca nos hemos visto en la necesidad de ejecutar tal operación. (Toco madera)

La gracia de esto es que si queda la cagada en uno, el(los) otro(s) simplemente estará(n) disponible(s) y en un par de minutos (segundos si es automático) quedará todo funcionando de una.

Para cagazos de borrado accidental, tenemos un backup incremental diario (+ entero semanal) y el binlog (lo tenemos seteado a 1 semana, es demasiado largo pero mejor curar a prevenir, el otro día por ejemplo recién dp de 2 días nos dimos cuenta que un developer había borrado 3 horas de datos de una tabla específica, no era mucho lo que hubo que rescatar [74 rows] pero fue menos webeo que ir a rescatar las tablas con rdiff-backup).

Por lo demás, el backup para lo único que se ha ocupado en la empresa, es para generar una base de datos falsa para los desarrolladores en base a entradas reales.

Saludos.

unreal4u · 27 Agosto 2017

Harima dijo:
Continuando con nuestra serie para flojos, hoy tenemos backup para flojos
El Script hace un backup de todas las BD en la ruta indicada (no recuerdo donde saque el script pero gracias al autor )

Script

Código:

#!/bin/bash USER="mysqladmin" PASSWORD="mysqladminpass" #OUTPUT="/home/manager/backup" #rm "$OUTPUTDIR/*gz" > /dev/null 2>&1 databases=`mysql -u $USER -p$PASSWORD -e "SHOW DATABASES;" | tr -d "| " | grep -v Database` for db in $databases; do if [[ "$db" != "information_schema" ]] && [[ "$db" != "performance_schema" ]] && [[ "$db" != "mysql" ]] && [[ "$db" != _* ]] ; then echo "Dumping database: $db" mysqldump -u $USER -p$PASSWORD --databases $db > `date +%Y%m%d`.$db.sql # gzip $OUTPUT/`date +%Y%m%d`.$db.sql fi done

luego dar permisos de ejecución

Código:

chmod +x backup.sh

Veo unos cuantos problemas:

1- Tienes una contraseña a plena vista. Mejor dejar un archivo en el root (default es .my.cnf, pero le puedes pasar la opción) donde dejar las credenciales y este archivo sólo puede ser editado por el dueño del archivo. Esta es la manera oficial tb de hacer las cosas.
2- En mysqldump tienes la opción de --all-databases. Mejor ocupar esta antes que pedirle a la base de datos que te pase una lista de bases de datos. Esta opción además omite automáticamente performane- e information_schema.
3- Si alguien escribe datos durante la operación, con tu script puedes terminar con una base de datos inconsistente (Ejemplo: si tienes que escribir a la table "addresses" y "users" a la vez, y en el intertanto vas en la tabla "options" que pesa algunos gigas. Agrega --lock-tables o, mejor aún, --single-transaction (si todas las tablas son innodb como debería ser). También sugiero echarle un miro a --add-locks, --flush-logs y otras opciones (busca man mysqldump en google para más información). La solución definitiva a este problema, es crear un master y aplicar un backup a un cierto punto específico (echa un vistazo a --master-data y otros).

PD: Ah y por último, no aplicar live backup al master, sino al slave que sí se puede permitir algunos minutos sin escritura (y que de hecho no debería tener users que permitan escritura).

Saludos.

Zuljin · 27 Agosto 2017

unreal4u dijo:
Percona XtraBackup junto con la demás suite de Percona por detrás.

Ahora la pregunta del millón: porqué centralizar backups? No tienes un esquema de replicación o simplemente tienes varios clientes distintos con use-cases totalmente distintos y los quieres centralizar?

Saludos.

Una herramienta a prueba de diputados, un software, que Invoque los respaldos y los almacene en una ubicación protegida. Onda Dataprotector, Netvault, etc.

Enviado desde mi VS986 mediante Tapatalk

unreal4u · 27 Agosto 2017

Zuljin dijo:
Una herramienta a prueba de diputados, un software, que Invoque los respaldos y los almacene en una ubicación protegida. Onda Dataprotector, Netvault, etc.

Enviado desde mi VS986 mediante Tapatalk

Ah no conocía esas cosas modernas sho... pero, Netvault soporta mysql de forma "nativa" (con un plugin, pero parece que es de ellos mismo): https://www.quest.com/documents/netvault-backup-for-mysql-datasheet-68108.pdf

De todas formas, para respaldo nada mejor que replication, más que nada pq es sumamente fácil recuperarse de un desastre si ocurre, con muy poco downtime y además sirve para cagazos del nivel "cagó el disco" hasta el famoso (dicen) "amenui". A prueba de diputados no es sí, necesitas a alguien que cache al respecto por detrás. (Que a mi juicio siempre va a ser mejor antes que cualquier "magia" que un programa propietario pueda hacer).

Saludos.

Zuljin · 27 Agosto 2017

unreal4u dijo:
Ah no conocía esas cosas modernas sho... pero, Netvault soporta mysql de forma "nativa" (con un plugin, pero parece que es de ellos mismo): https://www.quest.com/documents/netvault-backup-for-mysql-datasheet-68108.pdf

De todas formas, para respaldo nada mejor que replication, más que nada pq es sumamente fácil recuperarse de un desastre si ocurre, con muy poco downtime y además sirve para cagazos del nivel "cagó el disco" hasta el famoso (dicen) "amenui". A prueba de diputados no es sí, necesitas a alguien que cache al respecto por detrás. (Que a mi juicio siempre va a ser mejor antes que cualquier "magia" que un programa propietario pueda hacer).

Saludos.

La replicación no es lo mismo que respaldo poh rucio. Las buenas prácticas dicen que hay que tener respaldo y replicación.

Enviado desde mi VS986 mediante Tapatalk

unreal4u · 27 Agosto 2017

lógico... pero explico más acá: http://www.capa9.net/foro/tema/mysql-backup-para-flojos.1119730/#post-13636896

Miguelwill · 28 Agosto 2017

Zuljin dijo:
La replicación no es lo mismo que respaldo poh rucio. Las buenas prácticas dicen que hay que tener respaldo y replicación.

Enviado desde mi VS986 mediante Tapatalk

pero vicking-man dice algo cierto
es mejor hacer un backup al slave y así no afectar al funcionamiento del máster , ya que ese debe recibir lecturas y escrituras constantemente
los slaves sirven para casi todo lo que sea lectura y extracción de datos , ideal para los dump que duran varios minutos y no se quiera usar CPU del máster para esas tareas

Enviado desde mi MSM8916 for arm64 mediante Tapatalk

Zuljin · 28 Agosto 2017

miguelwill dijo:
pero vicking-man dice algo cierto
es mejor hacer un backup al slave y así no afectar al funcionamiento del máster , ya que ese debe recibir lecturas y escrituras constantemente
los slaves sirven para casi todo lo que sea lectura y extracción de datos , ideal para los dump que duran varios minutos y no se quiera usar CPU del máster para esas tareas

Enviado desde mi MSM8916 for arm64 mediante Tapatalk

¿Un slave permite almacenar respaldos históricos? Por ejemplo

"Nos mandamos una cagada y todo lo hecho en las últimas tres horas no sirve, carguemos el respaldo de hace 4 horas"

o

"Necesitamos replicar lo que pasó la semana pasada en el ambiente de pruebas. Cárguenle el respaldo del miércoles pasado al ambiente de pruebas"

Soujiro · 28 Agosto 2017

Nosotros tenemos un Master-Master-Master utilizando GTID con maria db, eso si que 2 de los servidores no tienen habilitada la escritura, cosa que en caso de desastre del "oficial" cambiar a alguno de los en stand-by sea relativameten sencillo.

Ademas de eso tenemos el binary log para el ultimo mes (si un mes completo) y los respaldos están configurados con 1 completo a la semana y uno diario incremental utilizando innobackupex (percona). Los respaldos se ejecutan en uno de los master stand-by para evitar problemas de uso de recursos en el "oficial"

Finalmente tenemos 2 slaves conectados a uno de los master, el unico proposito de estos slaves es proveer de snapshots frescos de la db para correr los test de desarrollo, como medida extra de seguridad puse que uno de estos slaves va siempre retrasado 2 horas respecto al master official.

Ocupamos mas espacio que la CTM pero perder datos no es una opcion, por lo mismo todos los servers estan con RAID10

Miguelwill · 28 Agosto 2017

Zuljin dijo:
¿Un slave permite almacenar respaldos históricos? Por ejemplo

"Nos mandamos una cagada y todo lo hecho en las últimas tres horas no sirve, carguemos el respaldo de hace 4 horas"

o

"Necesitamos replicar lo que pasó la semana pasada en el ambiente de pruebas. Cárguenle el respaldo del miércoles pasado al ambiente de pruebas"

ehh directamente no ya que el slave tiene una replica del máster, lo que permite recibir consultas de lectura y así distribuir la carga de lectura de datos
ahí dependerá de cada cuanto tiempo se realice el backup

Enviado desde mi MSM8916 for arm64 mediante Tapatalk

unreal4u · 29 Agosto 2017

Zuljin dijo:
¿Un slave permite almacenar respaldos históricos? Por ejemplo

"Nos mandamos una cagada y todo lo hecho en las últimas tres horas no sirve, carguemos el respaldo de hace 4 horas"

o

"Necesitamos replicar lo que pasó la semana pasada en el ambiente de pruebas. Cárguenle el respaldo del miércoles pasado al ambiente de pruebas"

Ojo: no toi en contra de los respaldos ni tampoco digo que no hay que hacerlos, para los casos que mencionas, tomaría obviamente el último respaldo que se hizo y luego le aplicaría los binary logs hasta el punto exacto que se necesite. (Aunque por un tema legal, no puedo llegar y poner los dumps de live en ambiente de pruebas, estamos obligados a alterar [o "scramble" en inglés] todos los datos personales).

El tema es que hacer los respaldos, los hacemos desde un slave. Se para el slave (ok, técnicamente no es necesario, dependiendo de los parámetros que se le pasen a mysqldump), se crea el respaldo (100% consistente ya que no está recibiendo updates), con el parámetro --master-data=(1|2) se guarda la posición actual en el mismo dump y se echa a andar nuevamente el slave.
Argumentos: 1 escribe la posición como query, 2 la escribe pero como comentario en el mismo dump.

El otro tema que digo es que en los últimos años no hemos necesitado tomar algo de los respaldos, excepto para justamente crear las bases de datos para los desarrolladores.

Para el interesado en mayores detalles:

Si alguien se mandara un cagazo como el que describes, sería una falla de múltiples capas previas por nuestro lado, ya que eso significa que todos nuestras reglas se habrían saltado: pésimo P2P review, pésima revisión por parte del lead developer, mala implementación de los múltiples tests automáticos (tanto de integración como unit tests) y mal testeo por parte de los testers. También tenemos sistemas de monitoreo en staging (y por supuesto de live) que podría haber dado alguna alarma, pero estos son bien específicos y no controlan las variaciones en cantidad de datos (aunque la revisión que le hacemos a nuestra herramienta de backup sí).

Lo que posteo entre código es nuestra salida de revisión de respaldos, normalmente está todo bien, pero en este caso un colega (también respaldamos todas las máquinas de los developers una vez al día) estaba trabajando en el sistema de fotos (lo cual incrementó considerablemente el tamaño del respaldo, lógicamente tb se hace el checkeo por si ocurre lo contrario) por lo que saltaron las alarmas:

Código:

2017-08-29 04:40:07.406 | [DEBUG] Checking whether /media/disk1/backups/rdiff/workstations/nick/vagrant is active or not
2017-08-29 04:40:07.406 | [DEBUG] /media/disk1/backups/rdiff/workstations/nick/vagrant is an active folder, so checking it
2017-08-29 04:40:07.406 | [INFO] Checking directory /media/disk1/backups/rdiff/workstations/nick/vagrant
2017-08-29 04:40:07.614 | [INFO] Treshold for ElapsedTime is greater than 75%! (207.50%, was 24.28, is now 74.66). Please check
2017-08-29 04:40:07.614 | [INFO] Treshold for SourceFiles is greater than 5%! (274.98%, was 3397, is now 12738). Please check
2017-08-29 04:40:07.614 | [WARNING] Treshold for SourceFileSize is greater than 25%! (163.91%, was 24698669, is now 65182887). Please check
2017-08-29 04:40:07.614 | [INFO] Treshold for MirrorFiles is greater than 25%! (274.98%, was 3397, is now 12738). Please check
2017-08-29 04:40:07.614 | [WARNING] Treshold for MirrorFileSize is greater than 25%! (163.91%, was 24698669, is now 65182887). Please check

Soujiro dijo:
Nosotros tenemos un Master-Master-Master utilizando GTID con maria db, eso si que 2 de los servidores no tienen habilitada la escritura, cosa que en caso de desastre del "oficial" cambiar a alguno de los en stand-by sea relativameten sencillo.

Ademas de eso tenemos el binary log para el ultimo mes (si un mes completo) y los respaldos están configurados con 1 completo a la semana y uno diario incremental utilizando innobackupex (percona). Los respaldos se ejecutan en uno de los master stand-by para evitar problemas de uso de recursos en el "oficial"

Finalmente tenemos 2 slaves conectados a uno de los master, el unico proposito de estos slaves es proveer de snapshots frescos de la db para correr los test de desarrollo, como medida extra de seguridad puse que uno de estos slaves va siempre retrasado 2 horas respecto al master official.

Ocupamos mas espacio que la CTM pero perder datos no es una opcion, por lo mismo todos los servers estan con RAID10

Excelente solución, y lo mejor para no perder datos. Espacio da lo mismo si la integridad es lo más importante. El tiempo perdido si queda realmente la cagada y no tienes todos los respaldos como dios manda saldrá infinitamente más caro que un poco de espacio adicional en disco.

Saludos.

Harima · 29 Agosto 2017

Holi, Primero que todo

El titulo dice "Backup para flojos" porque no es la forma correcta, pero si puede servir para salir del paso. por lo menos que en un fallo no te pillen en pelotas.

La verdad que recién estoy volviendo al mundo Linux y MySQL, como somos partner de MS solo utilizábamos su software, luego cuando subimos a la nube y comenzamos a utilizar Linux, SQL Azure y ElasticSearch, como siempre trabajamos con clúster, el backup es sobre los controladores y no sobre la instancia como en MySQL, en el cual se configura un worker que realiza los backups de forma automatica. y no me acordaba lo "frágil" que es MySQL que se rompe hasta si lo miran feo.

Más que el realizar el backup, lo importante es probar el backup, antes nos teníamos que dar la paja de levantar backups de 500gb cada cierto tiempo para comprobar que estaban ok.

Miguelwill · 20 Octubre 2017

bueno, me toco hacer unos ajustes a un backup sobre este mismo tema, e investigando, encontre algo muy util para hacer los snapshots de las db replicadas, desde los slaves:

--dump-slave[=value]

This option is similar to --master-data except that it is used to dump a replication slave server to produce a dump file that can be used to set up another server as a slave that has the same master as the dumped server. It causes the dump output to include a CHANGE MASTER TO statement that indicates the binary log coordinates (file name and position) of the dumped slave's master. These are the master server coordinates from which the slave should start replicating.

--dump-slave causes the coordinates from the master to be used rather than those of the dumped server, as is done by the --master-data option. In addition, specfiying this option causes the --master-data option to be overridden, if used, and effectively ignored.

The option value is handled the same way as for --master-data (setting no value or 1 causes a CHANGE MASTER TO statement to be written to the dump, setting 2 causes the statement to be written but encased in SQL comments) and has the same effect as --master-data in terms of enabling or disabling other options and in how locking is handled.

This option causes mysqldump to stop the slave SQL thread before the dump and restart it again after.

In conjunction with --dump-slave, the --apply-slave-statements and --include-master-host-port options can also be used.

This option was added in MySQL 5.5.3.

con eso se puede agregar (comenado o no) la marca de posicion en la replicacion desde el SLAVE, lo cual ayuda para poder dejar ese dato disponible para, por ejemplo, cargar en otro slave, y despues continuar la sincronizacion desde ese punto , sin necesidad de hacer ese dump en el master
en mi caso dejo el parametro en "2" para que quede a mano pero no obligatorio, asi tambien puede servir para un "no-slave" o hasta para el propio master en algun caso "especial"
lo bueno que mientras dura el dump, la sincronizacion queda pausada, y retoma inmediatamente después de la extracción

saludos

MySQL - Backup para flojos

Pegao al tarro

Fundador

non serviam

Pegao al tarro

Fanático

I am online

I solve problems.

I solve problems.

I solve problems.

Fundador

I solve problems.

Fundador

I solve problems.

I am online

Fundador

Fanático

I am online

I solve problems.

Pegao al tarro

I am online