Mi experiencia con los triggers proviene principalmente de SQL Server, plataforma en la que he hecho un uso bastante extenso de ellos, y me atrevería a asegurar que para algunos programadores, en según que condiciones, los triggers pueden abrir un mundo nuevo de posibilidades, facilitando enormemente la realización de algunas tareas que de no ser por éstos tendrían una resolución bastante más aparatosa.

Qué son los triggers en MySQL

Los triggers (o desencadenadores) son pequeños programas creados por el usuario que se invocan de forma automática por el propio motor de bases de datos al producirse ciertos eventos, lo que nos permite capturarlos, controlarlos e intervenir en ellos.

En MySQL los eventos que podemos capturar son los relacionados con las sentencias INSERT, UPDATE y DELETE.

Precauciones en el uso de triggers

Antes de entrar de lleno con ellos, es importante conocer cuales son los inconvenientes más comunes derivados de su uso para así evitarlos o cuanto menos minimizarlos.

El primero de ellos es el rendimiento. Ejecutar el código programado en el trigger conlleva un consumo de recursos que por norma general suele ser muy superior al de la sentencia que lo origina. Por lo tanto deberemos tener en cuenta esa carga y optimizarla para evitar posibles problemas como ralentización del sistema o interbloqueos.

El segundo inconveniente a tratar es la visibilidad. Hablamos de una porción de código que se encuentra completamente separada del resto, lo que en ocasiones puede provocar que nos olvidemos que está ahí, o que lo desconozcamos por completo si nos enrolamos en un nuevo proyecto.

Y una recomendación derivada del punto anterior, es poner un extra de atención para asegurar su correcto funcionamiento, o de lo contrario podemos encontrarnos con resultado indeseados mucho tiempo después de su activación.

Por último debemos destacar el efecto global de los triggers, que actuarán siempre que ocurra el evento para el que han sido definidos, independientemente de la aplicación, usuario o cualquier otra variable de sistema que se nos ocurra. Esta condición es intrínseca los triggers y es básicamente lo que buscamos, pero debemos recordarlo si en algún momento actuamos sobre la base de datos desde un lugar diferente al habitual.

Cuándo utilizar triggers

Desde mi punto de vista los triggers tienen dos escenarios principales de uso:

El primero es cuando no podemos intervenir en el código fuente de la aplicación que trabaja sobre la base de datos sobre la que queremos actuar o reaccionar a sus eventos.

El segundo es cuando a pesar de disponer del código, éste pertenece a un software desarrollado por terceros y existe una probabilidad relativamente alta de aplicar actualizaciones o instalar pluggins, y hemos decidido modificar el código fuente lo menos posible para facilitar este tipo de tareas.

Un ejemplo muy habitual son integraciones de software en las que al menos uno de los programas que intervienen es de código cerrado. En este tipo de situaciones los triggers nos permiten capturar los eventos que modifican la base de datos y actuar en consecuencia, evitando crear tareas programadas y e incluso tablas de integración.

Cuándo no utilizar trigger

Cuando tenemos acceso al código fuente de la aplicación que trabaja sobre la base de datos que nos interesa y no tenemos que mantener ningún tipo de compatibilidad con cambios como nuevas versiones, no existe razón alguna para utilizar triggers. En estos casos será mejor trabajar sobre el código de la aplicación y así evitaremos los inconvenientes de uso de los triggers.

Bien sea para registrar logs de acciones, generar registros de integración, realizar validaciones pre o post inserción o cualquier otra tarea que se nos ocurra, siempre será más eficiente, más visible y por lo tanto sencillo para el programador delegar esa responsabilidad en la propia aplicación.

Usando los triggers

Muy bien, ya hemos tomado las consideraciones necesarias y hemos decidido utilizar triggers, veamos ahora cómo crearlos.

Sentencias sobre las que podemos crear triggers

Ya lo adelantábamos al comienzo del artículo, podemos crear triggers que actúen sobre las sentencias:

• INSERT
• UPDATE
• DELETE

De esta forma podremos intervenir cada vez que se inserte, modifique o elimine un registro.

