Mysql數據庫主從同步常見問題合集及解決方法

Mysql數據庫主從同步常見問題合集:

1.Slave I/O: error connecting to master 'backup@192.168.1.x:3306'-retry-time: 60 retries: 86400,Error_code:1045

解決方法:

從服務器上刪除掉所有的二進制日志文件,包括一個數據目錄下的master.info文件和hostname-relay-bin開頭的文件。

master.info::記錄瞭Mysql主服務器上的日志文件和記錄位置、連接的密碼。

2. Errorreading packet from server: File '/home/mysql/mysqlLog/log.000001' not found(Errcode: 2) ( server_errno=29)

解決方法:

由於主服務器運行瞭一段時間,產生瞭二進制文件,而slave是從log.000001開始讀取的,刪除主機二進制文件,包括log.index文件。

3.Slave SQL: Error 'Table 'xxxx' doesn't exist' on query.Default database: 't591'.Query: 'INSERT INTO `xxxx`(type,post_id,browsenum)

SELECT type,post_id,browsenum FROM xxxx WHEREhitdate='20090209'', Error_code: 1146

解決方法:

由於slave沒有此table表,添加這個表,使用slave start 就可以繼續同步。

4.Error 'Duplicate entry '1' for key 1' on query. Default database: 'movivi1'. Query:'INSERT INTO `v1vid0_user_samename`

VALUES(null,1,'123','11','4545','123')'

Error 'You have an error in your SQL syntax; check themanual that corresponds to your MySQL server version for the right syntax

to use near '?' at line 1' on query. Default database:'club'. Query: 'INSERT INTO club.point_process ( GIVEID, GETID, POINT,CREATETIME, DEMO )

VALUES(0,4971112, 5,'2010-12-19 16:29:28',?'

1 row in set (0.00 sec)

Mysql> Slave status\G;

顯示:Slave_SQL_Running 為 NO

解決方法:

Mysql > stop slave;

Mysql > set global sql_slave_skip_counter =1 ;

Mysql > start slave;

5. show slavestatus\G;

Master_Log_File: mysql-bin.000029

Read_Master_Log_Pos: 3154083

Relay_Log_File: c7-relay-bin.000178

Relay_Log_Pos: 633

Relay_Master_Log_File: mysql-bin.000025

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB: club

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 1594

Last_Error: Relay log read failure: Could not parse relaylog event entry. The possible reasons are:

the master's binary log is corrupted (you can check thisby running 'mysqlbinlog' on the binary log),

the slave's relay log is corrupted (you can check this byrunning 'mysqlbinlog' on the relay log),

a network problem, or a bug in the master's or slave'sMySQL code. If you want to check the master's

binary log or slave's relay log, you will be ableto know their names by issuing 'SHOW SLAVE STATUS' on this slave.

Skip_Counter: 0

Exec_Master_Log_Pos: 1010663436

這個問題原因是,主數據庫突然停止或問題終止,更改瞭mysql-bin.xxx日志,slave服務器找不到這個文件,需要找到同步的點和日志文件,然後chage master即可。

解決方法:

change master to

master_host='IP',

master_user='同步帳號',

master_password='同步密碼',

master_port=3306,

master_log_file='mysql-bin.000025',

master_log_pos=1010663436;

6.Error'Unknown column 'qdir' in 'fieldlist''on query. Default database: 'club'. Query: 'insert into club.question_del(id, pid,

ques_name, givepoint, title, subject, subject_pid,createtime, approve, did, status, intime, order_d, endtime,banzhu_uid,

banzhu_uname,del_cause,qdir) select id, pid, ques_name,givepoint, title, subject, subject_pid, createtime, approve, did,

status, intime, order_d, endtime,'1521859','admin0523','無意義回復',qdir from club.question where id=7330212'

1 row in set (0.00 sec)

解決方案:

這個錯誤就說club.question_del 表裡面沒有qdir這個字段造成的加上就可以瞭~!

在主的mysql : 裡面查詢 Descclub.question_del;

在錯誤的從服務器上執行 : alter table question_del add qdirvarchar(30) not null;

7、Can't connect to MySQL server on 'localhost' (10061)

翻譯:不能連接到 localhost 上的mysql

分析:這說明“localhost”計算機是存在的,但在這臺機器上卻沒提供MySQL服務。

