2. 程式人生 > >線上MYSQL同步報錯故障處理總結

線上MYSQL同步報錯故障處理總結

阿新 • • 發佈：2019-01-17

http://www.cnblogs.com/itcomputer/articles/5618907.html

前言

在發生故障切換後，經常遇到的問題就是同步報錯，資料庫很小的時候，dump完再匯入很簡單就處理好了，但線上的資料庫都150G-200G，如果用單純的這種方法，成本太高，故經過一段時間的摸索，總結了幾種處理方法。

生產環境架構圖

目前現網的架構，儲存著兩份資料，通過非同步複製做的高可用叢集，兩臺機器提供對外服務。在發生故障時，切換到slave上，並將其變成master，壞掉的機器反向同步新的master，在處理故障時，遇到最多的就是主從報錯。下面是我收錄下來的報錯資訊。

常見錯誤

最常見的3種情況

這3種情況是在HA切換時，由於是非同步複製，且sync_binlog=0，會造成一小部分binlog沒接收完導致同步報錯。

  • 第一種：在master上刪除一條記錄，而slave上找不到。 
    Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1; 
Can't find record in 't1', 
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; 
the event's master log mysql-bin.000006, end_log_pos 254
  • 第二種：主鍵重複。在slave已經有該記錄，又在master上插入了同一條記錄。 
    Last_SQL_Error: Could not execute Write_rows event on table hcy.t1; 
Duplicate entry '2' for key 'PRIMARY', 
Error_code: 1062; 
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924
  • 第三種：在master上更新一條記錄，而slave上找不到，丟失了資料。 
    Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1', 
Error_code: 1032; 
handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263

非同步半同步區別

  • 非同步複製

簡單的說就是master把binlog傳送過去，不管slave是否接收完，也不管是否執行完，這一動作就結束了.

  • 半同步複製

簡單的說就是master把binlog傳送過去，slave確認接收完，但不管它是否執行完，給master一個訊號我這邊收到了，這一動作就結束了。（谷歌寫的程式碼，5.5上正式應用。）

  • 非同步的劣勢

當master上寫操作繁忙時，當前POS點例如是10，而slave上IO_THREAD執行緒接收過來的是3，此時master宕機，會造成相差7個點未傳送到slave上而資料丟失。

特殊的情況

  • slave的中繼日誌relay-bin損壞。 
    Last_SQL_Error: Error initializing relay log position: I/O error reading the header from the binary log
Last_SQL_Error: Error initializing relay log position: Binlog has bad magic number; 
It's not a binary log file that can be used by this version of MySQL

這種情況SLAVE在宕機，或者非法關機，例如電源故障、主機板燒了等，造成中繼日誌損壞，同步停掉。

  • 人為失誤需謹慎：多臺slave存在重複server-id

這種情況同步會一直延時，永遠也同步不完，error錯誤日誌裡一直出現上面兩行資訊。解決方法就是把server-id改成不一致即可。

Slave: received end packet from server, apparent master shutdown:
Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000012' at postion 106

問題處理

刪除失敗

在master上刪除一條記錄，而slave上找不到。

Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1; 
Can't find record in 't1',
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; 
the event's master log mysql-bin.000006, end_log_pos 254

解決方法：

由於master要刪除一條記錄，而slave上找不到故報錯，這種情況主上都將其刪除了，那麼從機可以直接跳過。可用命令：

stop slave;
set global sql_slave_skip_counter=1;
start slave;

如果這種情況很多，可用我寫的一個指令碼skip_error_replcation.sh，預設跳過10個錯誤（只針對這種情況才跳，其他情況輸出錯誤結果，等待處理），這個指令碼是參考maakit工具包的mk-slave-restart原理用shell寫的，功能上定義了一些自己的東西，不是無論什麼錯誤都一律跳過。）

主鍵重複

在slave已經有該記錄，又在master上插入了同一條記錄。

Last_SQL_Error: Could not execute Write_rows event on table hcy.t1; 
Duplicate entry '2' for key 'PRIMARY', 
Error_code: 1062; 
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924

解決方法：

在slave上用desc hcy.t1; 先看下錶結構：

mysql> desc hcy.t1;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | NO   | PRI | 0       |       | 
| name  | char(4) | YES  |     | NULL    |       | 
+-------+---------+------+-----+---------+-------+

刪除重複的主鍵