Cada trigger se define para un tipo de evento, de forma que si queremos controlar los tres eventos para una determinada tabla deberemos crear tres triggers.

También es importante mencionar que los triggers actúan registro a registro, es decir, supongamos que tenemos una sentencia UPDATE que modifica 100 registros, el trigger se ejecutará 100 veces, una por cada registro modificado

BEFORE y AFTER

Y como complemento al tipo de sentencia, podemos decidir si intervenir antes o después de que ésta realice los cambios. Así un trigger AFTER INSERT nos permitirá actuar una vez que el nuevo registro este insertado, y un trigger BEFORE DELETE lo hará antes de eliminar un registro.

La combinación del tipo de sentencia con BEFORE o AFTER nos ofrecen mucha versatilidad a la hora de diseñar nuestros triggers.

NEW y OLD

NEW y OLD son las palabras reservadas de MySQL para acceder a los valores de los registros sobre los que estamos trabajando.

• OLD nos permite acceder a los datos previos a la modificación realizada por la sentencia.
• NEW nos permite acceder a los nuevos datos que propone la sentencia.

La sintaxis es muy sencilla, OLD.campo o NEW.campo, dónde campo es el nombre del campo de la tabla al que queremos acceder.

Cómo crear un trigger en MySQL

Y una buena forma de aprender a crear un triggers es mediante un ejemplo, así que veamos uno. Supongamos que tenemos la tabla brands que forma parte de la base de datos de un software propietario:

+----+----------+---------+
| ID | Name     | Segment |
+----+----------+---------+
|  1 | Opel     | Mass    |
|  2 | Renault  | Mass    |
|  3 | Ford     | Mass    |
|  4 | Audi     | Premium |
|  5 | Mercedes | Premium |
|  6 | Porche   | Luxury  |
|  7 | Ferrari  | Luxury  |
+----+----------+---------+

Y queremos registrar los cambios que se producen para integrarlos con otro sistema, para lo que hemos creado una tabla en la que registraremos cualquier cambio que se produzca en la tabla brands. La nueva tabla la hemos llamado integration, y tiene los siguientes campos:

+----+--------+----------+--------+---------------------+-----------+---------------+------------+
| ID | Object | ObjectID | Action | DateCreated         | Processed | DateProcessed | ErrorCount |
+----+--------+----------+--------+---------------------+-----------+---------------+------------+

Para registrar todos los cambios que se produzcan en la tabla brands deberemos generar tres triggers:

• Uno para registrar los nuevos registros: AFTER INSERT.
• Uno para registrar los cambios: AFTER UPDATE.
• Uno para registrar las eliminaciones: BEFORE DELETE.

En esta entrada crearemos únicamente el trigger para la sentencia INSERT. Crear el resto de triggers se hace de forma muy similar, y en caso de que estés interesado en aprender será una buena práctica.

Así que veamos como crear el trigger, que será el encargado de registrar las nuevas marcas:

delimiter //
CREATE TRIGGER brandsInsertLog AFTER INSERT ON brands
FOR EACH ROW
BEGIN

	INSERT INTO integration (`Object`, `ObjectID`, `Action`, `DateCreated`, `Processed`, `DateProcessed`, `ErrorCount`) 
	VALUES ('brands', NEW.ID, 'insert', now(), 0, null, 0);

END;//
delimiter;

De forma que si ejecutásemos una sentencia de de inserción sobre la tabla brands:

INSERT INTO `osticket`.`brands` (`ID`, `Name`, `Segment`)
VALUES (8, 'Citroen', 'Mass');

Se registraría automáticamente la entrada correspondiente en la tabla integration:

+----+--------+----------+--------+---------------------+-----------+---------------+------------+
| ID | Object | ObjectID | Action | DateCreated         | Processed | DateProcessed | ErrorCount |
+----+--------+----------+--------+---------------------+-----------+---------------+------------+
|  1 | brands |        8 | insert | 2019-09-21 08:20:07 |         0 | NULL          |          0 |
+----+--------+----------+--------+---------------------+-----------+---------------+------------+

