mysql主備資料庫
1. 如何用mysql workbench做mysql主備
雙擊或右鍵打開MySQL Workbench，進入軟體主界面。
點擊new connection,會有個彈出框，讓我們填寫user(用戶名)，password(密碼)。
填寫完用戶名和密碼，點擊確定就會出現我們創建的資料庫工作空間，例如：local instance MySQL56。
雙擊local instance MySQL56，進入資料庫工作空間。
在左上方找到一個圓柱形帶加號的圖標，單擊該圖標，可以顯示出資料庫名讓我們填例如：。
創建好資料庫，我們在左菜單欄找到這個資料庫，雙擊該資料庫，可以看到下面有個tables,右鍵table，選擇create table，就能創建表了。
2. mysqlgoldendb出現主備庫關系修復失敗
需要登錄主庫進行一系列步驟來解決此問題。
登錄主庫，主從庫在同一台電腦，用埠號區分的，-h(ip地址可以不寫）。selectuser，hostfrommysql.user，查看允許訪問節點，showgrantsfor『boss』@』%』，查看賬號訪問許可權，鎖表，備份主資料庫，查看並找到主庫的data同步文件SK-20211222BOTJ-bin.000045並復制到從庫對應data目錄下，進入從庫、停止從庫、並導入主庫數據。重置從庫，配置從庫同步節點，進入主庫並解鎖主庫表，啟動從庫並查看配置是否成功。
3. mysql主備同步的原理
MYSQL主從同步原理：
1） MYSQL主從同步是非同步復制的過程，整個同步需要開啟3線程，master上開啟bin-log日誌（記錄資料庫增、刪除、修改、更新操作）；
2） Slave開啟I/O線程來請求master伺服器，請求指定bin-log中position點之後的內容；
3） Master端收到請求，Master端I/O線程響應請求，bin-log、position之後內容返給salve；
4） Slave將收到的內容存入relay-log中繼日誌中，生成master.info（記錄master ip、bin-log、position、用戶名密碼）；
5） Slave端SQL實時監測relay-log日誌有更新，解析更新的sql內容，解析成sql語句，再salve庫中執行；
6） 執行完畢之後，Slave端跟master端數據保持一致！
**MYSQL bin-log用途**
1） bin-log日誌最大的功能記錄資料庫增、刪、改、插入等操作，記錄用戶操作的SQL語句；
2） bin-log日誌可以用數據增量備份、完整備份；
3） bin-log還可以主要主從復制+讀寫分離；
4. MySQL實戰問題03 mysql如何保證主備一致
MySQL 主備的基本原理主備流程切換在狀態 1 中，客戶端的讀寫都直接訪問節點 A，而節點 B 是 A 的備庫，只是將 A 的更新都同步過來，到本地執行。這樣可以保持節點 B 和 A 的數據是相同的
當需要切換的時候，就切成狀態 2。這時候客戶端讀寫訪問的都是節點 B，而節點 A 是 B 的備庫。
M-S模式中, 為什麼建議把備庫設為readonly? 有時候一些運營類的查詢語句會被放到備庫上去查，設置為只讀可以防止誤操作； 防止切換邏輯有 bug，比如切換過程中出現雙寫，造成主備不一致 可以用 readonly 狀態，來判斷節點的角色。 把備庫設置成只讀了，還怎麼跟主庫保持同步更新呢？因為 readonly 設置對超級 (super) 許可權用戶是無效的，而用於同步更新的線程，就擁有超級許可權。
節點 A 到 B 這條線的內部流程是什麼樣的下圖畫出的就是一個 update 語句在節點 A 執行，然後同步到節點 B 的完整流程圖
備庫 B 跟主庫 A 之間維持了一個長連接。主庫 A 內部有一個線程，專門用於服務備庫 B 的這個長連接
一個事務日誌同步的完整過程是這樣的: 在備庫 B 上通過 change master 命令，設置主庫 A 的 IP、埠、用戶名、密碼，以及要從哪個位置開始請求 binlog，這個位置包含文件名和日誌偏移量。 在備庫 B 上執行 start slave 命令，這時候備庫會啟動兩個線程，就是圖中的 io_thread 和 sql_thread。其中 io_thread 負責與主庫建立連接。 主庫 A 校驗完用戶名、密碼後，開始按照備庫 B 傳過來的位置，從本地讀取 binlog，發給 B。 備庫 B 拿到 binlog 後，寫到本地文件，稱為中轉日誌（relay log）。 sql_thread 讀取中轉日誌，解析出日誌里的命令，並執行。 binlog 的三種格式對比三種格式分別是: statement row mixed
為了便於描述 binlog 的這三種格式間的區別, 創建並初始化一個表
mysql> CREATE TABLE `t` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `a` (`a`), KEY `t_modified`(`t_modified`) ) ENGINE=InnoDB; insert into t values(1,1,-11-13'); insert into t values(2,2,-11-12'); insert into t values(3,3,-11-11'); insert into t values(4,4,-11-10'); insert into t values(5,5,-11-09');刪除一行, 分析binlog
mysql> delete from t /*comment*/ where a>=4 and t_modified<=-11-10' limit 1; 查詢binlog命令: mysql> show binlog events in 'master.000001' 當 binlog_format=statement 時binlog 裡面記錄的就是 SQL 語句的原文:
分析一下上圖輸出的結果: 第一行可以先忽略. 第二行是一個 BEGIN，跟第四行的 commit 對應，表示中間是一個事務； 第三行是真實的執行語句, 在delete命令前,還有一個use test命令, 是mysql自動添加的. 最後一行是一個 COMMIT, 包含一個xid. 如果使用statement格式, 記錄到binlog 的是語句原文. 會有什麼問題出現呢?如果delete 帶有 limit, 很可能出出現住主備資料庫不一致的情況
在主庫執行這條 SQL 語句的時候，用的是索引 a；而在備庫執行這條 SQL 語句的時候，卻使用了索引 t_modified
當 binlog_format= row 時:與statement相比, begin 與 commit 是一致的, 但是row格式沒有記錄原文, 而是替換成了兩個event, 粉筆是table_map 與 delete_rows
Table_map event，用於說明接下來要操作的表是 test 庫的表 t; Delete_rows event，用於定義刪除的行為。 使用mysqlbinlog工具分析解析binlog中內容 mysqlbinlog -vv data/master.000001 --start-position=8900;解析結果:
server id 1，表示這個事務是在 server_id=1 的這個庫上執行的。 每個 event 都有 CRC32 的值，這是因為參數 binlog_checksum 設置成了 CRC32。 Table_map event 顯示了接下來要打開的表，map 到數字 226。現在我們這條 SQL 語句只操作了一張表，如果要操作多張表呢？每個表都有一個對應的 Table_map event、都會 map 到一個單獨的數字，用於區分對不同表的操作。 在 mysqlbinlog 的命令中，使用了 -vv 參數是為了把內容都解析出來，所以從結果裡面可以看到各個欄位的值（比如，@1=4、 @2=4 這些值）。 binlog_row_image 的默認配置是 FULL，因此 Delete_event 裡面，包含了刪掉的行的所有欄位的值。如果把 binlog_row_image 設置為 MINIMAL，則只會記錄必要的信息，在這個例子里，就是只會記錄 id=4 這個信息。 最後的 Xid event，用於表示事務被正確地提交了。 為什麼會有 mixed 格式的 binlog？為什麼會有 mixed 這種 binlog 格式的存在場景？ 因為有些 statement 格式的 binlog 可能會導致主備不一致，所以要使用 row 格式。 但 row 格式的缺點是，很占空間。比如你用一個 delete 語句刪掉 10 萬行數據，用 statement 的話就是一個 SQL 語句被記錄到 binlog 中，佔用幾十個位元組的空間。但如果用 row 格式的 binlog，就要把這 10 萬條記錄都寫到 binlog 中。這樣做，不僅會佔用更大的空間，同時寫 binlog 也要耗費 IO 資源，影響執行速度。 所以，MySQL 就取了個折中方案，也就是有了 mixed 格式的 binlog。mixed 格式的意思是，MySQL 自己會判斷這條 SQL 語句是否可能引起主備不一致，如果有可能，就用 row 格式，否則就用 statement 格式。 如何解決雙M結構的循環復制問題解決兩個節點間的循環復制的問題的邏輯 規定兩個庫的 server id 必須不同，如果相同，則它們之間不能設定為主備關系； 一個備庫接到 binlog 並在重放的過程中，生成與原 binlog 的 server id 相同的新的 binlog； 每個庫在收到從自己的主庫發過來的日誌後，先判斷 server id，如果跟自己的相同，表示這個日誌是自己生成的，就直接丟棄這個日誌。 按照這個邏輯，如果我們設置了雙 M 結構，日誌的執行流就會變成這樣： 從節點 A 更新的事務，binlog 裡面記的都是 A 的 server id； 傳到節點 B 執行一次以後，節點 B 生成的 binlog 的 server id 也是 A 的 server id； 再傳回給節點 A，A 判斷到這個 server id 與自己的相同，就不會再處理這個日誌。所以，死循環在這里就斷掉了。5. mysql主備切換是什麼意思
這一般是資料庫的安全策略，對於一些安全性要求比較高的系統，資料庫通常是由主伺服器和備份伺服器組成，主備同時運行，主伺服器有數據改動後，立刻會同步到備份伺服器。所以在日常運維工作中，為了防患於未然，經常會進行主備切換，就是把生產對接的伺服器從主資料庫切換到備份庫上，使用備份庫運行一段時間，看看備份庫運行是否正常，數據是否正確等。
切換的操作只需將連接池中，資料庫伺服器的Ip換成備份庫Ip就可以了。
6. mysql怎麼實現主從同步資料庫備份
1.主伺服器：
#Master start
log-bin="d:/log/mysql/mysql_log_bin"
server-id=1
#Master end
2.從伺服器：
#Slave start
log-bin="D:/log/mysql2/log-bin.log"
relay_log="D:/log/mysql2/relay-log-bin"
#從機id，區別於主機id
server-id=2
#主機ip，供從機連接主機用
#master-host=localhost
#主機埠
#master-port=3300
#剛才為從機復制主機數據新建的賬號
#master-user=slave
#剛才為從機復制主機數據新建的密碼
#master-password=654321
#重試間隔時間10秒
#master-connect-retry=10
#需要同步的資料庫
#replicate-do-db=test
#啟用從庫日誌，這樣可以進行鏈式復制
log-slave-updates
#從庫是否只讀，0表示可讀寫，1表示只讀
read-only=1
#只復制某個表
#replicate-do-table=tablename
#只復制某些表（可用匹配符）
#replicate-wild-do-table=tablename%
#只復制某個庫
#replicate-do-db=dbname
#不復制某個表
#replicate-ignore-table=tablename
#不復制某些表
#replicate-wild-ignore-table=tablename%
#不復制某個庫
#replicate-ignore-db=dbname
#Slave end
3.對從伺服器制定主伺服器使用CHANGE MASTER 語句
注意：1.一定要在主伺服器上創建一個可以執行replication的用戶
2.該用戶名在從伺服器上可遠程登錄到主伺服器。
3.開啟MySQL的log-bin日誌功能
7. 如何備份整個mysql資料庫
1、首先打開mysql資料庫軟體進入軟體主界面。
8. mysql主備之間使用什麼日誌文件同步
主從同步主要是以binlog日誌作為文件同步機制，具體如下
主從同步使得數據可以從一個資料庫伺服器復制到其他伺服器上，在復制數據時，一個伺服器充當主伺服器（master），其餘的伺服器充當從伺服器（slave）。因為復制是非同步進行的，所以從伺服器不需要一直連接著主伺服器，從伺服器甚至可以通過撥號斷斷續續地連接主伺服器。通過配置文件，可以指定復制所有的資料庫，某個資料庫，甚至是某個資料庫上的某個表。
使用主從同步的好處：
通過增加從伺服器來提高資料庫的性能，在主伺服器上執行寫入和更新，在從伺服器上向外提供讀功能，可以動態地調整從伺服器的數量，從而調整整個資料庫的性能。
提高數據安全-因為數據已復制到從伺服器，從伺服器可以終止復制進程，所以，可以在從伺服器上備份而不破壞主伺服器相應數據
在主伺服器上生成實時數據，而在從伺服器上分析這些數據，從而提高主伺服器的性能
注意，mysql是非同步復制的，而MySQL Cluster是同步復制的。有很多種主從同步的方法，但核心的方法有兩種，Statement Based Replication（SBR）基於SQL語句的復制，另一種是Row Based Replication（RBR）基於行的復制，也可以使用Mixed Based Replication（MBR）。在mysql5.6中，默認使用的是SBR。而mysql 5.6.5和往後的版本是基於global transaction identifiers(GTIDs)來進行事務復制。當使用GTIDs時可以大大簡化復制過程，因為GTIDs完全基於事務，只要在主伺服器上提交了事務，那麼從伺服器就一定會執行該事務。
9. 如何使用mysqlmp命令備份mysql資料庫
通用規律只有使用 --all-databases (-A) 會 ERROR 1356，那就看看他到底備份了什麼東西。於是喊上同事一起 less 看了下，上下掃了兩眼。突然發現：1. 備份 SQL 文件里 DROP 掉了 mysql.proc；2. 後CREATE了一個新的 mysql.proc；3. LOCK TABLES 和 UNLOCK TABLES 中間居然沒有備份 CREATE ROUTINE 任何數據？這不就是相當於每次導入全備都給我一個沒有任何 sys schema routines 的全新 mysql.proc 表？那這不就異常的尷尬？
---- Table structure for table `proc`--
---- Dumping data for table `proc`-
真相大白在官方文檔【sys-schema-usage】官方文檔明確的告訴我們不會備份 sys 庫。但在使用 mysqlmp 在執行 --all-databases 會清空 mysql.proc 導致 sys 無法正常使用；這是一個 BUG，並且只存在於 MySQL 5.7.x ！
1、mysql_upgrade install or upgrade sys schema
這個方案適用於 sys 庫已經因為 mysqlmp 導入而損壞的情況下使用。
注意：mysql_upgrade 在修理 sys 庫的同時，還修理 mysql 庫和用戶庫表（期間加鎖且速度一般），有極小可能會誤傷；使用 mysql_upgrade 的時候要加上 --upgrade-system-tables，不然會掃描用戶庫表。
2、全備時同時備份 sys 庫
這個方案適用於需要還原的資料庫，sys 庫也不太正常的情況下使用；在全備後額外再備份一份 sys 庫用於修復。
注意：不適用於做主從時使用它。
3、使用 databases 全備
這個方案適用於所有場景的全備需求，100% 安全。
4、使用 mysql-sys 開源代碼
如果你的資料庫 sys 全部中招了，又是生產庫。那你只能用這個方法；
mysql-sys：https://github.com/mysql/mysql-sys
中記錄了 sys 庫的創建語句將文件下載到本地，然後根據資料庫版本，執行以下命令即可。