mysql> delete from t1 where id=2;
Query OK, 1 row affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
……
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
mysql> select * from t1 where id=2;

在master上和slave上再分別確認一下。

更新丟失

在master上更新一條記錄，而slave上找不到，丟失了資料。

Last_SQL_Error: Could not execute Update_rows event on table hcy.t1; 
Can't find record in 't1', 
Error_code: 1032; 
handler error HA_ERR_KEY_NOT_FOUND; 
the event's master log mysql-bin.000010, end_log_pos 794

解決方法：

在master上，用mysqlbinlog 分析下出錯的binlog日誌在幹什麼。

/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000010 | grep -A '10' 794

#120302 12:08:36 server id 22  end_log_pos 794  Update_rows: table id 33 flags: STMT_END_F
### UPDATE hcy.t1
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='bbc' /* STRING(4) meta=65028 nullable=1 is_null=0 */
### SET
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='BTV' /* STRING(4) meta=65028 nullable=1 is_null=0 */
# at 794
#120302 12:08:36 server id 22  end_log_pos 821  Xid = 60
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email protected]_COMPLETION_TYPE*/;

在slave上，查詢下更新後的那條記錄，應該是不存在的。

mysql> select * from t1 where id=2;
Empty set (0.00 sec)

然後再到master檢視

mysql> select * from t1 where id=2;
+----+------+
| id | name |
+----+------+
|  2 | BTV  | 
+----+------+
1 row in set (0.00 sec)

把丟失的資料在slave上填補，然後跳過報錯即可。

mysql> insert into t1 values (2,'BTV');
Query OK, 1 row affected (0.00 sec)

mysql> select * from t1 where id=2;    
+----+------+
| id | name |
+----+------+
|  2 | BTV  | 
+----+------+
1 row in set (0.00 sec)

mysql> stop slave ;set global sql_slave_skip_counter=1;start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
……
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
……

中繼日誌損壞

slave的中繼日誌relay-bin損壞。

Last_SQL_Error: Error initializing relay log position: I/O error reading the header from the binary log
Last_SQL_Error: Error initializing relay log position: Binlog has bad magic number;  
It's not a binary log file that can be used by  this version of MySQL

手工修復

解決方法：找到同步的binlog和POS點，然後重新做同步，這樣就可以有新的中繼日值了。

例子：

mysql> show slave status\G;
*************************** 1. row ***************************
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 1191
               Relay_Log_File: vm02-relay-bin.000005
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1593
                   Last_Error: Error initializing relay log position: I/O error reading the header from the binary log
                 Skip_Counter: 1
          Exec_Master_Log_Pos: 821

Slave_IO_Running ：接收master的binlog資訊
                   Master_Log_File
                   Read_Master_Log_Pos

Slave_SQL_Running：執行寫操作
                   Relay_Master_Log_File
                   Exec_Master_Log_Pos

以執行寫的binlog和POS點為準。

Relay_Master_Log_File: mysql-bin.000010
Exec_Master_Log_Pos: 821

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=821;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)


mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.8.22
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 1191
               Relay_Log_File: vm02-relay-bin.000002
                Relay_Log_Pos: 623
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1191
              Relay_Log_Space: 778
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_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: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error:

Ibbackup

各種大招都用上了，無奈slave資料丟失過多，ibbackup（需要銀子）該你登場了。

Ibbackup熱備份工具，是付費的。xtrabackup是免費的，功能上一樣。

Ibbackup備份期間不鎖表，備份時開啟一個事務（相當於做一個快照），然後會記錄一個點，之後資料的更改儲存在ibbackup_logfile檔案裡，恢復時把ibbackup_logfile 變化的資料再寫入到ibdata裡。

Ibbackup 只備份資料（ ibdata、.ibd ），表結構.frm不備份。

下面一個演示例子：

備份：ibbackup /bak/etc/my_local.cnf /bak/etc/my_bak.cnf

恢復：ibbackup --apply-log /bak/etc/my_bak.cnf

[[email protected] etc]# more my_local.cnf 

datadir =/usr/local/mysql/data
innodb_data_home_dir = /usr/local/mysql/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /usr/local/mysql/data
innodb_buffer_pool_size = 100M
innodb_log_file_size = 5M
innodb_log_files_in_group=2



[[email protected] etc]# ibbackup /bak/etc/my_local.cnf /bak/etc/my_bak.cnf 