Así de sencillo. Espero que esta entrada te haya servido de ayuda y si es así un comentario siempre es de agradecer.

Créditos, referencias y artículos relacionados

• Imagen Peggy und Marco Lachmann-Anke en pixabay.
• Documentación sobre triggers de María DB
• Documentación sobre triggers de MySQL
• Backup de base de datos MySQL con PHP
• Servidor Web en Raspberry PI y Ubuntu Mate

Esta entrada pertenece a la serie Clonar una web en un servidor local. Por ese motivo te recomiendo que leas dicho artículo para darle perspectiva a este. Sea como sea, este artículo puede ser leído sin la referencia anterior, pero perderemos ciertos matices que quizás resulten interesantes.

Backup de la base de datos remota

En función del hosting que tengamos contratado dispondremos de una serie de funcionalidades. Por norma general si has contratado un VPS o servidor dedicado tendrás la posibilidad de ejecutar scripts de consola, lo cual ofrece muchas posibilidades para la tarea que queremos realizar.

Si por el contrario dispones de un hosting compartido no sueles tener acceso a esta opción, así que para dar respuesta a la mayor cantidad de situaciones posibles realizaremos el backup con PHP, más concretamente haremos uso de la clase MySql Backup Lite que introducimos en la entrada Backup de base de datos MySQL con PHP. Y para programar la ejecución de esta tarea nos ayudaremos de nuestro servidor local, dónde programaremos la ejecución de un script que acceda a la url que realiza el respaldo.

Para no extendernos demasiado y no repetirnos, no copiaremos la clase en esta entrada, puedes encontrarla en los enlaces del párrafo anterior.

Así que crearemos un script en PHP en nuestro servidor remoto que llamaremos backUpDb.php en el directorio scripts que tras ser ejecutado generará una copia de la base de datos en el archivo backups/wordpressBackUp.sql.

include('MySqlBackup.php');

$arrayDbConf['host'] = 'dbHost';
$arrayDbConf['user'] = 'dbUser';
$arrayDbConf['pass'] = 'dbPassword';
$arrayDbConf['name'] = 'wordpressDbName';

try {

  $bck = new MySqlBackupLite($arrayDbConf);
  $bck->backUp();
  $bck->setFileDir('../backups/');
  $bck->setFileName('wordpressBackUp.sql');
  $bck->saveToFile();

}
catch(Exception $e) {

  die($e);

}

Si nuestro hosting tiene habilitada la conexión remota a la base de datos este paso podríamos ejecutarlo en el servidor local. Como no siempre tendremos esta opción, nos hemos decantado por la alternativa más universal.

Y puesto que en este ejemplo el backup es de una plataforma WordPress, y que por ese motivo los datos de conexión a la base de datos ya están especificados en un archivo de configuración escrito en PHP, sería más interesante hacer un include del archivo wp-config.php y obtenerlos desde ahí. De nuevo, en pro de mantener esta entrada lo más genérica posible hemos decidido hacerlo así.

Programar la ejecución del backup de la base de datos

Una vez más existen múltiples opciones para programar esta tarea, unas más elegantes que otras. En un VPS programar una tarea con Cron sería lo más lógico y eficiente, pero tal y como hemos comentado, tomaremos la opción que podemos aplicar independientemente del hosting que tengamos: utilizaremos Cron en nuestro servidor local para programar una tarea que ejecute el script de backup de base de datos que acabamos de crear en el host remoto.

Para ello creamos un script de consola y le asignamos los permisos necesarios:

mkdir ~/scripts
vim ~/scripts/cloneWebDb.sh
chmod 0755 ~/scripts/clonWebDb.sh

Con el siguiente contenido:

#!/bin/bash

curl -Is https://url.com/scripts/backUpDb.php

Y programamos la ejecución del script con Cron:

crontab -e

E incluimos la siguiente línea en el archivo crontab:

0 1 * * 5 ~/scripts/clonWebDb.sh

Asegurándonos de que el script se ejecuta cada Viernes a la 1 de la madrugada. Evidentemente puedes programar la periodicidad que más te convenga. Puedes visitar la entrada Programar tareas en Ubuntu con Cron para profundizar en la programación de tareas con Cron.

