MySQL錯誤1118（42000）的MySQL 5.0到MySQL 5.5或以上版本

Original post: http://anothermysqldba.blogspot.com/2014/05/mysql-error-1118-42000-mysql-50-to.html 

所以，我最近有一個TB的數據庫，我不得不從MySQL 5.0升級到MySQL 5.5。
本博客文章將涉及以下內容：

• SQL_MODE
• innodb_strict_mode
• SLAVE IO_THREAD

在mysql_upgrade過程（其中做了mysqlcheck的），我很快發現了以下錯誤：

ERROR 1118 (42000) at line 23: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

於是我開始，我不得不先檢查幾件事情。

# The master DB was > select @@sql_mode;
+------------+
| @@sql_mode |
+------------+
| |
+------------+

新的數據庫是

mysql> select @@sql_mode;
+--------------------------------------------+
| @@sql_mode |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION | +--------------------------------------------+ 

好吧，我寧願有東西SQL_MODE了一個空值。
所以，我讓那去。

# MASTER SERVER
select @@innodb_strict_mode;
ERROR 1193 (HY000): Unknown system variable 'innodb_strict_mode'

# NEW SERVER mysql> select @@innodb_strict_mode;
+----------------------+
| @@innodb_strict_mode |
+----------------------+
| 1 |
+----------------------+

你可以閱讀更多有關在這裡設置：
http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-other-changes-strict-mode.html

mysql> SET GLOBAL innodb_strict_mode=0;

上面的命令讓我至少升級mysql的一個檢查表。 為了安全起見我還是成立了一個bash腳本來轉儲和加載所有的表。 （是他們的所有TBS）

不要走捷徑，並承擔一切正常。

如果您收到錯誤mysqldump的並重新加載該文件。 更好的是安全比遺憾以後。

一旦數據被加載到5.5 + I可以查看和調整變量。

所以，不用說這是要花費一些時間來轉儲和裝載數據的傳輸塊。 我想給所有從機的機會，我可以趕上盡可能快。 雖然我的shell腳本傾銷和加載數據，沒有理由的數據庫無法採集二進制日誌在此期間。

mysql> START SLAVE IO_THREAD ; 

所以，現在當我PROCESSLIST會顯示：

SELECT /*!40001 SQL_NO_CACHE */ * 

從站狀態顯示：
Slave_IO_Running：是
Slave_SQL_Running：無

因此，我收集日誌，而我清理數據庫。
這應該允許數據庫迅速趕上一次，我準備好了。