De acordo com o Guia de Estudo de Certificação do MySQL 5.0 , Capítulo 32, Seção 32.3.4, Páginas 456.457, descreve as Condições de Portabilidade Binária que trazem o seguinte:
A portabilidade binária é importante se você deseja fazer um backup binário feito em uma máquina e usá-lo em outra máquina com arquitetura diferente. Por exemplo, usar um backup binário é uma maneira de copiar bancos de dados de um servidor MySQL para outro.
Para o MyISAM, portabilidade binária significa que você pode copiar diretamente os arquivos de uma tabela MyISAM de um servidor MySQL para outro em uma máquina diferente e o segundo servidor poderá acessar a tabela.
Para o InnoDB, portabilidade binária significa que você pode copiar diretamente os arquivos do espaço de tabela de um servidor MySQL em uma máquina para outro servidor em uma máquina diferente e o segundo servidor poderá acessar o espaço de tabela. Por padrão, todas as tabelas do InnoDB gerenciadas por um servidor são armazenadas juntas no espaço de tabela; portanto, a portabilidade do espaço de tabela depende da capacidade de todas as tabelas individuais do InnoDB serem portáteis. Se mesmo uma tabela não for portátil, o espaço de tabela também não será.
As tabelas MyISAM e os espaços de tabela do InnoDB são portáteis binárias de um host para outro, se duas condições forem atendidas:
- Ambas as máquinas devem usar aritmética de número inteiro com dois complemento
- Ambas as máquinas devem usar o formato de ponto flutuante IEEE ou as tabelas não devem conter colunas de ponto flutuante (FLOAT ou DOUBLE)
Na prática, essas duas condições apresentam pouca restrição. A aritmética de número inteiro com complemento de dois e o formato de ponto flutuante IEEE são a norma no hardware moderno. Uma terceira condição para a portabilidade binária do InnoDB é que você use nomes em minúsculas para tabelas e bancos de dados. Isso ocorre porque o InnoDB armazena esses nomes internamente (em seu dicionário de dados) em minúsculas no Windows. O uso de nomes em minúsculas permite a portabilidade binária entre o Windows e o Unix. Para forçar o uso de nomes em minúsculas, você pode colocar as seguintes linhas em um arquivo de opções:
[mysqld]
lower_case_table_names=1
Se você configurar o InnoDB para usar espaços de tabela por tabela, as condições de portabilidade binária serão estendidas para incluir os arquivos .ibd das tabelas do InnoDB também. (As condições para os espaços de tabela compartilhados ainda se aplicam porque contém o dicionário de dados que armazena informações sobre todas as tabelas do InnoDB.)
Se as condições de portabilidade binária não forem satisfeitas, você pode copiar as tabelas MyISAM ou InnoDB de um servidor para outro despejando-as usando algum formato de texto (por exemplo, com mysqldump) e recarregando-as no servidor de destino.
Existem duas maneiras principais, com base no mecanismo de armazenamento, de mover tabelas individuais.
Para o exemplo dado, vamos supor o seguinte:
- datadir é / var / lib / mysql
- banco de dados chamado mydb
- tabela no banco de dados mydb chamada mytable .
Tabelas MyISAM
Se mydb.mytable usar o mecanismo de armazenamento MyISAM, a tabela será manifestada fisicamente como três arquivos separados
- /var/lib/mysql/mydb/mytable.frm (arquivo .frm)
- /var/lib/mysql/mydb/mytable.MYD (arquivo .MYD)
- /var/lib/mysql/mydb/mytable.MYI (arquivo .MYI)
O .frm contém a estrutura da tabela.
O .MYD contém os dados da tabela.
O .MYI contém a página de índice da tabela
Esses arquivos são usados interdependentemente para representar a tabela do ponto de vista lógico no mysql. Como esses arquivos não têm mais associação lógica anexada, migrando uma tabela de um servidor de banco de dados para outro. Você pode até fazer isso de um servidor Windows para um servidor Linux ou um MacOS. Obviamente, você pode desligar o mysql e copiar os 3 arquivos de tabela. Você pode executar o seguinte:
LOCK TABLES mydb.mytable READ;
SELECT SLEEP(86400);
UNLOCK TABLES;
em uma sessão ssh para manter a tabela como somente leitura e manter a trava por 24 horas. Um segundo depois, execute a cópia em outra sessão ssh. Então mate a sessão do mysql com o bloqueio de 24 horas. Você não precisa esperar 24 horas.
Tabelas InnoDB
Com base na citação acima mencionada no livro Certificação, existem muitos fatores que determinam como fazer backup de uma tabela específica do InnoDB. Por uma questão de simplicidade, clareza e concisão, basta executar um mysqldump da tabela desejada usando os parâmetros --single-transaction para obter um despejo perfeito da tabela em um determinado momento. Não há necessidade de se preocupar com a semântica do InnoDB se você quiser apenas uma tabela. Você pode recarregar esse arquivo de despejo em qualquer servidor MySQL de sua escolha.
Como duas perguntas foram mescladas aqui (jcolebrand): EDIT
Se você estiver disposto a viver com um desempenho lento do banco de dados, poderá executar uma série de rsyncs do servidor antigo (ServerA) para o novo servidor (ServerB), mesmo enquanto o mysql ainda estiver em execução no ServerA.
Etapa 01) instale a mesma versão do mysql no ServerB que o ServerA possui
Etapa 02) No ServerA, execute o SET GLOBAL innodb_max_dirty_pages_pct = 0;
mysql e aproximadamente 10 minutos (Isso remove páginas sujas do InnoDB Buffer Pool. Também ajuda a executar um desligamento do mysql mais rapidamente) Se o seu banco de dados for todo MyISAM, você pode pular esta etapa.
Etapa 03) rsync --archive --verbose --stats --partial --progress --human-readable ServerA:/var/lib/mysql ServerB:/var/lib/mysql
Etapa 04) Repita a Etapa 03 até que um rsync leve menos de 1 minuto
Etapa 05) service mysql stop
no ServerA
Etapa 06) Execute mais um rsync
Etapa 07) scp ServerA:/etc/my.cnf ServerB:/etc/
Etapa 08) service mysql start
no ServerB
Etapa 08) service mysql start
no ServerA (opcional)
De uma chance !!!
EMBARGO
Você pode criar um escravo de replicação como este. Lembre-se de definir o ID do servidor explicitamente no master /etc/my.cnf e um número diferente para o id do servidor no slave /etc/my.cnf