Descargar el backup de la base de datos

Lo siguiente es descargar el backup que acabamos de realizar. Lo haremos mediante el protocolo ftp, sirviéndonos del comando wget. Para ello agregamos una línea más a nuestro script clonWeb.sh, de forma que quede así:

#!/bin/bash

curl -Is https://url.com/scrpts/backUpDb.php
wget -q --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com/backups/wordpressBackUp.sql

Dónde:

• -q, oculta los mensajes de salida del comando
• –user=user, es el usuario ftp
• –password=’password’, es la contraseña del ftp
• –directory-prefix=~/webBackUp, es el directorio dónde copiaremos los archivos
• fttp://ftp.url.com/backups/wordpressBackUp.sql, es el ftp con el path del que queremos descargar los archivos

Con esto ya habremos descargado nuestra base de datos en el directorio ~/webBackUp/ftp.url.com/backups/wordpressBackUp.sql. El siguiente paso será restaurarla.

Restauración de la base de datos

Y para restaurar la base de datos en nuestro servidor local la estrategia que seguiremos será:

1. Eliminamos la base de datos.
2. Volvemos a crear base de datos vacía.
3. Restauramos la base de datos desde el backup.

Como puedes ver el proceso es bastante crítico pues elimina completamente la copia existente. Además hará que durante el tiempo que toma el proceso nuestro clon local no esté accesible. En mi caso el uso que le voy a dar es disponer de una réplica de una web en productivo en un servidor local para realizar pruebas. Para este uso el riesgo es perfectamente asumible, y en todo el tiempo que llevo utilizándola no he tenido ningún tipo de problema. Evidentemente, tú deberás evaluar si este riego y esta parada de servicio son asumibles para ti.

Así que crearemos un script SQL que elimine completamente la base de datos y vuelva a crearla. De nuevo lo haremos dentro de la carpeta ~/scripts y lo llamaremos dropAndCreateDb.sql. El contenido será el siguiente:

DROP DATABASE localDbName;
CREATE DATABASE localDbName;

Y agregamos dos líneas más a nuestro script de consola para ejecutar

#!/bin/bash

curl -Is https://urlToScript.com/backUpDb.php
wget -N -q --user=user --password='password' --directory-prefix=~/webBackUp ftp://ftp.miweb.com/path/backups/wordpressBackUp.sql
mysql -u localDbUserName -plocalDbPassword localDbName < ~/scripts/dropAndCreateDb.sql
mysql -u localDbUserName -plocalDbPassword localDbName < ~/webBackUp/ftp.url.com/backups/wordpressBackUp.sql

Actualización de los datos relativos al entorno

El último paso para dar por completado el proceso de clonación de nuestra base de datos será reemplazar todos los datos datos necesarios para que nuestro clon funcione perfectamente. Este paso es el que más puede variar de un entorno a otro, a continuación os dejo un ejemplo bastante básico para un blog realizado en wordpress:

update wp_options set option_value='http://192.168.1.10' where option_name='siteurl';
update wp_options set option_value='http://192.168.1.10' where option_name='home';
update wp_posts set guid=REPLACE(guid, 'blog.ahierro.es', '192.168.1.146:8085') where guid like '%blog.ahierro.es%';

Vosotros tendréis que localizar las tablas, campos y registro a modificar en vuestras plataformas. En el ejemplo expuesto las dos primeras líneas hacen referencia a datos de configuración y son imprescindible, pues de no actualizar estos campos nuestro wordpress local siempre redirigiría al remoto.

Créditos y Referencias

• Articulo de la serie: Clonar una web en un servidor local.
• Siguiente entrega de la serie: Clonar una web: los archivos.
• Clase MySql Backup Lite.
• Imagen de portada: Martin Harry.

Y cuando hablamos de «una copia exacta», queremos decir que tanto archivos como bases de datos estén perfectamente actualizados. Esto es muy útil para realizar pruebas de todo tipo: nuevos plugins, cambios de configuración, revisión de actualizaciones, etc.

