1.1 企業Linux運維場景數據同步方案
1.1.1 文件級別的異機同步方案
1、scp/sftp/nc 命令可以實現遠程數據同步。
2、搭建ftp/http/svn/nfs 服務器，然後在客戶端上也可以把數據同步到服務器。
3、搭建samba文件共享服務，然後在客戶端上也可以把數據同步到服務器。
http://taokey.blog.51cto.com/4633273/1203553
4、利用rsync/csync2/union等均可以實現數據同步
提示：union可實現雙同步，csync2可實現多機同步。
以上文件同步方式如果結合定時任何或者inotify，sersync等功能，可以實現定時以及定時的數據同步。
5、文件級別也可以利用mysql，mongodb等軟件作爲容器實現。
6、程序向兩個服務器同時寫入數據，雙寫就是一個同步機制
特點：簡單、方便、效率和文件系統級別要差一點，但是同步的節點可以提供訪問。
軟件的自身同步機制（mysql，oracle，mongdb，ttserver，redis….）文件放到數據庫，同步到從庫，再把文件拿出來。
7、DRBD文件系統級別（基於塊設備複製，直接複製block）
1.1.2 文件系統級別的異機同步方案
1、drbd基於文件系統同步，相當於網絡RAID1，可以同步幾乎任何業務數據。
mysql數據庫的官方推薦drbd同步數據，所有單點服務例如：NFS、MFS（DRBD）MySQL等都可以用drbd做複製，效率很高，缺點：備機服務不可用
2、數據庫同步方案：
a.自身同步機制：
mysql replication，mysql主從複製（邏輯的SQL重寫）物理複製方法<===drbd（從庫不提供讀寫）
oracle dataguard（物理的磁盤塊，邏輯的SQL語句重寫）9i從庫不提供腹瀉的，11g的從庫實現了readonly
b.第三方drbd，參考URL
Heartbeat+DRBD+MySQL高可用架構方案與實施過程細節
http://oldboy.blog.51cto.com/2561410/1240412
1.2 MySQL主從複製
MySQL的主從複製方案，和上述文件及文件系統級別同步是類似的，都輸數據的傳輸。只不過MySQL無需藉助第三方工具，而是其自帶的同步複製功能，另外一點，MySQL的主從複製並不是從硬盤給上文件直接同步，而是邏輯的binlog日誌同步到本地的應用執行的過程
提示：官方說主從不要超過9臺，推薦不超過5臺。
1、單向主從複製邏輯圖
2、雙向主主同步邏輯圖，此架構可以在Master1端或Master2端進行數據寫入
3、線性級聯單向雙主同步邏輯圖，此架構只能在Master1端進行數據寫入
4、環狀級聯單向多主同步邏輯圖，任何一個點都可以寫入數據
5、環狀級聯單向多主多從同步邏輯圖，此架構只能在任意一個Master端進行數據寫入
MySQL官方的同步架構圖
工作中第一種方案和第二種方案最常用。
1.3 MySQL主從複製原理介紹
MySQL的主從複製是一個異步的複製過程（雖然一般情況下感覺是實時的），數據將從一個Mysql數據庫（我們稱之爲Master）複製到另一個Mysql數據庫（我們稱之爲Slave），在Master與Slave之間實現整個主從複製的過程是由三個線程參與完成的。其中有兩個線程（SQL線程和IO線程）在Slave端，另一個線程（I/O線程）在Master端。
要實現MySQL的主從複製，首先必須打開Master端的binlog記錄功能，否則就無法實現。因爲整個複製過程實際上就是Slave從aster端獲取binlog日誌，然後再在Slave上以相同順序執行獲取的binlog日誌中的記錄的各種SQL操作
畫圖：
1）在Slave 服務器上執行sart slave命令開啓主從複製開關，開始進行主從複製。
2）此時，Slave服務器的IO線程會通過在master上已經授權的複製用戶權限請求連接master服務器，並請求從執行binlog日誌文件的指定位置（日誌文件名和位置就是在配置主從複製服務時執行change
master命令指定的）之後開始發送binlog日誌內容
3）Master服務器接收到來自Slave服務器的IO線程的請求後，其上負責複製的IO線程會根據Slave服務器的IO線程請求的信息分批讀取指定binlog日誌文件指定位置之後的binlog日誌信息，然後返回給Slave端的IO線程。返回的信息中除了binlog日誌內容外，還有在Master服務器端記錄的IO線程。返回的信息中除了binlog中的下一個指定更新位置。
4）當Slave服務器的IO線程獲取到Master服務器上IO線程發送的日誌內容、日誌文件及位置點後，會將binlog日誌內容依次寫到Slave端自身的Relay Log（即中繼日誌）文件（Mysql-relay-bin.xxx）的最末端，並將新的binlog文件名和位置記錄到master-info文件中，以便下一次讀取master端新binlog日誌時能告訴Master服務器從新binlog日誌的指定文件及位置開始讀取新的binlog日誌內容
5）Slave服務器端的SQL線程會實時檢測本地Relay Log 中IO線程新增的日誌內容，然後及時把Relay LOG 文件中的內容解析成sql語句，並在自身Slave服務器上按解析SQL語句的位置順序執行應用這樣sql語句，並在relay-log.info中記錄當前應用中繼日誌的文件名和位置點
主從複製條件
1、開啓Binlog功能
2、主庫要建立賬號
3、從庫要配置master.info（CHANGE MASTER to…相當於配置密碼文件和Master的相關信息）
4、start slave 開啓複製功能
知識點
1.3個線程，主庫IO，從庫IO和SQL及作用
2.master.info（從庫）作用
3.relay-log 作用
4.異步複製
5.binlog作用（如果需要級聯需要開啓Binlog）
小結：
主從複製是異步的邏輯的SQL語句級的複製
複製時，主庫有一個O/O線程，從庫有兩個線程，I/O和SQL線程
實現主從複製的必要條件是主庫要開啓記錄binlog功能
作爲複製的所有Mysql節點的server-id都不能相同
binlog文件只記錄對數據庫有更改的SQL語句（來自主庫內容的變更），不記錄任何查詢（select，show）語句
1.4 環境搭建
我們準備的是多實例，一臺服務器開啓3個服務端口不同
環境準備：
[root@db02 3307]# netstat -lntup|grep 330tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3074/mysqldtcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 33364/mysqldtcp 0 0 0.0.0.0:3308 0.0.0.0:* LISTEN 34084/mysqld
主庫開啓Binlog功能
[root@db02 3307]# grep log-bin /data/3306/my.cnflog-bin = /data/3306/mysql-bin
設置server-id，此處ID不可以相同否則最後出現IO錯誤
[root@db02 3307]# grep server-id /data/3306/my.cnfserver-id = 1[root@db02 3307]# grep server-id /data/3307/my.cnfserver-id = 3[root@db02 3307]# grep server-id /data/3308/my.cnfserver-id = 2================================================
[root@db02 3307]# grep server-id /data/{3306,3307,3308}/my.cnf/data/3306/my.cnf:server-id = 1/data/3307/my.cnf:server-id = 3/data/3308/my.cnf:server-id = 2
主庫需要授權slave訪問的用戶
mysql>grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123456';mysql> flush privileges;mysql>show grants for rep@'172.16.1.%';mysql>select user,host from mysql.user
#replication slave 爲mysql同步的必須權限，此處不要授權all權限
因爲從庫現在還沒有數據，或者數據不統一我們需要導入數據
鎖表、查看binlog文件及位置點，主庫導出全備，需要鎖表（-x –master-date=2）
flush table with read lock; 鎖表，窗口不能退出，退出失效root@oldboy 05:16:22->show master status; 臨界點，將來恢復就從0025開始+------------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000025 | 9155 | | |+------------------+----------+--------------+------------------+1 row in set (0.00 sec)
備份
mysqldump -uroot -p123456 -S /data/3306/mysql.sock -A -B --events|gzip >/server/backup/rep_bak$(date +%F).sql.gz[root@db02 oldboy]# ls -lrt /server/backup/total 308-rw-r--r-- 1 root root 20 Dec 23 2015 bak_2015-12-23.sql.gz-rw-r--r-- 1 root root 152214 Dec 23 2015 bak.sql.gz-rw-r--r-- 1 root root 152238 Jun 29 17:20 rep_bak2016-06-29.sql.gz解鎖：unlock table;root@oldboy 05:22:00->show master status;+------------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000025 | 9155 | | |+------------------+----------+--------------+------------------+
#如果解鎖之後還是mysql-bin.000025 說明是正確的，如果動了說明沒有鎖住表
#如果mysqldump 加了-F 他就會更改刷新binlog
從庫操作
1.確保server-id不同
2.把主庫的備份導入到從庫
[root@db02 backup]# gzip -d rep_bak2016-06-29.sql.gz[root@db02 backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock <rep_bak2016-06-29.sql
3.查找位置點，配置master.info
mysql-bin.000025 | 9155
| 主庫的位置點
Mysql從庫連接主庫的配置信息如下：
CHANGE MASTER TOMASTER_HOST='172.16.1.52', #這是主庫的IP（域名也可以需要做解析）MASTER_PORT=3306, #主庫的端口，從庫端口和主庫不可以相同MASTER_USER='rep', #這是主庫上創建用來複制的用戶repMASTER_PASSWORD='123456' #rep的密碼MASTER_LOG_FILE='mysql-bin.000025', #這裏是show master status時看到的查詢二進制日誌文件名稱，這裏不能多空格MASTER_LOG_POS=9155; #這裏是show master status時看到的二進制日誌偏移量，不能多空格提示：3307操作此步：會在/data/3307/data下面產生master.info文件
開啓從庫複製開關
root@oldboy 07:47:44->show slave status\G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: www.etiantian.orgMaster_User: repMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000025Read_Master_Log_Pos: 9706Relay_Log_File: relay-bin.000002Relay_Log_Pos: 453Relay_Master_Log_File: mysql-bin.000025Slave_IO_Running: Yes IO線程代表IO正常Slave_SQL_Running: Yes SQL線程Replicate_Do_DB:Replicate_Ignore_DB: mysqlReplicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 9706Relay_Log_Space: 603Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_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: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 11 row in set (0.00 sec)
查看檢查結果：在主庫創建目錄查看從庫是否存在即可
提示：如果出現show master status裏面沒有東西說明bin-log日誌沒有開啓
Slave_IO_Running:Yes，這是I/O線程狀態，I/O線程負載從從庫去主庫讀取binlog日誌，並寫入從庫的中繼日誌中，狀態爲Yes表示I/O線程工作正常。
Slave_SQL_Running:Yes 這個是SQL線程狀態，SQL線程負載讀取中繼日誌（relay-log）中的數據並轉換爲SQL語句應用到從庫數據庫中，狀態爲Yes表示I/O線程工作正常
Seconds_Behind_Master:0 這個是在複製過程中，從庫比主庫延遲的描述，這個參數很重要，但企業裏更準確地判斷主從延遲的方法爲：在主庫寫時間戳，然後從庫讀取時間戳進行比較，從而認定是否延遲。
從庫提升主庫步驟
mysql主從複製中，需要將備庫（從庫）提升爲主庫，需要取消其從庫角色，可以通過執行以下命令：
stop slave;
reset slave all;
RESET SLAVE ALL是清除從庫的同步複製信息，包括連接信息和二進制文件名、位置
從庫上執行這個命令後，使用show slave status將不會有輸出
1.5 生產場景下輕鬆部署MySQL主從複製
快速步驟MySQL主從複製
1）安裝好配置從庫的數據庫，配置好log-bin和server-id參數
2）無需配置主庫my.cnf，主庫的log-bin和server-id參數默認就是配置好的。
3）登錄主庫，增加從庫連接同步的賬戶，例如：rep，並授權replication同步的權限
4）使用mysqldump命令帶-x和–master-data=2的命令及參數全備數據，把它恢復到從庫
5）從庫執行CHANGE MASTER TO….語句，需要binlog文件及對應點（因爲–master-data=2已經帶了）
6）從庫開啓同步開關，start slave
7）從庫show slave status\G，檢查同步狀態，並在主庫更新測試
步驟：
主庫：
shell>mysqldump -uroot -p123456 -S /data/3306/mysql.sock -B -F -R -x --master-data=1 -A --events|gzip >/server/backup/rep3307_(date +%F).sql.gz
因爲添加了master-data=1 已經爲我們寫好了位置點
從庫：
shell>mysql -uroot -p123456 -S /data/3307/mysql.sock <./repo3307_2016-07-03.sqlmysql>CHANGE MASTER TOMASTER_HOST='www.etiantian.org',MASTER_PORT=3306,MASTER_USER='rep',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000025',MASTER_LOG_POS=9815;mysql>start slavemysql>show slave status\G
錯誤提示：
Slave_SQL_Running：NO 下面會有提示，如果提示這個庫已經創建無法創建等是可以跳過的
解決辦法
stop slave;set global sql_slave_skip_counter =1; #將同步指針向下移動，如果多次不同步，可以添加移動的數量start slave;
查看連接的線程，每一個線程代表一個從庫
root@oldboy 08:51:37->show processlist;
+----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
| 2 | rep | 172.16.1.52:51317 | NULL | Binlog Dump | 68 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
| 3 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
2 rows in set (0.00 sec)
主庫I/O工作狀態上方×××
| 主庫I/O 線程工作狀態 | 解釋說明 |
| Sending binlog event to slave | 線程已經從二進制binlog日誌讀取了一個事件並且正將它發送到從服務器 |
| Finished reading one binlog；switching to next binlog | 線程已經讀完二進制binlog日誌文件，並且整打開下一個要發送到從服務器的binlog日誌文件 |
| Has sent all binlog to slave；waiting for binlog to be updated | 線程已經從binlog日誌讀取所有更新並已經發送到了從數據庫服務器。線程現在爲空閒狀態，等待由主服務器上二進制binlog日誌中的新事件更新。 |
| Waiting to finalize termination | 線程停止時發送的一個很簡單的狀態 |
從庫I/O線程工作狀態show processlist;
| 從庫I/O線程工作狀態 | 解釋說明 |
| Connecting to master | 線程正試圖連接主服務器 |
| Checking master version | 同步主服務器之間建立後臨時出現的狀態 |
| Registering slave to master | |
| Requesting binlog dump | 建庫同主服務器之間的連接後立即臨時出現的狀態，線程向主服務器發送一條請求，索取從請求的二進制binlog日誌文件名和位置開始的二進制binlog日誌的內容 |
| Waiting to reconnect after a failed binlog dump request | 如果二進制binlog日誌轉存儲請求失敗，線程進行睡眠狀態，嘗試重新連接 |
| Reading event from the relay log | 線程已經從中繼日誌讀取了一個事件，可以對事件進行處理了。 |
| Has read all relay log；waiting for the slave I/O thread to update it | 線程已經處理了中繼日誌文件中的所有事件，現在等待I.O線程將新事件寫入中繼日誌 |
| Waiting for slave mutex on exit | 線程停止時發生了一個很簡單的狀態 |
1.6 MySQL主從複製更多應用技巧實踐
1. 工作中MySQL從庫停止複製的故障案例
模擬重現故障的鞥能力是運維人員最重要的能力。下面就進行模擬操作。先在從庫創建一個庫，然後去主庫創建同名的庫來模擬數據衝突
mysql>show slave status;報錯：且show slave status\G;
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB: mysql
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1007
Last_Error: Error ‘Can’t create database ‘cyh’; database exists’ on query. Default database: ‘cyh’. Query: ‘create database cyh’
對於該衝突，解決方法爲：
stop slave； #臨時停止同步開關set global sql_slave_skip_counter =1； #將同步指針向下移動一個start slave；
或可以根據錯誤號事先在配置文件中配置，跳過指定的不影響業務的數據的錯誤，例如：
[root@db02 oldboy]# grep slave-skip /data/3306/my.cnfslave-skip-errors = 1032,1062
提示：類似由於入庫重複導致的失敗可以忽略，其他情況是不可以忽略需要根據公司不同業務來評估。
錯誤2
MYSQL ERROR 139 (HY000)錯誤的解決辦法
標籤：mysql error 1396 it
創建用戶的時候報這個錯誤，原因是MYSQL中已經有了這個用戶，可以用mysql.user中直接刪除，然後刷新權限，在創建用戶就不會有這個問題了。如果是drop user先，那麼mysql內部應該會自動刷新一下，那麼在創建就不會這個問題看
其他可能引起復制故障的問題：
MySQL自身的原因以及人爲重複插入數據
不同的數據版本會引起不同步，低版本到高版本可以，但是高版本不能往低版本同步
MySQL的運行錯誤或者程序BUG
binlog記錄模式，例如：row level模式就比默認的語句要好
1.7 讓MySQL從庫記錄binlog日誌方法
從庫需要記錄binlog的場景爲：當前從庫還要作爲其他從庫的主庫，例如：級聯複製或者雙主互爲主從場景的情況下。
在從庫的my.cnf中加入如下參數，然後重啓服務生效
log-slave-updates #必須要有這個參數log-bin = /data/3307/mysql-binexpire_logs_days = 7 #相當於刪除7天之後的日誌
1.7 Mysql主從複製延遲問題原因及解決方法
問題一：一個主庫的從庫太多，導致複製延遲。
建議從庫數量3-5 爲宜，要複製的從節點數量過多，會導致複製延遲
問題二：從庫硬件比主庫差，導致複製延遲
查看master和slave的系統配置，可能會因爲機器配置的問題，包括磁盤IO、CPU、內存等各方面因素造成複製的延遲，一般發生在高併發大數據量寫入場景。
問題三：慢SQL語句過多
假如一條SQL語句，執行時間是20秒，那麼從庫執行完畢，到從庫上能查到數據也至少是20秒，這樣就延遲20秒了
SQL語句的優化一般要作爲常規工作不斷的監控和優化，如果是單個SQL的寫入時間長，可以修改後分多次寫入，通過查看慢查詢日誌或show full processlist 命令找出執行時間長的查詢語句或者打的事務。
問題四：主從複製的設計問題
例如，主從複製單線程，因爲主庫寫併發太大，來不及傳送到從庫就會導致延遲。
更高版本的MySQL可以支持多線程複製，門戶網站會開發自己多線程同步功能。
問題五：主從庫之間的網絡延遲。
主庫的網卡、網線、連接的交換機等網絡設備都可能成爲複製的瓶頸，導致複製延遲，另外，跨公網主從複製很容易導致主庫複製延遲
問題六：主庫讀寫壓力大，導致複製延遲
主庫硬件要搞好一點，架構的前端要加buffer以及緩存層。
通過read-only參數讓從庫只讀訪問
read-only參數選項可以讓從服務器只允許來自服務器線程或具有SUPER權限的數據庫用戶進行更新，可以確保從服務器不接受來自用戶端的非法用戶更新。
read-only參數具有允許數據庫更新的條件爲：
具有SUPER權限的用戶可以更新，不受read-only參數影響，例如：管理員root。
來自從服務器線程可以更新，不受read-only參數影響，例如：rep用戶
在生產環境中，可以在從庫Slave中使用read-only參數，確保從庫數據不被非法更新。
read-only參數的配置如下：
方法一：啓動數據庫時直接帶–read-only參數啓動或重啓，使用
mysqladmin -uroot -p123456 -S /data/3307/mysql.sock shutdownmysql_safe --defaults-file=/data/3307/my.cnf --read-only &
方法二：在my.cnf裏[mysqld]模塊下加read-only參數，然後重啓數據庫
[mysqld]read-only
1.8 Web用戶專業設置方案：MySQL主從複製讀寫分離集羣
專業的運維人員提供給開發人員的讀寫分離的賬戶設置如下：
1）訪問主庫和從庫時使用一套用戶密碼，例如，用戶名：web，密碼：123456
2）即使訪問IP不同，端口也儘量相同（3306）。例如:寫庫VIP爲10.0.0.1 ，讀庫VIP爲10.0.0.2
除了IP沒辦法修改之外，要儘量爲開發人員提供方便，如果數據庫前端有DAL層（DBPROXY代理）還可以只給開發人員一套用戶、密碼、IP、端口，這樣就更專業了，剩下的都是由運維搞定。
如果給開發授權權限
方法1：主庫和從庫使用不同的用戶，授權不同的權限。
主庫上對web_w用戶授權如下：
用戶：web_w 密碼：123456 端口3306 主庫VIP：10.0.0.1權限：SELECT,INSERT,UPDATE,DELETE命令：GRANT SELECT,INSERT,UPDATE,DELETE ON wen.* to 'web_w'@10.0.0.% identified by '123456';
從庫對web_r用戶授權如下：
用戶：web_r 密碼:123456 端口：3306 從庫VIP：10.0.0.2權限：SELECT命令：GRANT SELECT ON web.* TO [email protected].% identfied by '123456';
提示：此方法顯得不夠專業，但是可以滿發開發需求。
方法2：主庫和從庫使用相同的用戶，但授予不同的權限。（由於主從同步 有一些可能無法同步）
主庫上對web用戶授權如下：
用戶：web 密碼：123456 端口：3306 主庫VIP：10.0.0.1權限：SELECT,INSERT,UPDATE,DELETE命令：GRANT SELECT,INSERT,UPDATE,DELETE ON web.* TO [email protected].% identified by '123456';
從庫上對web用戶授權如下：
用戶：web 密碼：123456 端口：3306 從庫VIP：10.0.0.2權限：SELECT#由於主庫和從庫是同步複製的，所以從庫上的Web用戶會自動和主庫一直，既無法實現只讀select的權限。
方法3：在從庫上設置read-only參數，讓從庫只讀
主庫和從庫：主庫和從庫使用相同的用戶，授予相同的權限（非ALL權限）
用戶：web 密碼：123546 端口：3306 主庫VIP:10.0.0.8權限：SELECT,INSERT,UPDATE,DELETE命令：GRANT SELECT,INSERT,UPDATE,DELETE ON web.* to [email protected].% identified by '123546';由於從庫設置了read-only，非super權限是無法寫入的，因爲通過read-only參數就可以
忽略授權庫Mysql同步，主庫配置參數如下：
binlog-ignore-db = mysqlreplicate-ignore-db = mysql
1.9 MySQL主從複製集羣架構的數據備份策略
有了主從複製，還需要做定時全量備份
因爲，如果主庫有語句誤操作（例如：drop database oldboy;）從庫也會執行drop，這樣MySQL從庫就都刪除了該數據。
把從庫作爲數據備份服務器時，備份策略如下：
高併發業務場景備份時，可以選擇在一臺從庫上備份（Slave）把從庫作爲數據備份服務器時需要在從庫binlog功能。
1）選擇一個不對外提供服務的從庫，這樣可以確保和主庫更新最接近，專門做數據備份用
2）開啓從庫的binlog功能。
備份時可以選擇只停止SQL線程，停止應用SQL語句到數據庫，I/O線程保留工作狀態，執行命令爲stop slave sql_thread；備份方式可以採取mysqldump邏輯備份或者直接物理備份，例如使用cp、tar（針對目錄）工具，或xtrabackup（第三方的物理備份軟件）進行備份，邏輯備份和物理備份的選擇，一般是根據總的備份數據量的多少進行選擇，數據庫低於20G，建議選擇mysqldump邏輯備份方法，安全穩定，最後把全量和binlog數據發送到備份服務器上留存
1.9 MySQL半同步
M –S1
–S2
–S3
–S4
是否事先選擇好從庫，從庫如何選擇
1）半同步從庫（谷歌半同步插件 5.5自帶）
—S1作爲備庫
第一:主庫插入數據後，同時寫入到S1，成功返回。
優點:兩臺庫會同時寫入數據。
缺點：寫入會慢，網絡不穩定，主庫持續等待。
解決措施：
1.連不上S1的時候會自動轉爲異步
2.設置10秒超時，超時10秒轉爲異步
3.S1網絡，硬件要好，不提供服務，只能接管。
總結：
半同步就是就是用戶向mysql寫入數據，先寫入到主庫，然後生成binlog日誌。主庫等待從庫來取binlog日誌，如果從庫超過10秒沒有來獲取binlog日誌。主庫自動轉換爲異步，以後用戶寫入數據生成binlog日誌，等待用戶自己來取，沒有取到主庫也不在管理。
查看的位置在數據裏的安裝目錄下可以找到
[root@db02 oldboy]# ll /application/mysql-5.5.49/lib/plugin/-rwxr-xr-x 1 root root 173428 Jun 16 12:57 semisync_master.so-rwxr-xr-x 1 root root 94098 Jun 16 12:57 semisync_slave.so
2） 從庫什麼也不操作，只同步主庫
優點：可以立即接管主庫
缺點：浪費資源 不推薦使用
3）臨時選擇從庫
當主庫宕機後，mysql 臨時選擇一個最接近主庫的slave
確定主之後，角色切換S1提升爲新主M1
主庫宕機有兩種情況
1、如果主庫可以SSH連接，bin-log數據沒丟，要把主庫的bin-log補全到所有庫
a.提升S1爲M1的操作
1）調配置read-only，授權用戶select，變成增刪改查，開啓binlog
2）rm -rf master.info relay-log*
3）登錄數據庫reset master
4）重啓數據庫，提升S1爲M1完畢
b.所有從庫:CHANGE MASTER TO,MASTER_LOG_FILE=’mysql-bin.000001′,MASTER_LOG_POS=107
2、如果數據庫連接不上
a.半同步從庫提升主庫，半同步數據，補全到所有從庫
半同步從庫提升主庫的操作1-a，所有從庫執行同1-b
b.S1 只當做備庫的方法
提升S1爲主庫，操作見1-a步驟，所有從庫CHANGE MASTER 同1-b
c.主庫宕機實現沒有指定從庫爲主庫
選主的過程:
1.登錄國有從庫show processlist;裏面有2個線程，查看2個線程狀態
登錄所有從庫，分別查看master.info
[root@db02 data]# cat master.info18mysql-bin.000028188www.etiantian.orgrep1234563306600
確保更新完畢，查看4個從庫那個更快，經過測試沒有延遲的情況POS差距很小，甚至一直的
選擇文件及位置點最大的爲主庫，補全所有其他從庫，和當前準備爲主的數據一直。
從庫提升主庫的操作步驟（簡單說明）
提升的主庫操作
1.確保所有relay log全部更新完畢
在每個庫執行seop slave in_thread(sql線程)；show processlit
直到看到Has read all relay log；表示從庫更新都執行完畢；
2.登錄從庫提升爲主庫
登錄：mysql -uroot -p123456 -S /data/3306/mysql.sockstop slave;retset master;quit;
3.進到數據庫數據目錄，刪除master.info relay-log.info
cd /data/3306/datarm -rf master.info relay-log.info檢查mysql授權表（web用戶權限以及從庫同步的權限）是不是正確的read-only等參數確認bin-log是否開啓
4.開啓binlog
vim /data/3306/my.cnf
log-bin = /data/3306/mysql-bin//如果存在log-slave-updates read-only等一定要註釋掉它。/data/3306/mysql restart到此爲止，提升主庫完畢
其他從庫操作
登錄從庫
stop slave；CHANGE MASTER TO MASTER_HOST ='192.168.1.1'; #如果不同步，就指定位置點。start slave；show slave status\G==========================主庫宕機切換成功修改程序配置文件從主數據庫32指定32
平時訪問數據庫用域名，則直接可以修改hosts解析。
HMA高可用根據就是利用以上原理實現的。
以上是mysql主庫意外宕機。
假如：我們有計劃切換，如何從操作？
1.主庫鎖表
2.登錄所有的庫查看同步狀態，是否完成
步驟和前面相同
2.1 MySQL常用高可用方案
mysql+HA+DRBD高可用場景
mysql+MMM
mysql+MHA（日本人開發）
實現原理：把所有服務器之間做了一個SSH免密鑰登錄，控制檯登錄到主庫分發binlog到所有從庫，在上從庫比對哪一個更快更全
PXC
mysql+cluster （企業很少使用）
很多企業常用M-S