InnoDB Hot Backup version 3.0.0; Copyright 2002-2005 Innobase Oy
License A21488 is granted to vm01 ([email protected])
(--apply-log works in any computer regardless of the hostname)
Licensed for use in a computer whose hostname is 'vm01'
Expires 2012-5-1 (year-month-day) at 00:00
See http://www.innodb.com for further information
Type ibbackup --license for detailed license terms, --help for help

Contents of /bak/etc/my_local.cnf:
innodb_data_home_dir got value /usr/local/mysql/data
innodb_data_file_path got value ibdata1:10M:autoextend
datadir got value /usr/local/mysql/data
innodb_log_group_home_dir got value /usr/local/mysql/data
innodb_log_files_in_group got value 2
innodb_log_file_size got value 5242880

Contents of /bak/etc/my_bak.cnf:
innodb_data_home_dir got value /bak/data
innodb_data_file_path got value ibdata1:10M:autoextend

datadir got value /bak/data
innodb_log_group_home_dir got value /bak/data
innodb_log_files_in_group got value 2
innodb_log_file_size got value 5242880

ibbackup: Found checkpoint at lsn 0 1636898
ibbackup: Starting log scan from lsn 0 1636864
120302 16:47:43  ibbackup: Copying log...
120302 16:47:43  ibbackup: Log copied, lsn 0 1636898
ibbackup: We wait 1 second before starting copying the data files...
120302 16:47:44  ibbackup: Copying /usr/local/mysql/data/ibdata1
ibbackup: A copied database page was modified at 0 1636898
ibbackup: Scanned log up to lsn 0 1636898
ibbackup: Was able to parse the log up to lsn 0 1636898
ibbackup: Maximum page number for a log record 0
120302 16:47:46  ibbackup: Full backup completed!
[[email protected] etc]#
[[email protected] etc]# cd /bak/data/
[[email protected] data]# ls
ibbackup_logfile  ibdata1




[[email protected] data]# ibbackup --apply-log /bak/etc/my_bak.cnf 

InnoDB Hot Backup version 3.0.0; Copyright 2002-2005 Innobase Oy
License A21488 is granted to vm01 ([email protected])
(--apply-log works in any computer regardless of the hostname)
Licensed for use in a computer whose hostname is 'vm01'
Expires 2012-5-1 (year-month-day) at 00:00
See http://www.innodb.com for further information
Type ibbackup --license for detailed license terms, --help for help

Contents of /bak/etc/my_bak.cnf:
innodb_data_home_dir got value /bak/data
innodb_data_file_path got value ibdata1:10M:autoextend
datadir got value /bak/data
innodb_log_group_home_dir got value /bak/data
innodb_log_files_in_group got value 2
innodb_log_file_size got value 5242880

120302 16:48:38  ibbackup: ibbackup_logfile's creation parameters:
ibbackup: start lsn 0 1636864, end lsn 0 1636898,
ibbackup: start checkpoint 0 1636898


ibbackup: start checkpoint 0 1636898
InnoDB: Doing recovery: scanned up to log sequence number 0 1636898
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .....99
Setting log file size to 0 5242880
ibbackup: We were able to parse ibbackup_logfile up to
ibbackup: lsn 0 1636898
ibbackup: Last MySQL binlog file position 0 1191, file name ./mysql-bin.000010
ibbackup: The first data file is '/bak/data/ibdata1'
ibbackup: and the new created log files are at '/bak/data/'
120302 16:48:38  ibbackup: Full backup prepared for recovery successfully!

[[email protected] data]# ls
ibbackup_logfile  ibdata1  ib_logfile0  ib_logfile1

把ibdata1 ib_logfile0 ib_logfile1拷貝到從，把.frm也拷貝過去，啟動MYSQL後，做同步，那個點就是上面輸出的：

ibbackup: Last MySQL binlog file position 0 1191, file name ./mysql-bin.000010

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=1191;

Maatkit工具包

  • 簡介

maatkit是一個開源的工具包，為mysql日常管理提供了幫助。目前，已被Percona公司收購併維護。其中：

mk-table-checksum是用來檢測master和slave上的表結構和資料是否一致。

mk-table-sync是發生主從資料不一致時，來修復的。

這兩個工具包，沒有在現網實際操作的經驗，這裡僅僅是新技術探討和學術交流，下面展示下如何使用。

