一、配置主从服务器的好处
好处一：实现服务器负载均衡
通过服务器复制功能，可以在主服务器和从服务器之间实现负载均衡。即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户相应时间。通常情况下，数据库管理员会有两种思路。
一是在主服务器上只实现数据的更新操作。包括数据记录的更新、删除、新建等等作业。而不关心数据的查询作业。数据库管理员将数据的查询请求全部 转发到从服务器中。这在某些应用中会比较有用。如某些应用，像基金净值预测的网站。其数据的更新都是有管理员更新的，即更新的用户比较少。而查询的用户数 量会非常的多。此时就可以设置一台主服务器，专门用来数据的更新。同时设置多台从服务器，用来负责用户信息的查询。将数据更新与查询分别放在不同的服务器 上进行，即可以提高数据的安全性，同时也缩短应用程序的响应时间、提高系统的性能。
二是在主服务器上与从服务器切分查询的作业。在这种思路下，主服务器不单单要完成数据的更新、删除、插入等作业，同时也需要负担一部分查询作 业。而从服务器的话，只负责数据的查询。当主服务器比较忙时，部分查询请求会自动发送到从服务器重，以降低主服务器的工作负荷。当然，像修改数据、插入数据、删除数据等语句仍然会发送到主服务器中，以便主服务器和从服务器数据的同步。
要在数据库之间实现负载的均衡，其关键点就是数据同步的时间。如果主服务器与从服务器之间数据的更新时间比较长，此时从主服务器中查询得到的数 据就会同从从服务器中得到的数据有差异。而如果同步的时间比较短，如实现同步复制，对网络带宽、服务器设备等就有比较高的要求。
可见这个同步的时间选择直接关系到其应用的效果。那么这个同步的时间应该选择多少呢?这没有一个固定的答案。主要是看用户的需要。如用户对数据 的及时性要求并不是很高，或者数据更新的频率不是很高，那么这个同步的时间可以稍微长一点。但是如果这个数据的及时性要求很高，如股票的价格等等，此时就 需要能够实现同步更新。所以具体要看企业实际的应用才能够决定采用什么样的同步时间。
在采取这个应用时，需要注意MySQL数据库的复制是单向的。即只能够将数据从主服务器复制到从服务器，而不能够将数据从从服务器发生到主服务 器。这也就是说，数据库管理员不能够在从服务器上更新数据，否则的话，就可能会与主服务器上的数据产生冲突。默认情况下，系统会自动利用主服务器上的数据 来更新从服务器上的数据。即在从服务器上所做的任何更改，到时候都会失效。如果是用户的请求，一般不用担心。系统会自动判断用户的请求是查询请求还是数据 更新请求。并自动根据请求的类型转发到不同的服务器上。主要是数据库管理员，不要手痒痒，手动去更新从服务器上的数据。否则的话，就会导致从服务器与主服 务器之间数据的冲突。
好处二：通过复制实现数据的异地备份
如上图所示，可以定期的将数据从主服务器上复制到从服务器上，这无疑是先了数据的异地备份。在传统的备份体制下，是将数据备份在本地。此时备份 作业与数据库服务器运行在同一台设备上，当备份作业运行时就会影响到服务器的正常运行。有时候会明显的降低服务器的性能。同时，将备份数据存放在本地，也 不是很安全。如硬盘因为电压等原因被损坏或者服务器被失窃，此时由于备份文件仍然存放在硬盘上，数据库管理员无法使用备份文件来恢复数据。这显然会给企业 带来比较大的损失。
而如果使用复制来实现对数据的备份，就可以在从服务器上对数据进行备份。此时不仅不会干扰主服务气的正常运行，而且在备份过程中主服务器可以继 续处理相关的更新作业。同时在数据复制的同时，也实现了对数据的异地备份。除非主服务器和从服务器的两块硬盘同时损坏了，否则的话数据库管理员就可以在最 短时间内恢复数据，减少企业的由此带来的损失。
在通过这种方式进行异地备份时，主要需要注意如下二个细节：
一是数据更新的时间。如果要采取这种方式进行备份，那么对于数据同步的时间，要小于等于数据备份的周期。只有如此，才能够确保最近更新的数据被正确的备份。此时即使主服务器出现了故障，用户丢失的也只是最近一个备份周期的数据。
二是从服务器上硬盘的空间。根据一般用户的心态，从服务器的配置往往比主服务器要低。但是现在从服务器要承担起数据备份的任务，为此对于硬盘的 空间要求就要比主服务器要高。其不但要能够存储主服务器上的数据，而且还要对其进行备份。为此一般要求，从服务器上的存储空间是主服务器上的两倍。否则的 话，就容易出现磁盘空间不足而导致备份作业失败。
好处三：提高数据库系统的可用性
数据库复制功能实现了主服务器与从服务器之间数据的同步，增加了数据库系统的可用性。当主服务器出现问题时，数据库管理员可以马上让从服务器作为主服务器，用来数据的更新与查询服务。然后回过头来再仔细的检查主服务器的问题。此时一般数据库管理员也会采用两种手段。
一是主服务器故障之后，虽然从服务器取代了主服务器的位置，但是对于主服务器可以采取的操作仍然做了一些限制。如仍然只能够进行数据的查询，而 不能够进行数据的更新、删除等操作。这主要是从数据的安全性考虑。如现在一些银行系统的升级，在升级的过程中，只能够查询余额而不能够取钱。这是同样的道 理。
二是从服务器真正变成了主服务器。当从服务器切换为主服务器之后，其地位完全与原先的主服务器相同。此时可以实现对数据的查询、更新、删除等操 作。为此就需要做好数据的安全性工作。即数据的安全策略，要与原先的主服务器完全相同。否则的话，就可能会留下一定的安全隐患。
二、Mysql主从方案介绍
Master的配置
在Linux环境下MySQL的配置文件的位置是在 /etc/my.cnf ，在该文件下指定Master的配置如下：
log-bin=mysql-bin
server-id=2
binlog-ignore-db=information_schema
binlog-ignore-db=cluster
binlog-ignore-db=mysql
binlog-do-db=ufind_db
server-id：用于标识唯一的数据库，这里设置为2，在设置从库的时候就需要设置为其他值。
binlog-ignore-db：表示同步的时候ignore的数据库
binlog-do-db：指定需要同步的数据库
完整配置截图如下：
1、重启mysql：service mysqld restart
2、进入mysql：[root@VM_221_4_centos ~]# mysql -u root -p 回车，输入mysql密码进入。
3、 赋予从库权限帐号，允许用户在主库上读取日志，赋予192.168.1.2也就是Slave机器有File权限，只赋予Slave机器有File权限还不行，还要给它REPLICATION SLAVE的权限才可以。
在Master数据库命令行中输入：
>GRANT REPLICATION SLAVE ON *.* TO 'root'@'192.168.1.2' IDENTIFIED BY 'mysql password';
>FLUSH PRIVILEGES
这里使用的仍是 root 用户作为同步的时候使用到的用户，可以自己设定。
4、重启mysql，登录mysql，显示主库信息
mysql> show master status;
+------------------+----------+--------------+----------------------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+----------------------------------+-------------------+| mysql-bin.000004 | 28125 | ufind_db | information_schema,cluster,mysql | |
+------------------+----------+--------------+----------------------------------+-------------------+
1 row in set (0.00 sec)
mysql>
这里的 File 、Position 是在配置Salve的时候要使用到的，Binlog_Do_DB表示要同步的数据库，Binlog_Ignore_DB 表示Ignore的数据库，这些都是在配置的时候进行指定的。
另外：如果执行这个步骤始终为Empty set(0.00 sec)，那说明前面的my.cnf没配置对。
Slave的配置
1、从库的配置，首先也是修改配置文件：/etc/my.cnf 如下：
log-bin=mysql-bin
server-id=3
binlog-ignore-db=information_schema
binlog-ignore-db=cluster
binlog-ignore-db=mysql
replicate-do-db=ufind_db
replicate-ignore-db=mysqllog-slave-updates
slave-skip-errors=all
slave-net-timeout=60
2、修改完/etc/my.cnf 文件之后，重启一下MySQL（service mysqld restart）
进入Slave mysql控制台，执行：
mysql> stop slave; #关闭Slave
mysql> change master to master_host='192.168.1.1',master_user='root',master_password='123456',master_log_file='mysql-bin.000004', master_log_pos=28125;
mysql> start slave; #开启Slave
在这里指定Master的信息，master_log_file是在配置Master的时候的File选项， master_log_pos是在配置Master的Position 选项，这里要进行对应。
然后可以通过mysql> show slave status; 查看配置的信息：
mysql> show slave status \G;*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.167.1.1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 28125
Relay_Log_File: VM_128_194_centos-relay-bin.000004
Relay_Log_Pos: 26111
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: ufind_db
Replicate_Ignore_DB: mysql
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: 28125
Relay_Log_Space: 26296
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: 2
Master_UUID: 8ac3066a-9680-11e5-a2ec-5254007529fd
Master_Info_File: /data/mysqldb/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
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: 01 row in set (0.00 sec)
ERROR:
No query specified
mysql>
可以看到，已经配置成功。