MySQL 是企业运用程序中利用最多的SQL数据库之一，其能够管理事务和内核中的ACID行为，且数据库本身的利用及干系命令的利用都很便利。
在开源Web运用程序框架LAMP(包括Linux，Apache，MySQL和PHP)中，MySQL做事器是一个核心和主要的组件。MySQL数据库做事器利用C和C ++编写的，内部利用词法剖析器来解析和理解SQL查询。
随着系统变得分散、可扩展且高度容错时，我们越来越无法承受数据库中的故障，例如数据库做事器发生故障且无法自动管理。以是，本文就将和大家谈论一下数据库复制。
当系统的MySQL数据库发生故障，利用数据库复制我们可以转移到其副本并从中管理数据，乃至用户都感知不到数据库中发生了缺点。不同的企业利用数据库复制的初衷包括但不限于以下缘故原由：
确保直接从数据库备份数据在不滋扰主数据库的情形下运行剖析或检讨数据扩展数据库以得到更好的性能2. MySQL设置
我们创建了两个具有不同IP的新做事器，在副本集中将其分别用作主理事器和从做事器。为了进一步研究，我们在它们上面设置了MySQL做事器和客户端工具。
安装MySQL做事器和客户端：
sudo apt-get install mysql-server mysql-client
运行此命令后，做事器上即安装了上述程序，然后在两台做事器上进行相同的配置并设置MySQL root密码：
设置Root密码
安装过程完成后，利用以下命令确认MySQL做事器是否已启动并运行：
sudo service mysql status
输出：
检讨MySQL做事器状态
MySQL做事器已启动并运行，利用在安装过程中的用户名和密码连接。
登录MySQL
mysql -u root -p
此时，MySQL做事器会等待我们输入密码，出于安全考虑，密码不会回显给终端。登录MySQL命令行后，会涌现以下提示：
MySQL登录
进入MySQL命令提示符时，我们可以利用给定的命令来显示系统中存在的数据库并确保MySQL运行正常：
显示所有数据库
show databases;
输出：
检讨MySQL数据库
在输出中，MySQL只显示用于管理目的的MySQL默认数据库列表。只要在两台做事器上看到Active状态，我们就可以连续进行Master和Slave数据库的配置。
3.节制MySQL做事器配置
MySQL安装完之后，我们就可以进行master数据库的配置，即在主MySQL配置文件中添加配置，在Ubuntu上利用nano编辑器打开并实行以下命令：
编辑配置文件
sudo nano /etc/mysql/mysql.conf.d/my.cnf
该文件包含许多选项，利用它们可以修正和配置在系统上运行的MySQL做事器的行为。首先，我们须要在文件中找到bind-address属性：
绑定地址属性
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
将此IP修正为当前做事器IP：
更新Bind Address属性
bind-address = <server_ip_here>
查看server-id属性：
做事器ID属性
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
更新做事器ID属性
server-id = 1
log_bin属性关照实际保存副本集详细信息的文件。
Log Bin属性
log_bin = /var/log/mysql/mysql-bin.log
在这个文件中，从做事器记录它从主数据库中容纳的变革。现在我们将取消对属性的注释，编辑binlog_do_db属性，该属性关照从数据库做事器在从数据库中复制哪个数据库。我们可以通过对我们须要的所有数据库重复此行来包含多个数据库：
DB备份：
binlog_do_db = jcg_database
配置文件中显示的更新属性：
更新了配置文件
完成所有属性后，我们可以保存文件并重新启动MySQL做事器，以便这些更新反响在做事器中。要重新启动MySQL做事器，请运行以下命令：
重启MySQL：
sudo service mysql restart
一旦MySQL做事看重新启动，我们须要做的下一个变动是在MySQL shell本身内部。再次登录MySQL命令行。
授权给Slave DB，以便它可以访问和复制我们在配置文件中提到的数据库中的数据jcg_database。
付与权限
GRANT REPLICATION SLAVE ON . TO 'root'@'%' IDENTIFIED BY 'password';
刷新权限：
FLUSH PRIVILEGES;
切换到创建之后要复制的数据库：
mysql> CREATE SCHEMA jcg_database;
Query OK, 1 row affected (0.00 sec)
mysql> USE jcg_database;
Database changed
锁天命据库，禁止变动：
Read Lock：
FLUSH TABLES WITH READ LOCK;
在运用锁之前，我们须要制订一些新表并插入数据。
检讨主状态
SHOW MASTER STATUS;
输出：
主数据库状态
须要把稳的是，由于这是从属DB开始复制数据库的位置。如果我们对DB进行任何变动，它将自动解锁，以是不要在同一窗口中进行任何新的变动。下一部分有点棘手，打开一个新的终端窗口或选项卡(不关闭当前选项卡)并登录MySQL做事器并实行以下命令：
转储MySQL
mysqldump -u root -p --opt jcg_database > jcg_database.sql
输出：
MySQL转储
退出单独打开的新选项卡并返回到旧选项卡。在该选项卡上，解锁数据库并退出MySQL：
解锁并退出
UNLOCK TABLES;
QUIT;
如此，我们就完成了在master数据库上所需的所有配置。
4.从属MySQL做事器配置
现在，我们准备开始配置复制数据的从数据库，登录Slave做事器并在个中打开MySQL命令行。创建一个具有相同名称的数据库，复制并退出MySQL终端：
MySQL Slave DB
利用我们制作的SQL文件将原始数据库导入Slave MySQL做事器，确保将该文件带到此新做事器上并运行以下命令将其导入到从属MySQL数据库中：
导入数据库
mysql -u root -p jcg_database < /root/jcg_database.sql
点击Enter后，数据库内容和元数据将导入从数据库。完成之后，我们也可以配置Slave MySQL DB：
配置DB
nano /etc/mysql/mysql.conf.d/mysqld.cnf
我们须要确保此配置文件中的某些属性已设置，server-id设置的默认值为1，也可利用下面命令设置为其它值：
这个财产是server-id。它当前设置为1，这是默认值。将其设置为其他值：
Server ID for Slave
server-id = 2
Slace的其他属性设置：
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = jcg_database
添加relay-log属性，由于默认情形下它不在配置文件中。完成此操作后，还须要重新启动Slave MySQL DB，配置变动才能生效。
重启MySQL
sudo service mysql restart
一旦MySQL做事看重新启动，我们须要做的下一个变动是在MySQL shell本身内部。以是再次登录MySQL命令行。
在MySQL shell中，实行以下命令：
启用复制
CHANGE MASTER TO MASTER_HOST='<master-server-ip>',MASTER_USER='root', MASTER_PASSWORD='hello123', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS= 1306;
此命令一次完成各个步骤，包括：
关照当前MySQL做事器，它是给定的MySQL主理事器的Slave为Slave供应了Master Server的登录凭据关照Slave须要启动复制过程的位置以及日志文件详细信息利用以下命令终极激活从做事器：
激活MySQL Slave Server
START SLAVE;
利用以下命令查看一些紧张细节：
MySQL主状态
SHOW SLAVE STATUS\G;
输出：
MySQL主状态信息
mysql> SHOW SLAVE STATUS\G;
1. row
Slave_IO_State: Waiting for master to send event
Master_Host: 206.189.133.122
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 1306
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1306
Relay_Log_Space: 527
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 3b890258-be5d-11e8-88c2-422b77d8526c
Master_Info_File: /var/lib/mysql/master.info
Slave_SQL_Running_State: Slave has read all relay log;
waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
如果在连接时涌现问题，可以考试测验利用命令启动slave：
MySQL主状态
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; SLAVE START;
这样，我们就完成了MySQL复制的配置，数据正在MySQL做事器上复制，并考试测验将一些数据插入Master数据库，并检讨数据是否也复制到从数据库。
5.复制滞后
MySQL复制利用两个线程来完成主数据库和从属数据库之间的复制：
1. IO_THREAD
2. SQL_THREAD
IO_THREAD连接到主MySQL做事器，读取二进制日志以跟踪和变动数据库中的事宜，将它们复制到本地中继日志文件，Slave数据库的SQL_THREAD读取并跟踪变动，将它们复制到Slave数据库。
如果我们不雅观察到任何复制延迟，首先要确定此延迟是来自Slave的IO_THREAD还是Slave的SQL_THREAD。
常日，I / O线程不会导致任何重大的复制延迟，由于它只是从主数据库读取二进制日志，但有些成分会影响其性能，如网络连接，网络延迟以及通信网络的速率等等。如果Master上存在大量写入，由于带宽问题，复制可能会很慢。
另一方面，如果SQL线程在Slave延迟了，那么最可能的缘故原由是主数据库的SQL查询须要在Slave数据库实行实行较永劫光。其余， MySQL 5.6之前slave是单线程的，这也是导致从属SQL_THREAD延迟的另一个缘故原由。
6.复制的优点
MySQL复制在生产环境中具备一些明显上风：
性能：Slave做事器可以很随意马虎地用于向任何要求数据的客户端供应READ支持。这意味着Master数据库上的负载会减少很多，由于没有对它进行读取。备份性能：如果有任何运行的备份任务，则可以在复制数据时通过Slave数据库运行它。这意味着备份作业根本不会影响Master数据库。灾害规复：在Master数据库完备脱机的事宜中，如果以这种办法配置，Slave数据库可以快速取代它并开始实行写操作。这将许可在重修和规复主理事器时最小的站点停机韶光。7.复制的缺陷
从上文看下来，MySQL Replication是很不错的，但是它也有很多缺陷：
繁芜性：如果管理禁绝确，具有大量Slave进行复制的运用程序可能会造成掩护噩梦。性能：要完成复制过程，须要将二进制日志写入磁盘，只管它的影响可能很小，但是在查看整体做事器性能时仍须要考虑。可以通过将二进制日志写入磁盘的单独分区来办理，以限定IO性能问题。8.复制的局限性
除了上述内容，还有一些数据复制的限定点须要解释：
复制不是运用程序逻辑的备份，并且在Master数据库上实行的任何变动将始终复制到Slave数据库，并且不能限定它。如果用户删除master数据库上的数据，它也将在Slave数据库中删除。在多个Slaves的情形下，性能不会增加，反而会降落，由于数据库连接分布在多个做事器上，并且在任何做事器发生故障时涌现问题的风险都会增加。9. MySQL复制的类型
从实质上讲，MySQL支持三种不同的方法将数据从主理事器复制到从属做事器。所有这些方法都利用二进制日志，但它与日志的写入办法不同。以下是复制的方法：
基于语句的复制：利用此方法，数据库中每次变动的SQL语句都存储在二进制日志文件中。从属设备将读取这些SQL语句并在自己的MySQL数据库上实行它们，以便从主理事器天生完备相同的数据副本。这是MySQL 5.1.11和MySQL 5.1.29中的默认复制方法。基于行的复制：在此方法中，二进制日志文件存储主数据库表中发生的所有记录级变动。从做事器读取此数据并根据主数据更新其自己的记录，以天生主数据库的精确副本。稠浊格式复制：在此方法中，做事器将在基于语句的复制和基于行的复制之间动态选择，详细取决于某些条件，如利用用户定义的函数(UDF)，利用带DELAYED子句的INSERT命令，临时表，或利用利用系统变量的语句。这是MySQL 5.1.12到MySQL 5.1.28中的默认复制方法。在用例中，当你不愿定要利用哪种复制方法时，最好利用基于语句的复制，由于它是最常用和最大略的实行办法。如果你有一个写入繁重的系统，则不建议利用基于语句的复制，由于它也运用表锁。在这种情形下，可以利用基于行的复制方法。
10.对古迹的影响
如前所述，复制可能会影响数据库的性能，但与其他事情比较，复制对主理事器的影响常日非常小，由于master只须要在复制环境中完成两件主要事情：
制订事宜并将事宜写入本地硬盘驱动器上的二进制日志将它写入二进制日志的每个事宜副本发送给每个连接的从站纵然没有复制，二进制日志也是要始终打开的，以是在考虑复制本钱时也不须要列入二进制日志。
其余，复制事宜发送到从设备的本钱也可以忽略不计，由于从设备卖力掩护与主设备的持久TCP连接，主设备只需在事宜发生时将数据复制到套接字上。除此之外，主设备丝毫不关心从设备是否或得当实行。
末了一条语句的部分非常是半同步复制，这不是默认值。在这种模式下，主理事器等待至少一个从做事器确认来自每个事务的二进制日志事宜的吸收和持久存储(只管不是实际实行)，然后主理事器在每次提交时将掌握权返回给客户端。
在任何情形下，主理事器都不卖力实际实行从做事器上的更新，它只向从做事器发送两件事：运行的实际输入查询的副本(基于语句的模式)或数据对付每个查询实际插入/更新/删除的行(在基于行的模式下)。在稠浊模式下，查询优化器将决定在每个事宜的根本上利用哪种格式。
11. 综述MySQL复制
在确保生产系统运行时具有故障转移可靠性使其成为容错系统时，MySQL Replication是一个很好的选择，同时这也是当今分布式和高可用系统必须具备的。
本文向大家先容了在单个从属做事器上复制数据须要进行的主要的配置变动、系统变动。当然，由于主理事器上没有和从做事器干系或绑定的配置，以是我们可以在不影响主理事器的情形下设置任意数量的从做事器。