[[email protected]]# mk-table-checksum h=vm01,u=admin,p=123456 h=vm02,u=admin,p=123456 -d hcy -t t1
Cannot connect to MySQL because the Perl DBI module is not installed or not found.  
Run 'perl -MDBI' to see the directories that Perl searches for DBI.
If DBI is not installed, try:
  Debian/Ubuntu  apt-get install libdbi-perl
  RHEL/CentOS    yum install perl-DBI
  OpenSolaris    pgk install pkg:/SUNWpmdbi

提示缺少perl-DBI模組，那麼直接 yum install perl-DBI。

[[email protected] bin]# mk-table-checksum h=vm01,u=admin,p=123456 h=vm02,u=admin,p=123456 -d hcy -t t1
DATABASE TABLE CHUNK HOST ENGINE      COUNT         CHECKSUM TIME WAIT STAT  LAG
hcy      t1        0 vm02 InnoDB       NULL       1957752020    0    0 NULL NULL
hcy      t1        0 vm01 InnoDB       NULL       1957752020    0    0 NULL NULL

如果表資料不一致，CHECKSUM的值是不相等的。

解釋下輸出的意思：

DATABASE：資料庫名
TABLE：表名
CHUNK：checksum時的近似數值
HOST：MYSQL的地址
ENGINE：表引擎
COUNT：表的行數
CHECKSUM：校驗值
TIME：所用時間
WAIT：等待時間
STAT：MASTER_POS_WAIT()返回值
LAG：slave的延時時間

如果你想過濾出不相等的都有哪些表，可以用mk-checksum-filter這個工具，只要在後面加個管道符就行了。

[[email protected] ~]# mk-table-checksum h=vm01,u=admin,p=123456 h=vm02,u=admin,p=123456 -d hcy | mk-checksum-filter       
hcy      t2        0 vm01 InnoDB       NULL       1957752020    0    0 NULL NULL
hcy      t2        0 vm02 InnoDB       NULL       1068689114    0    0 NULL NULL

知道有哪些表不一致，可以用mk-table-sync這個工具來處理。

注：在執行mk-table-checksum時會鎖表，表的大小取決於執行的快慢。

MASTER上的t2表資料：                      SLAVE上的t2表資料：
mysql> select * from t2;                  mysql> select * from t2;    
+----+------+                             +----+------+
| id | name |                             | id | name |
+----+------+                             +----+------+
|  1 | a    |                             |  1 | a    | 
|  2 | b    |                             |  2 | b    | 
|  3 | ss   |                             |  3 | ss   | 
|  4 | asd  |                             |  4 | asd  |  
|  5 | ss   |                             +----+------+
+----+------+                             4 rows in set (0.00 sec)
5 rows in set (0.00 sec) 
                                          mysql> \! hostname; 
mysql> \! hostname;                       vm02       
vm01 

[[email protected] ~]# mk-table-sync --execute --print --no-check-slave --transaction --databases hcy h=vm01,u=admin,p=123456 h=vm02,u=admin,p=123456 
INSERT INTO `hcy`.`t2`(`id`, `name`) VALUES ('5', 'ss') /*maatkit src_db:hcy src_tbl:t2 src_dsn:h=vm01,p=...,u=admin dst_db:hcy dst_tbl:t2 
dst_dsn:h=vm02,p=...,u=admin lock:0 transaction:1 changing_src:0 replicate:0 bidirectional:0 pid:3246 user:root host:vm02*/;

它的工作原理是：先一行一行檢查主從庫的表是否一樣，如果哪裡不一樣，就執行刪除，更新，插入等操作，使其達到一致。表的大小決定著執行的快慢。

If C<--transaction> is specified, C<LOCK TABLES> is not used.  Instead, lock
and unlock are implemented by beginning and committing transactions.
The exception is if L<"--lock"> is 3.
If C<--no-transaction> is specified, then C<LOCK TABLES> is used for any
value of L<"--lock">. See L<"--[no]transaction">.
When enabled, either explicitly or implicitly, the transaction isolation level
is set C<REPEATABLE READ> and transactions are started C<WITH CONSISTENT
SNAPSHOT>

MySQL複製監控

MySQL常見錯誤型別