Realizar esta tarea manualmente es tedioso, aburrido y consume mucho tiempo, eso sin contar que es probable que cuando nos propongamos realizar nuestras pruebas este entorno esté desactualizado, alterado por las últimas pruebas realizadas, o lo que es aún peor, no esté disponible. Así que una buena idea es automatizar esta tarea y programar su ejecución con la periodicidad que nos interese.

Algunos aspectos relativos al clonado

Resumen del proceso

Es buena idea tener una visión general del proceso antes de adentrarnos en él. Lo que vamos a hacer básicamente es un proceso ETL (Extract, Transform, Load) manual.

Como parte del proceso de extracción realizaremos una copia de seguridad de la base de datos y la descargaremos a una ubicación intermedia. Haremos lo mismo con los archivos del servidor.

Una vez tenemos todo lo necesario en nuestro servidor local, modificamos algunos datos como son archivos de configuración o los registros en la base de datos relativos al entorno.

Finalmente restauraremos la base de datos y sobrescribiremos los archivos de nuestro servidor local.

Local versus Remoto

A pesar de que cada una de las tareas que realizaremos no son complicadas por si mismas, alternaremos de host continuamente y eso puede generar alguna confusión, así que para seguir los pasos indicados sin error deberemos estar muy atentos al host en el que se realizan las distintas acciones. Identificaremos los hosts como «remoto», el servidor de producción que queremos clonar, y «local» el servidor de pruebas dónde queremos tener la copia.

Es importante que las versiones de LAMP (Linux, Apache, PHP y MySQL) sean lo más similar posible, de este modo es posible que nos ahorraremos algunos quebraderos de cabeza. Además, es recomendable dedicar un virtual host de Apache para este entorno en nuestro servidor local.

Ejemplo sobre WordPress

Y ya que estas líneas que lees están escritas sobre WordPress, utilizaremos esta plataforma como ejemplo para realizar el clonado. Esto quiere decir que por norma general, si queréis clonar otra plataforma, las mayores diferencias las encontraremos en los los registros de la base de datos y los archivos de configuración referentes al entorno.

Periodicidad

Como hemos dicho queremos automatizar el clonado de nuestra web para tener nuestra réplica preparada y actualizada en todo momento. Podemos establecer la periodicidad que más nos convenga, personalmente estoy cómodo con una semana por dos motivos:

1. En una semana no suelen producirse muchos cambios en el blog.
2. Algunas pruebas se extienden durante varios días, y una restauración diaria las sobrescribiría.

Además, siempre estamos a tiempo de lanzar una actualización manual en caso de ser necesario con la simple ejecución de un script. Si no tienes una web muy grande el proceso será relativamente rápido.

Requisitos hardware

En cuanto a los requisitos de hardware puedes estar tranquilo, pues no necesitas un gran servidor para implementar este sistema. Un ejemplo muy claro de ello es que para este blog lo tengo implementado con una humilde Raspberry Pi. Por si te interesa, aquí te dejo un enlace en el que puedes ver cómo de sencillo es montar un servidor web Apache sobre una Raspberry Pi.

Clonando nuestra web: el proceso

Llegados a este punto creo que al igual que yo ya tendréis ganas de poneros manos a la obra, así que no me enrollo más y vamos al lío.

Y puesto que esto se ha alargado un poco más de la cuenta, hemos dividido este artículo en varias entregas para que sea más fácil de seguir:

1. Clonar una web en un servidor local (es decir, esta entrada).
2. Clonar una web: la base de datos.
3. Clonar una web: los archivos.

Créditos y referencias

• Imagen de portada: Martin Harry.

Otra de esas posibilidades de las que hablamos es realizar el respaldo con PHP, lo que nos permitirá hacerlo con casi todos los hostings, además de que es fácilmente automatizable. La principal desventaja, por contra, es que es una opción algo más laboriosa, pues tendremos que programar el script. Pero como la rueda casi siempre está inventada, en internet tienes muchas soluciones que te facilitarán la labor.

MySQL BackUp Lite