需要啟動這臺機器上的MySQL服務,如果機子負載太高沒空相應請求也會產生這個錯誤。

解決方案:既然沒有啟動那就去啟動這臺機子的mysql。如果啟動不成功,多數是因為你的my.ini配置的有問題。重新配置其即可。

如果覺得mysql負載異常,可以到mysql/bin 的目錄下執行mysqladmin -uroot -p123 processlist來查看mysql當前的進程。

8、Unknown MySQL Server Host 'localhosadst' (11001)

翻譯:未知的MySQL服務器 localhosadst

分析:服務器 localhosasdst 不存在。或者根本無法連接

解決方案:仔細檢查自己論壇下面的 ./config.inc.php 找到$dbhost重新設置為正確的mysql 服務器地址。

9、Access denied for user: 'roota@localhost' (Usingpassword: YES)

翻譯:用戶 roota 訪問 localhost 被拒絕(沒有允許通過)

分析:造成這個錯誤一般數據庫用戶名和密碼相對mysql服務器不正確

解決方案:仔細檢查自己論壇下面的 ./config.inc.php 找到$dbuser、$dbpw核實後重新設置保存即可。

10、Access denied for user: 'red@localhost' to database'newbbs'

翻譯:用戶 red 在localhost 服務器上沒有權限操作數據庫newbbs

分析:這個提示和問題三是不同的。那個是在連接數據庫的時候就被阻止瞭,而這個錯誤是在對數據庫進行操作時引起的。比如在select update等等。這個是因為該用戶沒有操作數據庫相應的權力。比如select這個操作在mysql.user.Select_priv裡記錄Y 可以操作N 不可以操作。

解決方案:如果是自己的獨立主機那麼更新mysql.user 的相應用戶記錄,比如這裡要更新的用戶為red 。或者直接修改 ./config.inc.php 為其配置一個具有對數據庫操作權限的用戶

或者通過如下的命令來更新授權grant all privileges on dbname.* to'user'@'localhost' identified by 'password’

提示:更新瞭mysql庫中的記錄一定要重啟mysql服務器才能使更新生效

FLUSH PRIVILEGES;

11、No Database Selected

翻譯:沒有數據庫被選擇上

分析:產生的原因有兩種

config.inc.php 裡面$dbname設置的不對。致使數據庫根本不存在,所以在 $db->select_db($dbname); 時返回瞭false

和上面問題四是一樣的,數據庫用戶沒有select權限,同樣會導致這樣的錯誤。當你發現config.inc.php的設置沒有任何問題,但還是提示這個錯誤,那一定就是這種情況瞭。

解決方案:對癥下藥

打開config.inc.php 找到$dbname核實重新配置並保存

同問題四的解決方法

12、Can't open file: 'xxx_forums.MYI'. (errno: 145)

翻譯:不能打開xxx_forums.MYI

問題分析:

這種情況是不能打開 cdb_forums.MYI 造成的,引起這種情況可能的原因有:

1、服務器非正常關機,數據庫所在空間已滿,或一些其它未知的原因,對數據庫表造成瞭損壞。

2、類 unix 操作系統下直接將數據庫文件拷貝移動會因為文件的屬組問題而產生這個錯誤。

解決方法:

1、修復數據表

可以使用下面的兩種方式修復數據表:(第一種方法僅適合獨立主機用戶)

1)使用 myisamchk ,MySQL 自帶瞭專門用戶數據表檢查和修復的工具 —— myisamchk 。更改當前目錄到 MySQL/bin 下面,一般情況下隻有在這個下面才能運行 myisamchk 命令。常用的修復命令為:myisamchk -r 數據文件目錄/數據表名.MYI;

2)通過 phpMyAdmin 修復, phpMyAdmin 帶有修復數據表的功能,進入到某一個表中後,點擊“操作”,在下方的“表維護”中點擊“修復表”即可。

註意:以上兩種修復方式在執行前一定要備份數據庫。

2、修改文件的屬組(僅適合獨立主機用戶)

1)復制數據庫文件的過程中沒有將數據庫文件設置為 MySQL 運行的帳號可讀寫(一般適用於 Linux 和 FreeBSD 用戶)。

13、Table 'test.xxx_sessions' doesn't exist

翻譯:xxxxx表不存在

