1. 首頁 > 生活百科 > >

01-MySQL8主從詳解( 二 )

生活百科

溫馨提示：在主服務器上最重要的二進制日志設置是sync_binlog，這使得mysql在每次提交事務的時候把二進制日志的內容同步到磁盤上 ， 即使服務器崩潰也會把事件寫入日志中 。
sync_binlog這個參數是對于MySQL系統來說是至關重要的，他不僅影響到Binlog對MySQL所帶來的性能損耗，而且還影響到MySQL中數據的完整性 。對于"sync_binlog"參數的各種設置的說明如下：
sync_binlog=0，當事務提交之后，MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定什么時候來做同步，或者cache滿了之后才同步到磁盤 。
sync_binlog=n，當每進行n次事務提交之后，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤 。
在MySQL中系統默認的設置是sync_binlog=0，也就是不做任何強制性的磁盤刷新指令，這時候的性能是最好的，但是風險也是最大的 。因為一旦系統Crash ， 在binlog_cache中的所有binlog信息都會被丟失 。而當設置為“1”的時候，是最安全但是性能損耗最大的設置 。因為當設置為1的時候，即使系統Crash ， 也最多丟失binlog_cache中未完成的一個事務，對實際數據沒有任何實質性影響 。
從以往經驗和相關測試來看，對于高并發事務的系統來說 ， “sync_binlog”設置為0和設置為1的系統寫入性能差距可能高達5倍甚至更多 。
2.4 數據一致性在同步前保證master和slave中的數據一致，新環境忽略本步驟
導出數據庫之前先鎖定數據庫
#數據庫只讀鎖定命令，防止導出數據庫的時候有數據寫入,unlock tables命令解除鎖定mysql> flush tables with read lock;導出master數據庫中需要同步的庫
#導出需要同步的庫[root@master ~]#mysqldump -uroot test -p123456 >/opt/test.sql#如不指定 ， 則導出所有庫mysqldump -uroot -p123456 --all-databases>/opt/all.sql將導出數據導入salve中
#傳到slavescp /opt/all slave:/opt#在slave導入數據庫mysql> source /opt/all.sql2.5 創建數據同步賬號登錄主數據庫創建一個用于從數據庫復制的賬號
mysql> create user 'rep'@'192.168.150.25' identified with mysql_native_password by 'repl123';grant replication slave on *.* to 'rep'@'192.168.150.25';mysql> flush privileges;查看主服務器master狀態(注意File與Position項，從服務器需要這兩項參數)
mysql> show master status;+-----------+-----------+--------------+------------------+-------------------+| File| Position| Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+-----------+-----------+--------------+------------------+-------------------+| mysql-bin.000065 | 186607472 ||||+-----------+-----------+--------------+------------------+-------------------+1 row in set (0.00 sec)2.6 配置slave修改my.cnf配置文件
vim /etc/my.cnf#設置從服務器id，必須于主服務器不同server-id=2#啟動MySQ二進制日志系統log-bin=mysql-bin#需要同步的數據庫名 。如果不指明同步哪些庫，就去掉這行，表示所有庫的同步（除了ignore忽略的庫）配置主從同步指令
#執行同步前，要先關閉slavemysql> stop slave;mysql> change master to master_host='192.168.150.185',master_user='repl',master_password='repl123',master_log_file='ON.000065',master_log_pos=186607472;mysql> start slave;mysql> show slave status \G;mysql> show slave status \G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.150.185Master_User: slaveMaster_Port: 3306Connect_Retry: 60Master_Log_File: ON.000065Read_Master_Log_Pos: 187730832Relay_Log_File: xmkjoa02-relay-bin.000002Relay_Log_Pos: 46151494Relay_Master_Log_File: ON.000065Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 187730832Relay_Log_Space: 46151706Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: YesMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 1Master_UUID: 6c3f5abb-1c32-11ec-96ba-fa163e7a46bfMaster_Info_File: mysql.slave_master_infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set:Executed_Gtid_Set:Auto_Position: 0Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:Master_public_key_path:Get_master_public_key: 1Network_Namespace:1 row in set (0.00 sec)

推薦閱讀