Yo os propongo esta sencilla solución que he desarrollado, de la que os dejo el código a continuación. En cualquier momento puedes acceder a la versión más actualizada de MySQL Backup Lite en Github.

/**
*
* MySql Backup Lite Class
*
* @author     Andres Hierro
* @copyright  2019 Andres Hierro
* @license    http://www.apache.org/licenses/LICENSE-2.0  Apache License, Version 2.0
* @version    0.0.1
* @link       http://ahierro.es/
*
*
*
* Copyright 2019 Andrés Hierro
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/

class MySqlBackupLite {

  private $host;
  private $user;
  private $pass;
  private $name;

  private $fileName = "mySqlBackup.sql";
  private $fileDir = "./";
  private $fileCompression = false;

  private $timeZone = '+00:00';

  private $mySqli;
  private $sqlString = "";
  private $arrayTables;

  private $tableFieldCount = 0;
  private $tableNumberOfRows = 0;
  private $queryResult;



  public function __construct(array $arrayConnConfig) {

      if (
        (!isset($arrayConnConfig['host'])) ||
        (!isset($arrayConnConfig['user'])) ||
        (!isset($arrayConnConfig['pass'])) ||
        (!isset($arrayConnConfig['name']))
      ) {
          throw new Exception('Missing connection data.');

      }
      $this->setHost($arrayConnConfig['host']);
      $this->setUser($arrayConnConfig['user']);
      $this->setPass($arrayConnConfig['pass']);
      $this->setName($arrayConnConfig['name']);

  }



  public function backUp() {

    $this->connectMySql();
    $this->getTables();
    $this->generateSqlHeader();
    $this->createTableStaments();
    $this->insertStaments();
    $this->generateSqlFooter();

  }



  private function setHost($host) {
    $this->host = $host;
  }



  private function setUser($user) {
    $this->user = $user;
  }



  private function setPass($password) {
    $this->pass = $password;
  }



  private function setName($name) {
    $this->name = $name;
  }



  public function setFileName($name) {
    $this->fileName = $name;
  }



  public function setFileDir($dir) {
    $this->fileDir = $dir;
  }



  public function setFileCompression($compression) {
    $this->fileCompression = $compression;
  }



  private function connectMySql() {

    $this->mySqli = new mysqli($this->host, $this->user, $this->pass, $this->name);
    $this->mySqli->select_db($this->name);
    $this->mySqli->query("SET NAMES 'utf8'");

  }



  private function getTables() {

    $queryTables = $this->mySqli->query('SHOW TABLES');
    while($row = $queryTables->fetch_row()) {
      $this->arrayTables[] = $row[0];
    }

  }



  private function generateSqlHeader() {

    $this->sqlString  = 'SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";' . "\r\n";
    $this->sqlString .= 'SET time_zone = "' . $this->timeZone . '";' . "\r\n\r\n\r\n";
    $this->sqlString .= '/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;' . "\r\n";
    $this->sqlString .= '/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;' . "\r\n";
    $this->sqlString .= '/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;' . "\r\n";
    $this->sqlString .= '/*!40101 SET NAMES utf8 */;' . "\r\n";
    $this->sqlString .= '--' . "\r\n";
    $this->sqlString .= '-- Database: `' . $this->name . '`' . "\r\n";
    $this->sqlString .= '--' . "\r\n\r\n\r\n";

    return;

  }



  private function createTableStaments() {

    foreach($this->arrayTables as $table){
      $this->sqlCreateTableStament($table);
    }

  }



  private function sqlCreateTableStament($table) {

    $res = $this->mySqli->query('SHOW CREATE TABLE '.$table);
    $temp = $res->fetch_row();
		$this->sqlString .= "\n\n" . str_ireplace('CREATE TABLE `','CREATE TABLE IF NOT EXISTS `', $temp[1]) . ";\n\n";

  }



  private function insertStaments() {

    foreach($this->arrayTables as $table){
      $this->sqlInsertStaments($table);
    }

  }



  private function sqlInsertStaments($table) {

		$this->getTableData($table);

    if($this->tableFieldCount == 0) {
      return;
    }


    $i = 0;
		while($row = $this->queryResult->fetch_row())	{

      $this->insertResultHeader($table, $i);
      $this->insertSingleResult($row);

      $i++;
      $this->sqlString .= (($i != 0) && ($i % 100 == 0) || ($i == $this->tableNumberOfRows)) ? ";" : ",";

		}

    $this->sqlString .= "\n\n\n";

  }



  private function getTableData($table) {

  	$this->queryResult	= $this->mySqli->query('SELECT * FROM `' . $table . '`');
    $this->tableFieldCount = $this->queryResult->field_count;
    $this->tableNumberOfRows = $this->mySqli->affected_rows;

  }



  private function insertResultHeader($table, $currentRowNumber) {

  	if ($currentRowNumber % 100 == 0 || $currentRowNumber == 0 )	{
      $this->sqlString .= "\nINSERT INTO " . $table . " VALUES";
    }

  }



  private function insertSingleResult($row) {

    $this->sqlString .= "\n(";

    for($i = 0; $i < $this->tableFieldCount; $i++){

      $row[$i] = str_replace("\n","\\n", addslashes($row[$i]));

      $this->sqlString .= (isset($row[$i])) ? '"'.$row[$i].'"' : '""';
      if($i < ($this->tableFieldCount-1)){
        $this->sqlString.= ',';
      }

    }

    $this->sqlString .=")";

  }



  private function generateSqlFooter() {

    $this->sqlString .=  "\r\n\r\n";
    $this->sqlString .=  '/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;';
    $this->sqlString .=  "\r\n";
    $this->sqlString .=  '/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;';
    $this->sqlString .=  "\r\n";
    $this->sqlString .=  '/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;';

  }



  public function downloadFile() {

      ob_get_clean();
      header('Content-Type: application/octet-stream');
      header("Content-Transfer-Encoding: Binary");
      header('Content-Length: '. (function_exists('mb_strlen') ? mb_strlen($this->sqlString, '8bit'): strlen($this->sqlString)) );
      header("Content-disposition: attachment; filename=\"".$this->fileName."\"");
    	echo $this->sqlString; exit;

  }



  public function saveToFile() {

    if (!$backupFile = fopen($this->fileDir . $this->fileName, "w+")) {
        throw new Exception('Imposible to create file.');
    }
    fwrite($backupFile, $this->sqlString);
    fclose($backupFile);

  }


}