分析:在執行sql語句時沒有找到表,比如:SELECT *FROM xxx_members WHERE uid=’XX’ 這裡如果表xxx_members不存在於$dbname庫裡,那麼就會提示這個錯誤。具體可分為以下三種情況來討論:

安裝插件或者hack時修改瞭程序文件,而忘記瞭對數據庫作相應的升級。

後臺使用瞭不完全備份,導入數據時沒有導入到已經安裝瞭相應版本的論壇的數據庫中。

解決方案: 同樣對癥下藥,不同的原因不同的處理方法。

仔細對照插件作者提供的安裝說明,把遺漏的對數據庫的操作補上,如果仍然不能解決問題,那麼應該懷疑該插件的可用性瞭。去咨詢一下插件作者,或者將其卸載。

不要張冠李戴,多大的腳就穿多大的鞋。總之使得程序文件和數據庫配套即可.

14、Unknown column 'column_name' in 'field list'

翻譯:未知的字段名 column_name

分析:在執行sql語句是出現瞭指定表中沒有的字段名稱,就會出現這個錯誤。具體導致的原因可分為以下兩種

安裝插件或者hack時修改瞭程序文件,而忘記瞭對數據庫作相應的升級。

程序文件和數據庫不配套,比如d2.5的數據庫配置給d4.1的程序來用肯定會出現這個錯誤。

解決方案:導致的原因和問題八的1和 3是相同的,所以解決方法也一樣。

15、You have an error in your SQL syntax

翻譯:有一個語法錯誤在你的sql中

分析:論壇標準的程序是沒有sql語法錯誤的。所以造成這個錯誤的原因一般就兩類

安裝插件或擅自修改程序。

不同的數據庫版本數據庫導出導入,比如MySQL4.1的數據在導出的語句包含瞭MySQL4.0沒有的功能,像字符集的設定,這時如果將這些sql導入到MySQL4.0的時候就會產生sql語法錯誤。

解決方案:仔細檢查看到底是哪裡的錯誤,將其修正,實在不行就用標準程序把出錯的程序替換。

在數據庫備份的時候要留意,如果不打算倒入到其他版本的mysql中則不用特殊考慮,反之要特殊的設定。使用DZ4.1的後臺數據備份,可以按照提示去設定想要的格式。獨立主機的也可以在到處的時候將其導出為mysql4.0的格式。

mysqldump -uroot -p –default-character-set=latin1 –set-charset=gbk –skip-optdatabse > test.sql

16、Duplicate entry 'xxx' for key 1

翻譯:插入 xxx 使索引1重復

分析:索引如果是primary unique這兩兩種,那麼數據表的數據對應的這個字段就必須保證其每條記錄的唯一性。否則就會產生這個錯誤。

一般發生在對數據庫寫操作的時候,例如Discuz!4.1論壇程序要求所有會員的用戶名username必須唯一,即username的索引是 unique,這時如果強行往cdb_members表裡插入一個已有的username的記錄就會發上這個錯誤,或者將一條記錄的username更新為已有的一個username。

改變表結構的時候也有可能導致這個錯誤。例如 Discuz!4.0論壇的數據庫中cdb_members.username 的索引類型是index這個時候是允許有相同username的記錄存在的,在升級到4.1的時候,因為要將username的索引由原來的index變 為unique。如果這時cdb_members裡存在有相同的username的記錄,那麼就會引發這個錯誤。

導出數據據時有時會因為一些原因(作者目前還不清楚)導致同一條記錄被重復導出,那麼這個備份數據在導入的時候出現這個錯誤是在所難免的瞭。

修改瞭auto_increment的值,致使“下一個 Autoindex”為一條已經存在的記錄

解決方案: 兩種思路,一是破壞掉唯一性的索引。二是把重復的數據記錄幹掉,隻保留一條。很顯然第一種思路是不可取的。那麼按照二的思路我們得出以下幾種解決方法,對應上面的i ii iii

按照錯誤提示裡的信息到數據庫中將重復的記錄刪除,僅保留一條即可。之後繼續執行升級操作。

這種情況發生的概率很小,可以用文本編輯器打開備份文檔,查找重復的信息。將其多餘的拿掉,僅保留一條即可。

查詢出表中auto_increment最大的一條記錄,設置auto_incerment比其大一即可。

PS:repaire table "表名“,可以暫時解決問題。

