De acuerdo con la Guía de estudio de certificación MySQL 5.0 , el Capítulo 32, Sección 32.3.4, Páginas 456,457, describe las Condiciones para la portabilidad binaria que resaltan lo siguiente:
La portabilidad binaria es importante si desea tomar una copia de seguridad binaria realizada en una máquina y utilizarla en otra máquina que tenga una arquitectura diferente. Por ejemplo, usar una copia de seguridad binaria es una forma de copiar bases de datos de un servidor MySQL a otro.
Para MyISAM, la portabilidad binaria significa que puede copiar directamente los archivos para una tabla MyISAM de un servidor MySQL a otro en una máquina diferente y el segundo servidor podrá acceder a la tabla.
Para InnoDB, la portabilidad binaria significa que puede copiar directamente los archivos de espacio de tabla de un servidor MySQL en una máquina a otro servidor en una máquina diferente y el segundo servidor podrá acceder al espacio de tabla. De forma predeterminada, todas las tablas de InnoDB administradas por un servidor se almacenan juntas en el espacio de tablas, por lo que la portabilidad del espacio de tablas depende de si todas las tablas individuales de InnoDB son portátiles. Si incluso una tabla no es portátil, tampoco lo es el espacio de tabla.
Las tablas MyISAM y los espacios de tablas InnoDB son portátiles binarios de un host a otro si se cumplen dos condiciones:
- Ambas máquinas deben usar aritmética de enteros con dos complementos
- Ambas máquinas deben usar el formato de punto flotante IEEE o las tablas no deben contener columnas de punto flotante (FLOTANTE o DOBLE)
En la práctica, esas dos condiciones plantean poca restricción. La aritmética de enteros con dos complementos y el formato de coma flotante IEEE son la norma en el hardware moderno. Una tercera condición para la portabilidad binaria de InnoDB es que debe usar nombres en minúsculas para tablas y bases de datos. Esto se debe a que InnoDB almacena estos nombres internamente (en su diccionario de datos) en minúsculas en Windows. El uso de nombres en minúsculas permite la portabilidad binaria entre Windows y Unix, para forzar el uso de nombres en minúsculas, puede poner las siguientes líneas en un archivo de opciones:
[mysqld]
lower_case_table_names=1
Si configura InnoDB para usar espacios de tabla por tabla, las condiciones para la portabilidad binaria se extienden para incluir también los archivos .ibd para las tablas de InnoDB. (Las condiciones para los espacios de tabla compartidos todavía se aplican porque contiene el diccionario de datos que almacena información sobre todas las tablas de InnoDB).
Si no se cumplen las condiciones para la portabilidad binaria, puede copiar las tablas MyISAM o InnoDB de un servidor a otro descargándolas utilizando algún formato de texto (por ejemplo, con mysqldump) y volviéndolas a cargar en el servidor de destino.
Hay dos formas principales basadas en el motor de almacenamiento para mover tablas individuales.
Para el ejemplo dado, supondremos lo siguiente:
- datadir es / var / lib / mysql
- base de datos llamada mydb
- tabla en la base de datos mydb llamada mytable .
Mesas MyISAM
Si mydb.mytable usa el motor de almacenamiento MyISAM, la tabla se manifestará físicamente como tres archivos separados
- /var/lib/mysql/mydb/mytable.frm (archivo .frm)
- /var/lib/mysql/mydb/mytable.MYD (archivo .MYD)
- /var/lib/mysql/mydb/mytable.MYI (archivo .MYI)
.Frm contiene la estructura de la tabla
.MYD contiene los datos de la tabla
.MYI contiene la página de índice de la tabla
Estos archivos se usan de forma interdependiente para representar la tabla desde un punto de vista lógico en mysql. Dado que estos archivos no tienen ninguna asociación lógica adicional adjunta, migrar una tabla de un servidor DB a otro. Incluso puede hacerlo desde un servidor Windows a un servidor Linux o MacOS. Por supuesto, puede cerrar mysql y copiar los 3 archivos de la tabla. Podrías ejecutar lo siguiente:
LOCK TABLES mydb.mytable READ;
SELECT SLEEP(86400);
UNLOCK TABLES;
en una sesión ssh para mantener la tabla como solo lectura y mantener el bloqueo durante 24 horas. Un segundo después, realice la copia en otra sesión ssh. Luego, elimine la sesión de mysql con el bloqueo de 24 horas. No necesitas esperar 24 horas.
Tablas InnoDB
Según la cita del libro de certificación mencionada anteriormente, hay muchos factores que rigen cómo hacer una copia de seguridad de una tabla InnoDB específica. En aras de la simplicidad, la claridad y la brevedad, simplemente realice un mysqldump de la tabla deseada utilizando los parámetros de transacción única para tener un volcado perfecto de la tabla en un momento determinado. No es necesario darse el gusto con la semántica de InnoDB si solo desea una tabla. Puede volver a cargar ese archivo de volcado en cualquier servidor MySQL que elija.
Dado que dos preguntas se fusionaron aquí (jcolebrand): EDITAR
Si está más que dispuesto a vivir con un rendimiento de base de datos lento, puede realizar una serie de rsyncs desde el antiguo servidor (ServerA) al nuevo servidor (ServerB) incluso mientras mysql todavía se está ejecutando en ServerA.
Paso 01) instale la misma versión de mysql en ServerB que ServerA tiene
Paso 02) En ServerA, ejecute SET GLOBAL innodb_max_dirty_pages_pct = 0;desde mysql y aproximadamente 10 minutos (Esto purga páginas sucias del InnoDB Buffer Pool. También ayuda a realizar un apagado de mysql más rápido) Si su base de datos es todo MyISAM, puede omitir este paso.
Paso 03) rsync --archive --verbose --stats --partial --progress --human-readable ServerA:/var/lib/mysql ServerB:/var/lib/mysql
Paso 04) Repita el Paso 03 hasta que un rsync tome menos de 1 minuto
Paso 05) service mysql stopen el ServidorA
Paso 06) Realice un rsync más
Paso 07) scp ServerA:/etc/my.cnf ServerB:/etc/
Paso 08) service mysql starten ServerB
Paso 08) service mysql starten el servidor A (opcional)
Darle una oportunidad !!!
CONSIDERACIÓN
Puede crear un esclavo de replicación como este. Solo recuerde tener el ID de servidor establecido explícitamente en el maestro /etc/my.cnf y un número diferente para el ID de servidor en el esclavo /etc/my.cnf