1005：建立表失敗
1006：建立資料庫失敗
1007：資料庫已存在，建立資料庫失敗
1008：資料庫不存在，刪除資料庫失敗
1009：不能刪除資料庫檔案導致刪除資料庫失敗
1010：不能刪除資料目錄導致刪除資料庫失敗
1011：刪除資料庫檔案失敗
1012：不能讀取系統表中的記錄
1020：記錄已被其他使用者修改
1021：硬碟剩餘空間不足，請加大硬碟可用空間
1022：關鍵字重複，更改記錄失敗
1023：關閉時發生錯誤
1024：讀檔案錯誤
1025：更改名字時發生錯誤
1026：寫檔案錯誤
1032：記錄不存在
1036：資料表是隻讀的，不能對它進行修改
1037：系統記憶體不足，請重啟資料庫或重啟伺服器
1038：用於排序的記憶體不足，請增大排序緩衝區
1040：已到達資料庫的最大連線數，請加大資料庫可用連線數
1041：系統記憶體不足
1042：無效的主機名
1043：無效連線
1044：當前使用者沒有訪問資料庫的許可權
1045：不能連線資料庫，使用者名稱或密碼錯誤
1048：欄位不能為空
1049：資料庫不存在
1050：資料表已存在
1051：資料表不存在
1054：欄位不存在
1065：無效的SQL語句，SQL語句為空
1081：不能建立Socket連線
1114：資料表已滿，不能容納任何記錄
1116：開啟的資料表太多
1129：資料庫出現異常，請重啟資料庫
1130：連線資料庫失敗，沒有連線資料庫的許可權
1133：資料庫使用者不存在
1141：當前使用者無權訪問資料庫
1142：當前使用者無權訪問資料表
1143：當前使用者無權訪問資料表中的欄位
1146：資料表不存在
1147：未定義使用者對資料表的訪問許可權
1149：SQL語句語法錯誤
1158：網路錯誤，出現讀錯誤，請檢查網路連線狀況
1159：網路錯誤，讀超時，請檢查網路連線狀況
1160：網路錯誤，出現寫錯誤，請檢查網路連線狀況
1161：網路錯誤，寫超時，請檢查網路連線狀況
1062：欄位值重複，入庫失敗
1169：欄位值重複，更新記錄失敗
1177：開啟資料表失敗
1180：提交事務失敗
1181：回滾事務失敗
1203：當前使用者和資料庫建立的連線已到達資料庫的最大連線數，請增大可用的資料庫連線數或重啟資料庫
1205：加鎖超時
1211：當前使用者沒有建立使用者的許可權
1216：外來鍵約束檢查失敗，更新子表記錄失敗
1217：外來鍵約束檢查失敗，刪除或修改主表記錄失敗
1226：當前使用者使用的資源已超過所允許的資源，請重啟資料庫或重啟伺服器
1227：許可權不足，您無權進行此操作
1235：MySQL版本過低，不具有本功能

複製監控指令碼