17、 Duplicate key name 'xxx'

翻譯:索引名重復

分析:要創建的索引已經存在瞭,就會引發這個錯誤,這個錯誤多發生在升級的時候。可能是已經升級過的,重復升級引起的錯誤。也有可能是之前用戶擅自加的索引,剛好與升級文件中的所以相同瞭。

解決方案: 看看已經存在的索引和要添加的索引是否一樣,一樣的話可以跳過這條sql語句,如果不一樣那麼現刪除已存在的所以,之後再執行。

18、 Duplicate column name 'xxx'

翻譯:字段名xxx重復

分析:添加的字段xxx已經存在,多發生在升級過程中,與問題十二的產生是一樣的。

解決方案: 看一下已經存在的字段是否和將要添加的字段屬性完全相同,如果相同則可以跳過不執行這句sql,如果不一樣則刪除掉這個字段。之後繼續執行升級程序。

19、 Table 'xxx' already exists

翻譯:數據表xxx已經存在

分析:xxx表已經存在於庫中,再次試圖創建這個名字的表就會引發這個錯誤。同樣多發生在論壇的升級中。類似於問題十二。

解決方案: 看看已經存在的表是否和將要創建的表完全一樣,一樣的話可以跳過不執行這個sql,否則請將存在的表先刪除,之後繼續執行升級文件。

20、 Can't create database 'xxx'. Database exists

翻譯:不能創建數據庫xxx,數據庫已經存在

分析:一個mysql下面的數據庫名稱必須保證唯一性,否則就會有這個錯誤。

解決方案:把已經存在的數據庫改名或者把將要創建的數據庫改名,總之不讓他們的名稱沖突。

21、 小結(針對問題 11\12\13\14\15)

此類問題錯誤提示中都暗藏一個關鍵詞duplicate(重復)

那麼對於mysql數據庫來說什麼東西是不能重復的呢?

數據庫 database

同一個數據庫下數據表 table

同一個數據表下字段 column

同一個數據表下索引 key

同一個數據表在索引唯一(UNIQUE PRIMARY)的情況下記錄中的這些字段不可以重復

22、Unknown system variable 'NAMES'

翻譯:未知的系統變量NAMES

分析:Mysql版本不支持字符集設定,此時強行設定字符集就會出現這個錯誤。

解決方案: 將sql語句中的SET NAMES ‘xxx’ 語句去掉

23、 Lost connection to MySQL server during query

翻譯:MySQL服務器失去連接在查詢期間

分析:遠程連接數據庫是有時會有這個問題。MySQL服務器在執行一條sql語句的時候失去瞭連接造成的。

解決方案: 一般不需要怎麼去處理,如果頻繁的出現那麼考慮改善硬件環境。

24、User 'red' has exceeded the 'max_updates' resource(current value: 500)

翻譯:msql用戶red已經超過瞭'max_updates'(最大更新次數),'max_questions'(最大查詢次數),'max_connections'(最大連接數),當前設定為500

分析:在mysql數據庫的下有一個庫為mysql,它其中有一個表為user這裡面的紀錄每一條都對應為一個mysql用戶的授權。其中字段 max_questions max_updates max_connections分別記錄著最大查詢次數 最大更新數 最大連接數,當目前的任何一個參數大於任何一個設定的值就會產生這個錯誤。

解決方案: 獨立主機用戶可以直接修改授權表。修改完之後重啟mysql或者跟新授權表,進入mysql提示符下執行

FLUSH PRIVILEGES;

記得後面要有分號’;’

虛擬主機的用戶如果總是出現這個問題可找空間商協商解決。

25、Too many connections (1040)鏈接過多

翻譯:達到最大連接數

問題分析:

連接數超過瞭mysql設置的值,與max_connections和wait_timeout 都有關系。wait_timeout的值越大,連接的空閑等待就越長,這樣就會造成當前連接數越大

解決方案:

1.虛擬主機用戶請聯系空間商優化 MySQL 服務器的配置;

2.獨立主機用戶請聯系服務器管理員優化 MySQL 服務器的配置,可參考:

修改 MySQL 配置文件 my.ini 或者 my.cnf 中的參數:

max_connections= 1000

wait_timeout = 10

修改後重啟 MySQL ,如果經常性的報此錯誤,請做一下服務器的整體優化。

26、There is no such grant defined for user '%s' on host'%s'

