1 主庫配置
1.1 my.cnf配置：
在主庫配置文件my.cnf中進行以下基本配置：2018-11-09mysql
log-bin = mysql-bin //二進制日誌文件名稱主體 log-bin-index = mysql-bin.index //二進制日誌文件索引文件 server-id = 1 //惟一的服務器ID，爲了保持惟一性，能夠去ip的尾部 binlog-format = mixed //控制複製基於的方式，有基於語句(statement)，基於行(row)，混合(mixed)，**主從庫須要保持一致** #sync_binlog=1 //推薦配置，開啓該選項，mysql每次在事務提交前會將二進制日誌同步到磁盤上，保證在服務器崩潰時不會丟失事件。
默認複製所有數據庫，若是須要指定數據庫，請參照第7節（複製過濾）。sql
好比說要指定db1和db2兩個數據庫進行主從複製： binlog-do-db = db1 binlog-do-db = db2
1.2 添加複製帳戶：
複製帳戶添加以及權限設置：數據庫
mysql> grant replication slave, replicatin client on \*.\* to repl@'172.16.226.192' identified by 'repl123456'; //其中repl是用戶名，repl123456爲帳戶密碼，172.16.226.168爲備庫的地址。 mysql> flush privileges; //在不重啓mysql服務的狀況下完成權限的更新
2 備庫配置
在備庫配置文件my.cnf中進行以下基本配置：緩存
relay-log = slave-relay-bin //中繼日誌文件名稱主體 relay-log-index = slave-relay-bin.index //中繼日誌文件索引文件 server-id = 2 //惟一的服務器ID，必需要異於主庫 #read_only = 1 //限制備庫爲只讀，可選 log_slave_updates = 1 //控制是否在中繼日誌執行以後，將同步過來的數據添加到本身的binlog中去，1表明是 skip_slave_start // 該選項可以阻止備庫在崩潰後自動啓動複製，建議開啓 即便開啓了建議的選項，備庫仍然可能在崩潰後被中斷，由於master.info和中級日誌文件都不是崩潰安全的，因此建議開啓一下選項： sync_master_info = 1 sync_relay_log = 1 sync_relay_log_info = 1
一樣能夠過濾待同步的數據庫，或者表，參考複製過濾一節。安全
3 數據庫遠程備份
數據庫遠程備份能夠選擇mysqldump（邏輯備份）進行熱備，但對於數據量較大時會比較慢，Xtrabackup（物理備份）也能夠對mysql數據庫進行熱備（這裏使用innobackupex-1.5.1），Xtrabackup能夠實現innoDB等數據庫的在線備份，速度較快且不影響正常讀寫。這裏對全庫進行備份。服務器
3.1 建立備份帳戶
在主服務器建立用戶backup（使用最小權限），用於數據庫備份。網絡
mysql> grant reload, lock tables, replication client on \*.\* to backup@'%' identified by 'backup123'; mysql> flush privileges; //在不重啓mysql服務的狀況下完成權限的更新
3.2 數據庫徹底備份
徹底備份和恢復準備兩個步驟都是在主庫服務器完成。app
innobackupex-1.5.1 --defaults-file=/etc/mysql/my.cnf --user=backup --password=backup123 /mysqlbackup --defaults-file：選擇默認的配置文件 --user和--password：分別爲進行備份的用戶名和密碼 /mysqlbackup：目標目錄
3.3 恢復準備
通常狀況下，在備份完成後，數據尚且不能用於恢復操做，由於備份的數據中可能會包含還沒有提交的事務或已經提交但還沒有同步至數據文件中的事務。所以，此時數據文件仍處理不一致狀態。「準備」的主要做用正是經過回滾未提交的事務及同步已經提交的事務至數據文件也使得數據文件處於一致性狀態。
innobakupex命令的--apply-log選項可用於實現上述功能。以下面的命令：ide
innobackupex-1.5.1 --apply-log --user=backup --password=backup123 /mysqlbackup/2017-01-11_21-20-57 若是執行正確，其最後輸出的幾行信息一般以下： xtrabackup: starting shutdown with innodb_fast_shutdown = 1 120407 9:01:36 InnoDB: Starting shutdown... 120407 9:01:40 InnoDB: Shutdown completed; log sequence number 92036620 120407 09:01:40 innobackupex: completed OK!
在實現「準備」的過程當中，innobackupex一般還可使用--use-memory選項來指定其可使用的內存的大小，默認一般爲100M。若是有足夠的內存可用，能夠多劃分一些內存給prepare的過程，以提升其完成速度。函數
3.4 數據拷貝
將主服務器上準備好的數據庫拷貝到從服務器。(固然也能夠打包後再拷貝)
scp -r /mysqlbackup/ copyer@192.168.1.192:/data/
3.5 數據恢復
在數據恢復以前首先關閉從服務器mysql服務，並從備份文件夾中的xtrabackup_binlog_info文件中獲取當前正在使用的二進制日誌文件，以及備份這一刻爲止二進制日誌事件的位置。若是datadir目錄不爲空，還須要清空datadir目錄。
innobackupex命令的--copy-back選項用於執行恢復操做，其經過複製全部數據相關的文件至mysql服務器datadir目錄中來執行恢復過程。innobackupex經過backup-my.cnf來獲取datadir目錄的相關信息（也能夠經過--defaults-file指定my.cnf目錄，還要確保datadir路徑爲空）
innobackupex-1.5.1 --copy-back /mysqlbackup 若是執行正確，其輸出信息的最後幾行一般以下： innobackupex: Starting to copy InnoDB log files innobackupex: in '/backup/2012-04-07_08-17-03' innobackupex: back to original InnoDB log directory '/mydata/data' innobackupex: Finished copying back files. 120407 09:36:10 innobackupex: completed OK!
請確保如上信息的最後一行出現「innobackupex: completed OK!」。
當數據恢復至datadir目錄之後，還須要確保全部數據文件的屬主和屬組均爲正確的用戶，如mysql，不然，在啓動mysqld以前還須要事先修改數據文件的屬主和屬組。如：
chown -R mysql:mysql /var/lib/mysql/
4 主從鏈接
4.1 開啓從數據庫
service mysql start
若是開啓mysql失敗，能夠經過查看錯誤日誌尋找失敗緣由。
4.2 創建主從鏈接
從庫經過複製帳戶鏈接到主庫：（slave必須處於stop狀態才能使如下鏈接生效）
mysql> change master to master_host='192.168.1.208'，master_user='repl'， master_password='repl123456'，master_log_file='mysql-bin.000001'（備份時獲得的活動日誌）,master_log_pos=0（備份時獲得的活動日誌中事件的位置）;
注：若是這裏在進行主從鏈接的時候一直連不上master，有一個可能的緣由是my.cnf配置文件中綁定了本機，即bind-address = 127.0.0.1，咱們要作的就是將其註釋掉，不然外部機器是訪問不了的。
開啓slave：
mysql> start slave;
查看slave狀態，能夠發現IO線程和SQL線程已處於開啓狀態，有很是多表徵從庫鏈接狀態的變量（這些變量一樣能夠用於設置主從監控），在這裏不一一作介紹。
mysql> show slave status; Slave_IO_Running: Yes //表示IO線程運行正常 Slave_SQL_Running: Yes //表示SQL線程運行正常 Seconds_Behind_Master: 0 //表示在網絡條件較好的狀況下，從庫可以及時同步上主庫
4.3 經常使用監控命令
mysql> show processlist\G; //查看數據庫服務線程狀況 mysql> show master/slave status\G; //查看主備庫狀態 mysql> flush logs; //強制輪換(rotate)二進制日誌，從而獲得一個完整的二進制日誌文件 mysql> show binlog events in '指定二進制日誌文件名稱' from （從指定位置開始顯示） limit （須要顯示的事件數量）\G; //查看binlog中事件 mysql> show binary logs; //顯示全部的binlogs mysql> reset master; //刪除全部二進制日誌文件並清空索引文件 mysql> reset slave; //刪除slave上覆制用的全部文件從新開始 mysql> show slave hosts; //查看主庫所擁有的從庫信息
5 從庫延遲較大
若是發現從庫延遲較大，就須要找到延遲大的緣由。參數 innodb_flush_log_at_trx_commit對mysql的寫入效率影響較大，有三個取值：
0：每隔一秒，把事務日誌緩存區的數據寫到日誌文件中，以及把日誌文件的數據刷新到磁盤上； 1：每一個事務提交時候，把事務日誌從緩存區寫到日誌文件中，而且刷新日誌文件的數據到磁盤上； 2：每事務提交的時候，把事務日誌數據從緩存區寫到日誌文件中；每隔一秒，刷新一第二天志文件，但不必定刷新到磁盤上，而是取決於操做系統的調度；
取1時的IO耗費最大，雖然一致性和完整性方面效果最好，可是寫入效率最低，而這也是致使從庫延遲較大的緣由（若是服務器配置較高或許會好些）。取0時mysql寫入性能很好，但若是 mysqld 進程崩潰，一般會致使最後 1s 的日誌丟失 。取2時的寫入性能也很好，每次事務提交會寫入日誌文件，但並不會當即刷寫到磁盤，日誌文件會每秒刷寫一次到磁盤。這時若是 mysqld 進程崩潰，因爲日誌已經寫入到系統緩存，因此並不會丟失數據；在操做系統崩潰的狀況下，一般會致使最後 1s 的日誌丟失。
6 混合模式複製
正常狀況下使用使用基於語句的複製，而對不安全的語句則切換到基於行的複製。主要有如下幾種狀況：
- 該語句調用了：一個語句同時更新了兩個或者兩個以上含有AUTO_INCREMENT列的表
- UUID函數
- 用戶自定義函數
- CURRENT_USER或USER函數
- LOAD_FILE函數
- 語句使用了服務器變量
- 存儲引擎不容許使用基於語句的複製，例如，mysql cluster引擎
7 複製過濾
有時候咱們不須要對數據庫中全部的庫進行復制，或者不想對指定庫中的某些表進行復制操做，那麼咱們就須要對複製進行必定的過濾配置，以達到更合理的複製效果。
1. 基於master
**binlog-do-db=mysql**：主庫只是將指定庫(mysql)發生的變化記錄到二進制日誌中。 **binlog-ignore-db=mysql**：主庫取消將指定庫(mysql)發生的變化記錄到二進制日誌中。
2. 基於slave
針對數據庫進行的過濾：
**replicate-do-db=mysql**：從庫只是將指定庫(mysql)發生的變化進行重現。 **replicate-ignore-db=mysql**：從庫取消將指定庫(mysql)發生的變化進行重現。 針對表進行的過濾： **replicate-wild_do-table=mysql.learn**：從庫只是將指定庫(mysql)中指定表(learn)發生的變化進行重現。 **replicate-wild_ignore-table=mysql.learn**：從庫取消將指定庫(mysql)中指定表(learn)發生的變化進行重現。
以上覆制過濾方式乍一看沒有問題，其實仍是有須要注意的地方。由於這些過濾方式的效果與複製方式有關係。若是是基於語句的複製，binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db與跨庫(如use庫內和use外)有關係，這一點須要注意。
8 日誌清理
暴力清理：（沒有主從複製的狀況下）
一、重啓mysql服務器便可關閉bin日誌的記錄 二、經過reset master命令進行清理
條件清理
若是存在主從複製關係，則應當使用purge的方式來清理bin日誌，語法以下：
purge {master|binary} logs to 'log_name' purge {master|binary} logs before 'date'
用戶刪除列於在指定的日誌或日期以前的日誌索引中的全部二進制日誌，同時這些日誌也會從日誌索引文件的清單中刪除。
eg. purge master logs to 'mysql-bin.000005'; purge master logs before '2014-08-30 00:00:00';//清除指定日期以前的日誌 purge master logs before date_sub(now(),Interval 3 day);清除三天前的日誌
定時清理
參數：expire_logs_days
說明：二進制日誌自動刪除/過時的天數。默認值爲'0'，即沒有過時的
示例：expire_logs_days = 5，表明日誌的有效時間爲5天
何時會刪除過時日誌？
每次進行log flush的時候會自動刪除過時的日誌
何時會觸發log flush？
一、重啓 二、binlog文件的大小達到了最大限制 三、手動執行flush logs命令