一、單個數據庫服務器的缺點
-
數據庫服務器存在單點問題；
-
數據庫服務器資源無法滿足增長的讀寫請求；
- 高峯時數據庫連接數經常超過上限。
二、如何解決單點問題
-
增加額外的數據庫服務器，組建數據庫集羣；
-
同一集羣中的數據庫服務器需要具有相同的數據；
- 集羣中的任一服務器宕機後，其它服務器可以取代宕機服務器。
三、MySQL主從複製架構
1、主庫將變更寫入到主庫的binlog中
-
一些MySQL版本並不會開啓二進制日誌，所以一定要檢查是否開啓；
-
如果剛開始沒有開啓，後面再進行開啓的話，需要重啓數據庫才能生效，而且數據庫的重啓往往會對業務造成很大的影響；
- 儘管二進制日誌對性能有稍許的影響，所以還是建議大家無論是否使用複製功能，都要開啓MySQL二進制日誌，因爲增量備份也需要二進制日誌。
2、從庫的IO線程在指定位置讀取主庫binlog內容存儲到本地的中繼日誌（Relay Log）中
要完成二進制日誌的傳輸過程，MySQL會在從服務器上啓動一個工作線程，稱爲IO線程，這個IO線程會跟主數據庫建立一個普通的客戶端連接，然後在主服務器上啓動一個特殊的二進制轉儲線程稱爲binlogdown線程。
從庫上的IO線程通過這個二進制轉儲線程來讀取主庫上的二進制事件，如果該事件追趕上主庫，則會進入sleep狀態，直到主庫發起信號通知有新事件產生時，纔會被喚醒，relay log的格式和binlog格式是完全相同的，
可以使用mysqlbinlog來讀取relay log中的內容。
3、從庫的SQL線程讀取Relay Log日誌中的內容，並在從庫中重放
SQL線程所執行的事件，我們可以通過配置選項來決定是否要寫入到從服務器的二進制日誌中。
目前MySQL支持兩種複製類型：
-
基於二進制日誌點的複製
- 基於GTID的複製（MySQL>=5.7推薦使用）
四、MySQL主從配置步驟
1、配置主從數據庫服務器參數
有些參數配置後需要數據庫重啓才能生效，爲了不影響數據庫的正常使用，我們最好在服務器上線的同時就把參數都配置好。特別是master服務器的參數，更應該作爲服務器初始參數來進行配置。
master服務器：
slave 服務器：
2、在master服務器上創建用於複製的數據庫賬號
用於IO線程連接master服務器獲取binlog日誌，需要* REPLICATION SLAVE** 權限：
create user 'repl'@'ip段' identified by 'password';
grant replication slave on *.* to 'repl'@'ip段';3、備份master服務器上的數據並初始化slave服務器數據
建議主從數據庫服務器採用相同的MySQL版本；
建議使用全庫備份的方式初始化slave數據。
採用相同版本的好處：
我們可以使用全備的方式來初始化slave數據，還可以避免不同版本之間的差異造成數據庫同步失敗的問題。
如果我們使用的主從複製的服務器MySQL版本不同，則一定要注意master上的版本一定要低於slave服務器，不然同步的時候就可能出現錯誤。
由於我們演示過程中的MySQL服務器都是使用的MySQL5.7，所以我們可以使用全備的方式進行：
mysqldump --master-data=2 -uroot -p -A --single-transaction -R --triggers4、啓動基於日誌點的複製鏈路
在slave服務器上運行，MySQL命令：
CHANGE MASTER TO
MASTER_HOST= 'master_host_ip',
MASTER_USER= 'repl',
MASTER_PASSWORD = 'password',
MASTER_LOG_FILE='mysql_log_file_name',
MASTER_LOG_POS=xxxxxx;5、啓動基於GTID的複製鏈路
GTID：全局事務ID，GTID可以保證每一個在主上提交的事務，在複製集羣中可以生成一個唯一的ID值，要使用基於GTID的複製，我們要在主從複製的配置文件中同時加入以下配置項。
MySQL配置：
gtid_mode=on
# 是否啓動gtid模式，啓動了此模式會在二進制日誌中會額外記錄每個事務的GTID標識符
enforce-gtid-consistency
# 強制gtid一致性，用於保證啓動gtid後事務的安全
log-slave-updates = on
# mysql5.6一定要啓用參數，5.7可以不啓用MySQL命令：
CHANGE MASTER TO
MASTER_HOST= 'master_host_ip',
MASTER_USER= 'repl',
MASTER_PASSWORD = 'password',
MASTER_AUTO_POSITION=1;GTID複製的限制：
-
無法再使用create table ... select語句建立表，只能先create表，再insert數據；
-
無法在事務中使用create temporary table建立臨時表；
- 無法使用關聯更新同時更新事務表和非事務表。
4和5中選一個執行即可。
五. MySQL主從複製演示
1. 先對主服務器進行配置
由於主服務器一直在運行着，在生產環境中主服務器是很少會重啓的，如果主服務器重啓，會造成正常的業務訪問的中斷，所以在服務器啓動之前就啓動了二進制日誌。
這裏不需要重啓主服務器了，由於主服務器的默認server_id=1，我們雖然在配置文件中更改了它的值 ，但實際運行環境中並沒有改變。
我們可以查看一下當前server_id：
mysql> show variables like '%server_id%';可以通過以下命令動態的進行修改：
mysql> set global server_id = 100;2. 再對從服務器進行配置
修改完從服務器配置後，重啓MySQL服務器。如果使用的是MySQL5.7版本的需要注意：
-
MySQL5.7增加了server-uuid值，默認情況下載auto.cnf文件中，如果是使用的鏡像的方式安裝，可能大家的uuid一樣 ，所以需要把auto.cnf文件刪除掉。MySQL重啓後會自動重新生成uuid的值，這樣就可以保證不同服務器上的MySQL實例的uuid的值是不一樣的；
- 如果server-uuid的值相同，主從複製會出現問題。
以上我們就完成了主從複製的配置，接下來我們要在主服務器上建立複製賬號。
3. 在MySQL主服務器上建立MySQL複製賬號
mysql> create user 'dba_repl'@'192.168.3.%' identified by '123456';
mysql> grant replication slave on *.* to 'dba_repl'@'192.168.3.%';4. 建立好複製賬號以後，通過mysql主服務器上的全備初始化從服務器上數據
進行全備：
[root@localhost data]# cd /data/db_backup/
[root@localhost db_backup]# mysqldump -uroot -p --master-data=1 --single-transaction --routines --triggers --events --all-databases > all.sql
Enter password:將其拷貝到從服務器上：
[root@localhost db_backup]# scp all.sql [email protected]:/root在從服務器上恢復備份進行初始化：
[root@Node2 ~]# mysql -uroot -p < all.sql初始化完成後，準備。
5. 從服務器進行基於日誌點的複製鏈路的配置
mysql> change master to
master_host='192.168.3.100',
master_user='dba_repl',
master_password='123456',
MASTER_LOG_FILE='mysql-bin.000017',
MASTER_LOG_POS=663;
MASTER_LOG_FILE和MASTER_LOG_POS的值從全備文件中的CHANGE MASTER中獲取以上覆制鏈路的配置完成。
啓動slave：
mysql> start slave;檢查是否啓動成功狀態：
mysql> show slave status \G顯示：
Relay_Master_Log_File: mysql-bin.000017Slave_IO_Running：YesSlave_SQL_Running: Yes說明啓動成功了，可以在主服務器上插入數據，在從服務上查看數據是否同步過來了。
六. 主從複製的一些缺點
雖然主從複製增加了一個數據庫副本，但從數據庫和主數據庫的數據最終會是一致的。之所以說是最終一致，因爲MySQL複製是異步的，正常情況下主從複製數據之間會有一個微小的延遲。
通過這個數據庫副本看似解決了數據庫單點問題，但並不完美：因爲這種架構下，如果主服務器宕機，需要手動切換從服務器，業務中斷不能忍受，不能滿足應用高可用的要求。
如大家對內容有更多想法及建議，歡迎留言交流~