很久之前写过《MySQL 5.1的主从配置》,如今MySQL已经发布了5.6.10,在主从复制功能上做了很多优化,特别是GTID(Global Transact
很久之前写过《MySQL 5.1的主从配置》,如今MySQL已经发布了5.6.10,在主从复制功能上做了很多优化,特别是GTID(Global Transaction ID)的引入, 值得再重新写一篇文章介绍如何配置MySQL 5.6.10的主从复制。
相关阅读:
MySQL 5.6主从复制第一部分[简介及配置]
MySQL 5.6主从复制第二部分[恢复某一台从服务器]
MySQL 5.6主从复制第三部分[把从服务器提升为主服务器]
MySQL 5.6主从复制第四部分[一些被忽视的操作细节]
MySQL 主从复制事件校验 MySQL Replication Event Checksum
使用pt-table-checksum检查主从复制是否正常
----------------------------------------分割线----------------------------------------
还是用mysql::sandbox来测试吧。
主服务器(别名black)安装在 /home/modify/sandboxes/msb_5_6_10/ 使用5610端口。
从服务器(别名blue)安装在 /home/modify/sandboxes/msb_5_6_10_a/ 使用5611端口。
第一步,修改配置文件
修改主服务器配置文件my.sandbox.cnf,添加下面的几行:
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=1
report-port=5610
port=5610
log-bin=black-bin.log
report-host=black
innodb_flush_log_at_trx_commit=1
sync_binlog=1
修改从服务器配置文件,添加下面几行:
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=2
report-port=5611
port=5611
log-bin=blue-bin.log
report-host=blue
innodb_flush_log_at_trx_commit=1
sync_binlog=1
可以看到主与从的配置文件基本上是相同的,这样也便于在主服务器挂掉的时候,不用修改配置文件即可把从服务器提升为主。
下面简单介绍每一行的含义:
binlog-format
采用了row-based, 传说5.6对row-based replication做了优化,具体不明。
gtid-mode与enforce-gtid-consistency
决定使用gtid。
传统方式下,主从是基于master binary logfile 与 binary logfile postition的,
当主服务器挂掉,需要把某个从服务器提升为主的时候,需要做很多工作,
主要原因还是在于主从复制其实是异步的,
导致多台从服务器间的数据不一致,有的同步速度快,,有的速度慢, 很有可能每一台从服务器上面的Read_Master_Log_Pos都是不同的。
首先要根据Read_Master_Log_Pos来确定每台从服务器缺少binlog中的哪些transactions(evens),帮它们补充完之后,
从服务器间的数据完全一致了,然后才能把任意一台从服务器提升为主。
这个过程,人工做起来实在是比较痛苦,还好有一些开源的第三方程序可以自动做到,比如MHA。

MySQL是一種開源的關係型數據庫管理系統,主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據,以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題,優化建議包括使用索引、優化查詢和分錶分區。

MySQL是一個開源的關係型數據庫管理系統,適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統,廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎,MySQL高效處理數據。 3.基本用法包括創建數據庫和表,插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能,支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎,支持事務和查詢優化。 3.易於使用,支持多種操作系統和編程語言。 4.擁有強大的社區支持,提供豐富的資源和解決方案。

InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合,確保數據一致性。

MySQL查询性能不佳的原因主要包括没有使用索引、查询优化器选择错误的执行计划、表设计不合理、数据量过大和锁竞争。1.没有索引导致查询缓慢,添加索引后可显著提升性能。2.使用EXPLAIN命令可以分析查询计划,找出优化器错误。3.重构表结构和优化JOIN条件可改善表设计问题。4.数据量大时,采用分区和分表策略。5.高并发环境下,优化事务和锁策略可减少锁竞争。

在數據庫優化中,應根據查詢需求選擇索引策略:1.當查詢涉及多個列且條件順序固定時,使用複合索引;2.當查詢涉及多個列但條件順序不固定時,使用多個單列索引。複合索引適用於優化多列查詢,單列索引則適合單列查詢。

要優化MySQL慢查詢,需使用slowquerylog和performance_schema:1.啟用slowquerylog並設置閾值,記錄慢查詢;2.利用performance_schema分析查詢執行細節,找出性能瓶頸並優化。

MySQL和SQL是開發者必備技能。 1.MySQL是開源的關係型數據庫管理系統,SQL是用於管理和操作數據庫的標準語言。 2.MySQL通過高效的數據存儲和檢索功能支持多種存儲引擎,SQL通過簡單語句完成複雜數據操作。 3.使用示例包括基本查詢和高級查詢,如按條件過濾和排序。 4.常見錯誤包括語法錯誤和性能問題,可通過檢查SQL語句和使用EXPLAIN命令優化。 5.性能優化技巧包括使用索引、避免全表掃描、優化JOIN操作和提升代碼可讀性。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

記事本++7.3.1
好用且免費的程式碼編輯器

MinGW - Minimalist GNU for Windows
這個專案正在遷移到osdn.net/projects/mingw的過程中,你可以繼續在那裡關注我們。 MinGW:GNU編譯器集合(GCC)的本機Windows移植版本,可自由分發的導入函式庫和用於建置本機Windows應用程式的頭檔;包括對MSVC執行時間的擴展,以支援C99功能。 MinGW的所有軟體都可以在64位元Windows平台上運作。

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能

SublimeText3 Linux新版
SublimeText3 Linux最新版