测试环境：
主节点：81.69.247.195
从节点：124.71.182.20
linux：centos6.5
主:
1.
编辑 vim /etc/my.cnf
添加：log-bin = mysql-bin
添加 :server-id =1
添加：innodb-file-per-table =ON
添加：skip_name_resolve=ON
2.
重启mysql：service mysqld restart
3.进入mysql：mysql -u root -p
4.查看二进制信息：
show global variables like '%log%';
5.查看主节点二进制日志列表
show master logs;
6.查看主节点的server id
show global variables like '%server%';
7.在主节点上创建有复制权限的用户。REPLIACTION SLAVE ，REOPLIATION CLIENT
grant replication slave,replication client on *.* to 'admin'@'124.71.182.20' identified by '123456';
8.刷新
flush privileges;
从：
1.
编辑 vim /etc/my.cnf
添加：relay-log=relay-log
添加：relay-log-index=relay-log.index
添加：server-id=2
添加：innodb_file_per_table=ON
添加：skip_name_resolve=ON
2.重启mysql：service mysqld restart
3.进入mysql：mysql -u root -p
4.查看二进制信息是否开启：
show global variables like '%log%';
5.产看server 相关信息
show global variables like '%server%';
6.在从节点配置访问主节点的参数信息
添加 主节点主机，访问主节点的用户名及密码，主节点二进制文件信息。
注意：主节点的二进制文件一定要是二进制列表中的最后一个二进制文件。
CHANGE MASTER TO MASTER_HOST='81.69.247.195',MASTER_USER='admin',MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000009',MASTER_LOG_POS=430;
7.因为没有启动 从节点的复制线程，IO线程 和 SQL 线程都为NO.
show slave status\g;
启动：start slave;
测试：
在主上创建数据库并查看二进制信息：
create database test charset 'utf8';
show master status;
在从节点查找二进制日志信息，并查看mydb数据库是否复制成功
show slave status\G;
基本命令：
stop slave;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\GProblemas que devem ser observados na arquitetura de replicação mestre-escravo:
O nó escravo deve definir certas restrições para que não possa executar operações de gravação para garantir que os dados na cópia sejam consistentes.
1: Restringir o servidor escravo para somente leitura
Definir no servidor escravo:
read_only = ON, mas esta restrição é inválida para usuários com privilégios SUPER.
Bloquear todos os usuários:
mysq> FLUSH TABLES WITH READ LOCK;
2: Como garantir a segurança das coisas durante a replicação mestre-escravo?
1: Defina o parâmetro
sync_binlog = 1 no nó mestre : Quando o Mysql abre o log bin-log e usa bin-log, por padrão, ele não é sincronizado com o disco rígido toda vez que uma gravação é executada. Isso pode causar bin-log quando o servidor falha. A última declaração do log foi perdida. Ele pode ser ajustado por este parâmetro, sync_binlog = N, para sincronizar com o disco rígido após executar N gravações. 1 é o mais seguro, mas também o mais lento.
Se o mecanismo de armazenamento innode for usado:
innodb_flush_logs_at_trx_commit = ON (log de liberação : quando a transação é confirmada, os dados relacionados à transação na memória devem ser liberados para o log de transações imediatamente.)
Innodb_support_xa = ON (transação distribuída: com base nela Execute a função de envio de dois estágios)
sync_master_info = 1: Sempre que depois de despejar alguma informação de evento no nó escravo, a informação de informação mestre do nó mestre será imediatamente sincronizada com o disco. Deixe o master_info no servidor escravo ser atualizado a tempo.
2: Em cada nó escravo
skip_slave_start = ON (Pule o início automático, use o início manual.) O
relay_log será armazenado em cache nele primeiro e, em seguida, sincronizado com o relay_log, você pode usar os seguintes parâmetros para torná-lo sincronizado imediatamente.
sync_relay_log = 1, o padrão é 10.000, ou seja, cada 10.000 eventos sync_relay_log serão descarregados para o disco. Se for 0, significa que não há atualização e é controlado pelo cache do sistema operacional.
sync_relay_log_info = 1 Quantas transações atualizam relay-log.info a cada intervalo , se a configuração da tabela (innodb) for inválida, todas as transações serão atualizadas
Nota: No nó escravo, master.info é um arquivo gravado no local da cópia do nó mestre.
relylog_info: Localmente, no futuro, para saber qual arquivo binário do nó mestre irá posicionar e qual posição em qual relay log salvar o texto. Quando o nó escravo é iniciado, o relay-log local precisa ser localizado de acordo com relay-log.info.