錯誤編號:1141

問題分析:

MySQL 當前用戶無權訪問數據庫。

解決方案:

1、虛擬主機用戶請聯系空間商,確認給你提供的帳號是否有授權數據庫的權限。

2、獨立主機用戶請聯系服務器管理員,確認給您提供的數據庫帳號是否有管理此數據庫的權限。

27、Error on rename of '%s' to '%s' (errno: %d)

error.:1025

問題分析:

請檢查一下您的程序是否有修改數據庫表名的語句。

解決方案:

1.請檢查您的程序中哪些地方需要修改數據庫表名;

2.如果您的實際應用確實需要修改到數據庫表名的話,請聯系空間商或者服務器管理員給您開放修改庫名的權限和服務器本身是否正常。

28、Error reading file '%s' (errno: %d)

error.:1023

問題分析:

數據庫文件不能被讀取。

解決方案:

1.虛擬主機用戶請聯系空間商查看數據庫是否完好。

2.獨立主機用戶請聯系服務器管理員檢查一下 MySQL 本身是否正常, MySQL 是否可以讀取文件,Linux 用戶可以檢查一下 MySQL 的數據庫文件的屬主是否正確以及本身的文件是否損壞。

29、Host '*****' is blocked because of many connectionerrors; unblock with 'mysqladmin flush-hosts'

error.:1129

問題分析:

數據庫出現異常,請重啟數據庫。

解決方案:

1. 由於存在很多連接錯誤,主機'****'被屏蔽,虛擬主機用戶請聯系空間商處理,獨立主機用戶請聯系服務器管理員,在 MySQL 的命令控制臺下執行'mysqladmin flush-hosts'解除屏蔽即可,或者重啟 MySQL 數據庫

30、dropping database (can't delete '%s', errno: %d)

error.:1009

問題分析:

不能刪除數據庫文件,導致刪除數據庫失敗。

解決方案:

1.檢查您使用的數據庫管理帳號是否有權限刪除數據。

2.檢查數據庫是否存在。

31、Got error 28 from table handler

error.:1030

問題分析:

數據庫所在磁盤空間已滿。

解決方案:

1.虛擬主機用戶請聯系空間商增加 MySQL 所在的磁盤空間或者清理一些無用文件;

2.獨立主機用戶請聯系服務器管理員增加 MySQL 所在的磁盤空間或者清理一些無用文件

32、Can't create a new thread; if you are not out ofavailable memory, you can consult the manual for a possible OS-dependent bug。

error.:11/35

問題分析:

數據庫服務器問題,數據庫操作無法創建新線程。一般是兩個原因:

1.服務器系統內存溢出。

2.環境軟件損壞或系統損壞。

解決方案:

1.虛擬主機用戶請聯系下空間商數據庫服務器的內存和系統是否正常。

2.獨立主機用戶請聯系服務器管理員檢查服務器的內存和系統是否正常,如果服務器內存緊張,請檢查一下哪些進程消耗瞭服務器的內存,同時考慮是否增加服務器的內存來提高整個的負載能力。

33、Error: Client does not support authentication protocolrequested by server; consider upgrading MySQL client

error.:1251

問題分析:

如果你升級 MySQL 到 4.1 以上版本後遇到以上問題,請先確定你的 MySQL Client 是 4.1 或者更高版本( Windows 下有問題你就直接跳到下面看解決方法瞭,因為 MySQL 在 Windows 是 client 和server 一起裝上瞭的)。

解決方案:

1. Windows 平臺

主要是改變連接 MySQL 的帳戶的加密方式,MySQL4.1/5.0 是通過 PASSWORD 這種方式加密的。可以通過以下兩種方法得到解決:

1) mysql->SET PASSWORD FOR'some_user'@'some_host'=OLD_PASSWORD('new_password');

2) mysql->UPDATE mysql.user SET Password=OLD_PASSWORD('new_password') WHEREHost='some_host' AND User='some_user';

2. Linux/Unix 平臺

Linux 平臺下首先確定是否安裝過 MySQL 的客戶端,這個用 rpm 安裝很簡單,Linux 代碼為:

rpm -ivh MySQL-client-4.1.15-0.i386.rpm

然後在編譯 php 的時候要加上:

–with-mysql=/your/path/to/mysql