參考原文修改。

  • 原指令碼
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

    相關推薦

    線上MYSQL同步報錯故障處理總結

    http://www.cnblogs.com/itcomputer/articles/5618907.html 前言 在發生故障切換後，經常遇到的問題就是同步報錯，資料庫很小的時候，dump完再匯入很簡單就處理好了，但線上的資料庫都150G-200G，

    線上MYSQL同步報錯故障處理方法總結

    table 存在 index 刪除 查找 skip number hat rec 前言 在發生故障切換後，經常遇到的問題就是同步報錯，下面是最近收集的報錯信息。 記錄刪除失敗 在master上刪除一條記錄，而slave上找不到 Last_SQL_Error:

    線上MYSQL同步報錯故障處理方法總結(必看篇)

    前言在發生故障切換後，經常遇到的問題就是同步報錯，資料庫很小的時候，dump完再匯入很簡單就處理好了，但線上的資料庫都150G-200G，如果用單純的這種方法，成本太高，故經過一段時間的摸索，總結了幾種處理方法。生產環境架構圖目前現網的架構，儲存著兩份資料，通過非同步複製做的

    MySQL主從同步報錯故障處理記錄

    記錄 error start record master 前言在發生故障切換後，經常遇到的問題就是同步報錯，下面是最近收集的報錯信息。記錄刪除失敗在master上刪除一條記錄，而slave上找不到Last_SQL_Error: Could not execute Delete_rows e

    MYSQL啟動後報錯故障問題的解決辦法

    quit ... AI gin native with 錯誤日誌 查看 RR centos系統有一次異常關機後啟動mysql一直報錯#/etc/init.d/mysqld startStarting MySQL.. ERROR! The server quit withou

    mysql 5.7 基於GTID 主從同步的1236故障處理（其它事務故障等同）

    其它 top 處理 set tid gtid stop eve 1-1 登錄從庫 stop slave; 查看執行事務 show slave status\G Retrieved_Gtid_Set: ee3bdb44-f6a1-11e7-b194-005056a35fd4

    mysql儲存emoji表情報錯的處理方法【更改編碼為utf8mb4】

    utf-8編碼可能2個位元組、3個位元組、4個位元組的字元，但是MySQL的utf8編碼只支援3位元組的資料，而移動端的表情資料是4個位元組的字元。如果直接往採用utf-8編碼的資料庫中插入表情資料，Java程式中將報SQL異常： java.sql.SQLException: Incorrect st

    mysql存儲emoji表情報錯的處理方法【更改編碼為utf8mb4】

    ice filesyste 內容 except 位置 tween see red dir utf-8編碼可能2個字節、3個字節、4個字節的字符，但是MySQL的utf8編碼只支持3字節的數據，而移動端的表情數據是4個字節的字符。如果直接往采用utf-8編碼的數據庫中插入表情

    Windows7 上連線 MySQL報錯問題處理

    在 win7上面連線 MySQL 報錯：ERROR 1045 (28000): Access denied for user 'ODBC'@'localhost' (using password: YES). 環境如下： win7 64位系統（32位也應該沒有關係把）

    mysql主從同步報錯 Got fatal error 1236 from master when reading data from binary log

    突然發現從庫不同步主庫了 ，不知道是什麼原因   來不及分析  只能先恢復 報錯；Got fatal error 1236 from master when reading data from binary log 剛開始怎麼的執行set global sql_slave

    [MySQL] MySQL主從同步報錯1236解決

    記一次MySQL主從同步1236報錯檔案解決。 報錯： Slave同步失敗報錯1236，日誌 mysql> show slave status \G *************************** 1. row **********************

    linux上 mysql主從報錯處理常見方式

    1：mysql從庫上，重置slave,重新指定master資訊    RESET SLAVE;    change master to master_host='主庫ip',master_user='zzh',master_password='Zzh91121

    service mysql start 報錯總結【全】

    在linux上安裝mysql後 啟動mysql，或者在使用mysql過程中啟動mysql 可能出現以下錯： 常見錯誤以下三種，可迴圈解決！  讓報錯無所遁形！！！ 報錯一： ERROR! MySQL is running but PID file coul

    處理mysql啟動報錯Table 'mysql.plugin' doesn't exis

    Installing MySQL system tables...2015-10-23 17:47:57 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_ti

    Navicat連線Mysql資料庫報錯，但是命令列可以連線上

    折騰了好幾天，本來mysql好好的，隔了一陣子後再去用navicat去連線，居然顯示 1045-access denied for user 'root'@'localhost' (using password: YES) 雖然不知道為什麼但還是去改了，於是

    WAS 管理節點和node同步報錯

    system request generate 同步WAS管理節點和node報如下錯誤：[17-5-28 20:42:04:546 CST] 00000082 NodeSync E ADMS0005E: The system is unable to generate synchro

    ORA-12547: TNS:lost contact報錯的處理方法

    oracle ora-12547最近兩天在虛擬機上搞Oracle 12.2的安裝，安裝的過程挺順利的。但虛擬機重啟之後就無法連接數據庫，執行sqlplus / as sysdba報錯ORA-12547: TNS:lost contact為什麽呢？安裝完後測試都好好的，怎麽重啟之後會這樣呢。在網上找了很多方法來

    【ORACLE】ORA-27102: out of memory報錯的處理

    trac conf error 一個 linu erro 大小 spfile target ************************************************************************ ****原文：blog

    MySql啟動報錯,無法更新PID文件

    mysql error pidMySql啟動報錯Starting MySQL.. ERROR! The server quit without updating PID file (/var/lib/mysql..）1，查看錯誤日誌 2017-08-10 19:38:14 31865 [Note] In

    Mysql安裝報錯解決辦法

    base edi 註意 eve program 搜索 重新啟動 5.1 edit .msi版MySQL安裝包在安裝最後執行的時候到第三部或者第四部死掉 主要是因為之前安裝的版本沒有卸載幹凈，要卸載幹凈MySQ安裝包有一些幾個步驟： 1.通過卸載程序MySQL的相關組件 2。