个人认为,90%的公司的数据体量和并发量压根用不上从服务器,结合Redis,一台性能强劲的云MySQL服务器,做好日常备份。足够了。
概念
一个MySQL主(Master)服务器上的数据自动复制到至少一个的MySQL从(Slave)服务器的过程,利用bin log,主服务器上的数据更改会被自动地同步到从服务器,以保持至少两个服务器上数据的一致性。
注意:客户端请求MySQL Server,写主还是写从,读主还是读从,决定权在客户端。
解决了什么问题?
- 负载均衡:一台机器读写可能扛不住,多个服务器过来帮忙,主负责写,从负责读。
- 读写分离:起到了数据备份的作用,鸡蛋不要放到一个篮子里。
- 高可用性:一台服务器宕机,可切换到另一台服务器上,提供继续服务的能力。
缺点
- 增加运维复杂度。
- 无法保证主从实时通信,可能出现数据不一致的情况。
主从通信推还是拉?
拉,通过从机上配置主机的IP就能看出来,如果是推,则是主机上配置从机IP。
主服务器主动请求从服务器或推送,这是推。
从服务器主动请求主服务器,这是拉。
配置一主一从
mysql有大量的可选主从的配置,很多不一定能用上,具体可查看MySQL官网:dev.mysql.com/doc/refman/…
最好先ping对方的服务器,能互相ping通,说明可通信。
防火墙开启3306端口:
firewall-cmd --zone=public --add-port=3306/tcp --permanent && systemctl restart firewalld
主服务器配置
#主服务器id
server-id=180
#bin log日志名称
log-bin=mysql-bin
#需要从机复制的数据库名
binlog-do-db=test
从服务器配置
#从服务器id
server-id=181
#设置只读
read-only=1
mysql5.7及以下版本,在主服务器上执行一下MySQL指令
grant replication slave on *.* to '从服务器用户名'@'从服务器IP' identified by '从服务器密码';
mysql8,在主服务器上执行一下MySQL指令
create user '从机用户名'@'%' identified by '从机密码';
grant replication slave on *.* to '从机用户名'@'%';
alter user '从机用户名'@'%' identified with mysql_native_password by '从机密码';
flush privileges;
主机执行
show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000032 | 157 | test | | |
+------------------+----------+--------------+------------------+-------------------+
在从机执行
change master to master_host='主机IP',master_user='主机创建的从机用户名',master_password='主机创建的从机密码',master_log_file='主机执行show master status的bin log名称',master_log_pos=主机执行show master status的position值;
在从机执行
start slave;
在从机执行:
show slave status;只要发现Slave_IO_Running : Yes和Slave_SQL_Running : Yes;就说明配置完成。
*************************** 1. row ***************************
Slave_IO_State: Waiting for source to send event
Master_Host: 192.168.3.180
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000032
Read_Master_Log_Pos: 157
Relay_Log_File: lnmp-relay-bin.000002
Relay_Log_Pos: 326
Relay_Master_Log_File: mysql-bin.000032
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: 157
Relay_Log_Space: 535
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: 180
Master_UUID: fbdac062-db17-11ee-9a5f-000c29d1c19b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Replica 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:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set, 1 warning (0.00 sec)
值得一提的是,在主机的配置上,有一个binlog_format的属性,用于指定二进制日志文件中记录的事件格式
- statement:如执行now()这种函数时,从机会照搬复制主机的数据。
- row:默认值。 如执行now()这种函数时,从机会获取自身的数据,能够避免由于不确定性造成的错误。但可能生成更大的二进制日志文件,因为它记录了每一行数据的变化。
- mixed:中庸策略,在某些情况下,它会记录 SQL 语句,而在另一些情况下会记录数据行更改。