一般情況下都可以解決。如果還出現這種錯誤,可以按照下面的方法來做:

mysql->SET PASSWORD FOR'some_user'@'some_host'=OLD_PASSWORD('new_password');

mysql->UPDATE mysql.user SET Password=OLD_PASSWORD('new_password') WHEREHost='some_host' AND User='some_user';

34、Error: Can't connect to local MySQL server throughsocket '/var/lib/mysql/mysql.sock'

error.:2002

問題分析:

出現這個錯誤一般情況下是因為下面兩個原因:

1.MySQL 服務器沒有開啟。

2.MySQL 服務器開啟瞭,但不能找到 socket 文件。

解決方案:

1.虛擬主機用戶,請聯系空間商確認數據庫是否正常啟動。

2.獨立主機用戶,請檢查一下 MySQL 服務是否已經開啟,沒有開啟,請啟動 MySQL 服務;如果已經開啟,並且是 Linux 系統,請檢查一下 MySQL 的 socket 的路徑,然後打開 config.inc.php 找到

$dbhost = 'localhost'; 在 hostname 後面加冒號‘:’和 MySQL 的 socket 的路徑。

比如 MySQL 服務器為 localhost

MySQL 的 socket 的路徑為/tmp/mysql.sock

那麼就改成如下:

$dbhost = 'localhost:/temp/mysql.sock';

35、Can't connect to MySQL server on 'localhost'

error.:2003

問題分析:

MySQL 服務沒有啟動,一般是在異常的情況下 MySQL 無法啟動導致的,比如無可用的磁盤空間,my.ini 裡 MySQL 的basedir 路徑設置錯誤等。

解決方案:

1.檢查磁盤空間是否還有剩餘可用空間,盡量保持有足夠的磁盤空間可用。

2.檢查 my.ini 裡的 basedir 等參數設置是否正確,然後重新啟動下 MySQL 服務。

36、Lost connection to MySQL server during query

error.:2013

問題分析:

數據庫查詢過程中丟失瞭與 MySQL 服務器的連接。

解決方案:

1.請確認您的程序中是否有效率很低的程序,比如某些插件,可以卸載掉插件,檢查一下服務器是否正常;

2.服務器本身資源緊張,虛擬主機用戶請聯系空間商確認,獨立主機用戶請聯系服務器管理員,檢查一下服務器是否正常。

37、Got a packet bigger than \'max_allowed_packet\' bytes

錯誤編號:1153

問題分析:調整瞭 Mantis 的上傳附件的大小卻沒有調整MySQL 的配置文件。

解決方案:

1、獨立主機用戶請按照以下方法調整:

查找 MySQL 的配置文件(my.cnf 或者 my.ini)

在 [mysqld] 部分添加一句(如果存在,調整其值就可以):

max_allowed_packet=10M

重啟 MySQL 服務就可以瞭。這裡設置的是 10MB。

2、虛擬主機用戶請聯系空間商調整此參數。

1.2 MySQL Replication常見錯誤

1.Last_SQL_Errno: 1677

Last_SQL_Error: Column 1 of table 'test.t' cannot be converted from type'int' to type 'bigint(20)'

解決方法:這個案例是從網上找到的,自己動手實驗瞭一把。從錯誤信息來看表面上是由於在slave上無法執行一條轉換字段類型的SQL語句。實際上並不是有這種語句直接引起的,而是間接引起的(之前某些操作導致主從表字段類型不一致,接下來對這個表進行DML時就會報錯)。它的意思是在對這個表t進行 DML操作時,發現主從上表結果不一致,比如這裡是說在主上t的字段1是int類型,但是從上t的字段1是bigint類型,所以報錯。那麼為什麼要報錯呢?這是從安全角度考慮,因為如果字段類型不一致可能會導致數據截斷之類的問題。那麼解決方法呢?通過參數slave_type_conversions 進行控制,它有三種取值:

ALL_LOSSY:僅支持有損轉換,什麼叫有損?比如一個值本來是bigint存儲為9999999999999,現在轉換為int類型勢必會要截斷從而導致數據不一致。

ALL_NON_LOSSY:僅支持無損轉換,隻能在無損的情況下才能進行轉換

ALL_LOSSY,ALL_NON_LOSSY:有損/無算轉換都支持

空,即不設置這個參數:必須主從的字段類型一模一樣。