Realizar la copia de seguridad

La solución propuesta nos proporciona dos opciones que podemos utilizar según nuestras necesidades:

1. Realizar el backup y descargarlo.
2. Realizar el backup y guardarlo en un archivo.

En ambos casos incluimos la clase y le pasaremos al método constructor los datos de la conexión a la base de datos en un array como el que ves a continuación:

include('MySqlBackup.php');

$arrayDbConf['host'] = 'dbHost';
$arrayDbConf['user'] = 'dbUser';
$arrayDbConf['pass'] = 'dbPassword';
$arrayDbConf['name'] = 'dbName';

Respaldar y descargar

Para realizar el backup y descargarlo serán suficientes unas pocas líneas:

try {

  $bck = new MySqlBackupLite($arrayDbConf);
  $bck->backUp();
  $bck->downloadFile();

}
catch(Exception $e) {

  echo $e;

}

Respaldar y guardar en un archivo

Para guardar el resultado en un archivo además deberemos de indicarle el nombre del archivo y el directorio dónde guardarlo.

try {

  $bck = new MySqlBackupLite($arrayDbConf);
  $bck->backUp();
  $bck->setFileDir('./backups/');
  $bck->setFileName('backupFileNae.sql');
  $bck->saveToFile();

}
catch(Exception $e) {

  echo $e;

}

Solo una parte del proceso

Pero en muchas situaciones, este respaldo sera solo una parte del proceso. Nosotros hemos propuesto un escenario mayor en el que clonamos nuestra web en un servidor local, en breve publicaremos el artículo.

Créditos y rerefencias

• Imagen principal: Tumisu en Pixabay.
• Solución Mysql Backup Lite: Andrés Hierro, github.