註意: 前面說的這幾中情況都隻在binlog_format=ROW的情況下才有效。

2.Last_SQL_Errno: 1194

Last_SQL_Error: Error 'Table 'traincenter' is marked as crashedand should be repaired' on query.Default database: 'basketballman'. Query:'update traincenter set points='4',pointstime='1361912066' where uid ='1847482697' limit 1'

解決方法:myisam表traincenter損壞,直接repair table即可。至於為什麼myisam類型表比innodb更容易損壞,我覺得有兩個原因:1,innodb有double write機制,損壞或者half write的頁可以用它恢復,第二innodb是事務引擎,都有操作都是事務的,而myisam是非事務的,存在寫一半但是操作終止情況。

3.Last_IO_Errno: 1236

Last_IO_Error: Got fatal error 1236 from master when reading datafrom binary log: 'Could not find first log file name in binary log index file'

解決方法:主庫上的binlog文件已經不存在但是在index file中確有相應記錄存在。我這裡發生這個錯誤的原因在於由於復制中斷時間很長,報警出來一直沒人處理,這個中斷時間超過master上binlog超期時間,等恢復復制時需要的binlog已經由於其超期而被刪掉,沒辦法隻好重建這個實例瞭。以大傢都要引以為戒。

4.Last_IO_Errno: 1593

Last_IO_Error: Fatal error: The slave I/O thread stops becausemaster and slave have equal MySQL server ids; these ids must be different forreplication to work (or the –replicate-same-server-id option must be used onslave but this does not always make sense; please check the manual before usingit).

解決方法:主從配置的server-id一樣,而在主從復制環境中server-id一樣的binlog events都會被過濾掉。具體server-id的含義可以瞭解一下復制原理。這個一般是因為拷貝配置文件時忘記修改server-id導致,遇到這類問題也比較容易,平時操作謹慎一點即可。

5.Last_Errno: 1053

Last_Error: Query partially completed on the master (error on master:1053) and was aborted. There is a chance that your master is inconsistent atthis point. If you are sure that your master is ok, run this query manually onthe slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;START SLAVE; . Query: 'insert into …

解決方法:查詢在master上部分完成,然後終止瞭。這馬上又能想到是myisam表,結果也正是這樣。由於myisam不支持事務所以可能存在一個查詢完成一部分然後失敗的情況。解決方法一般也就是提示信息給出的跳過一個binlog event。不過確認跳過之前最好還是查詢一下master上是否真的存在相應的記錄,因為錯誤信息同時還會給出它認為在master上執行一部分然後終止的查詢語句。

6.Last_SQL_Errno: 1666

Last_SQL_Error: Error executing row event: 'Cannot executestatement: impossible to write to binary log since statement is in row formatand BINLOG_FORMAT = STATEMENT.'

解決方法:這個案例的背景是做一個ABC結構的復制,B、C中設定的binlog_format=statement,A中的是MIXED,所以當B嘗試 重做A過來的relay log,然後記錄binlog(傳給C)時發現relay log的binlog_format與自己設定的binlog_format不一致。我當時就是直接先更改BC的binlog_format=MIXED 解決。

7.Last_Errno: 1032

Last_Error: Could not execute Update_rows event on table db.table; Can'tfind record in 'table', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;the event's master log mysql-bin.000064, end_log_pos 158847

解決方法:這個是在binlog_format=row復制下發生的。原因是因為row格式復制是最嚴格的,所以在mysql看來如果在從庫上找不到要更新的這條記錄,那麼就代表主從數據不一致,因此報錯。另外順便說一句,對於row格式binlog,如果某個更新操作實際上並沒有更新行,這個操作是不會記binlog的,因為row格式的binlog宗旨就是隻記錄發生瞭改變的行。所以這個解決辦法根據你自己實際應用來定,最好的方法還是重做slave 吧,這樣更放心。

8.Last_Errno: 28

Last_Error: Error in Append_block event: write to'/tmp/SQL_LOAD-32343798-72213798-1.data' failed

解決方法:首先說錯誤原因:主庫執行load data infile,同步到從庫後load data infile存放的文件默認是放在/tmp(由參數slave_load_tmpdir控制),而/tmp空間不夠因此報錯。因此隻要將從庫上 slave_load_tmpdir設置到一個磁盤空間足夠大的分區就行。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。