亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

MySQL 升級方法指南大全

系統 1847 0
原文: MySQL?升級方法指南大全

通常,從一個發布版本升級到另一個版本時,我們建議按照順序來升級版本。例如,想要升級 MySQL 3.23 時,先升級到 MySQL 4.0,而不是直接升級到 MySQL 4.1 或 MySQL 5.0。
如果都是比較新的版本的升級可以參考下面的文章,
MySQL數據庫的版本更新很快,新的特性也隨之不斷的更新,更主要的是解決了很多影響我們應用的BUG,為了讓我們的MySQL變得更美好,我們有必要去給它升級,盡管你會說它現在已經跑得很好很穩定完全夠用了。下面我們來看看幾種常用的升級方法。

介紹之前,我們先做一些聲明,MySQL采用二進制包來安裝,升級都是在同一臺DB Server上操作。

第一種,很簡單,適用于任何存儲引擎。

1. 下載并安裝好新版本的MySQL數據庫,并將其端口改為3307(避免和舊版本的3306沖突),啟動服務。

2. 在新版本下創建同名數據庫。

# mysqldump -p3307 -uroot create mysqlsystems_com

3. 在舊版本下備份該數據庫。

# mysqldump -p3306 -uroot mysqlsystems_com > mysqlsystems_com.bk

Note: 你也可以加上–opt選項,這樣可以使用優化方式將你的數據庫導出,減少未知的問題。

4. 將導出的數據庫備份導入到新版本的MySQL數據庫中。

# mysql -p3307 -uroot mysqlsystems_com < mysqlsystems_com.bk

5. 再將舊版本數據庫中的data目錄下的mysql數據庫全部覆蓋到新版本中。

# cp -R /opt/mysql-5.1/data/mysql /opt/mysql-5.4/data

Note: 大家也都知道這個默認數據庫的重要性。

6. 在新版下執行mysql_upgrade命令,其實這個命令包含一下三個命令:

# mysqlcheck –check-upgrade –all-databases –auto-repair
# mysql_fix_privilege_tables
# mysqlcheck –all-databases –check-upgrade –fix-db-names –fix-table-names

Note: 在每一次的升級過程中,mysql_upgrade這個命令我們都應該去執行,它通過mysqlcheck命令幫我們去檢查表是否兼容新版本的數據庫同時作出修復,還有個很重要的作用就是使用mysql_fix_privilege_tables命令去升級權限表。

7. 關閉舊版本,將新版的數據庫的使用端口改為3306,重新啟動新版本MySQL數據庫。到此,一個簡單環境下的數據庫升級就結束了。


第二種,同樣適用任何存儲引擎。

1. 同樣先安裝好新版本的MySQL。

2. 在舊版本中,備份數據庫。

# mkdir /opt/mysqlsystems_bk ; mysqldump -p3306 -uroot –tab=/opt/mysqlsystems_bk mysqlsystems_com

Note: –tab選項可以在備份目錄mysqlsystems_bk下生成后綴為*.sql和*.txt的兩類文件;其中,.sql保存了創建表的SQL語句而.txt保存著原始數據。

3. 接下來在新版本的數據庫下更新數據。

# mysqladmin -p3307 -uroot create mysqlsystems_com

# cat /opt/mysqlsystems_bk*.TRG
啟動服務器,倒入觸發器:
mysql> delimiter // ;
mysql> source /tmp/triggers.sql //
不兼容的變化:MySQL 5.1.6引進了觸發器權限機制。以前,創建觸發器需要有 SUPER 權限,現在,這個操作只需要有 TRIGGER 權限。這改善了權限安全狀況
一些MySQL 5.1中作為保留關鍵字在MySQL 5.0中并沒有作為保留關鍵字
新引入了 "INSTALL PLUGIN" 和 "UNINSTALL PLUGIN" 語句用于操作API插件。同樣,創建 FULLTEXT 索引時,可以用 "WITH PARSER" 子句關聯解析器插件
3、從 MySQL 4.1 升級到 MySQL 5.0

服務器部分:

不兼容的變化:InnoDB 和 MyISAM 表中空格結尾的 TEXT 字段索引順序改變了。因此需要運行 "CHECK TABLE" 語句修復數據表,如果出現錯誤,就運行 "OPTIMIZE TABLE" 或 "REPAIR TABLE" 語句修復,甚至重新轉儲(用mysqldump)
不兼容的變化:從MySQL 5.0.15開始,如何處理 BINARY 字段中填充的值已經改變了。填充的值現在是 0x00 而非空格了,并且在取值的時候不會去除末尾的空格
不兼容的變化:從MySQL 5.0.3開始,DECIMAL 的實現方式已經改變了,5.0對 DECIMAL 的格式限制嚴格多了
不兼容的變化:在MySQL 5.0.3到5.0.5之間版本的 MyISAM 和 InnoDB 表中創建的 DECIMAL 字段升級到5.0.6之后會發生崩潰
不兼容的變化:從5.0.3開始,除非和主函數之間有輔助的符號鏈接,否則服務器將不再默認地加載用戶自定義函數(UDFs),也可以通過 --allow-suspicious-udfs 選項來啟用
不兼容的變化:5.0中禁用了更新日志(update log) ,不過可以用二進制日志(binary log)來代替它
不兼容的變化:5.0中不再支持 ISAM 類型存儲引擎(作者:可以通過重新編譯源代碼支持,不過非常不建議這么做)
不兼容的變化:5.0中不再支持 MyISAM 的 RAID 選項,可以用 mysqldump 導出舊表然后重新導回去實現升級
在5.0.6中,記錄存儲過程和觸發器的二進制日志發生了一些變化,詳見手冊的 "17.4 Binary Logging of Stored Routines and Triggers"
SQL部分:

不兼容的變化:從5.0.12開始,自然連接和使用 USING 的連接,包括外部連接的衍生形式,都按照SQL:2003標準來處理了;這個變化導致減少了自然連接和使用 USING 的連接產生的結果字段數,并且還將按照更合理的順序顯示這些字段,逗號比較符的優先順序和 JOIN, LEFT JOIN 中的一樣了
不兼容的變化:在以前,等待超時的鎖會導致 InnoDB 回滾當前全部事務,從5.0.13開始,就只回滾最近的SQL語句了
不兼容的變化:觸發器的變化,跟前面講到的一樣
不兼容的變化:從5.0.15開始,CHAR() 函數返回二進制字符串,而不是按照連接字符集格式的字符串。子句 USING charset_name 可以自定義返回結果的字符集
不兼容的變化:在5.0.13以前,NOW() 和 SYSDATE() 返回的結果一樣。但從5.0.13開始,SYSDATE() 返回的是語句執行點的時間,這就可能和 NOW() 返回的結果不一樣了,不過可以用 --sysdate-is-now 選項讓 SYSDATE() 作為 NOW() 的同名函數
不兼容的變化:在5.0.13以前,GREATEST(x,NULL) 和 LEAST(x,NULL) 如果 x 不是 NULL 值,則返回 x 。從5.0.13開始,只要任何參數是 NULL ,就返回 NULL,跟Oracle一樣
不兼容的變化:在4.1.13/5.0.8以前,DATETIME 的加0后就轉換成 YYYYMMDDHHMMSS 格式,現在變成 YYYYMMDDHHMMSS.000000 格式了
不兼容的變化:在4.1.12/5.0.6中,語句 LOAD DATA INFILE 和 SELECT ... INTO OUTFILE 中,當 FIELDS TERMINATED BY 和 FIELDS ENCLOSED BY 的值都是空的時候,結果就被改變了。以前,字段都按照它顯示的寬度來讀寫的。現在變成按照足夠保存字段值的寬度來讀寫它。然而,對MySQL 4.0.12/5.0.6來說,那些在它們之前導出來的文件可能無法正確用 LOAD DATA INFILE 語句導入
一些MySQL 5.0中作為保留關鍵字在MySQL 4.1中并沒有作為保留關鍵字
從5.0.3開始,DECIMAL 用更有效的格式來存儲
5.0.3開始,在計算 DECIMAL 值和舍入精確值的時候采用精確數學
4.1中,FLOAT 或 DOUBLE 之間的比較碰巧沒問題,但在5.0中可能就不行了
從5.0.3開始,VARCHAR 和 VARBINARY 字段中末尾的空格不再刪除
從5.0.3開始,BIT 是一個獨立的數據類型了,不再是 TINYINT(1) 的同名詞了
MySQL 5.0.2增加了一些SQL模式以使對排除包含非法或者缺失值得記錄有著更嚴格的控制
從5.0.2開始,關鍵字 SCHEMA 和 SCHEMAS 被認為分別是 DATABASE 和 DATABASES 的同名詞
5.0中用戶變量對大小寫不敏感,而4.1中則不然
增加了一個新的啟動選項 innodb_table_locks,它導致 LOCK TABLE 時也可以請求 InnoDB 表鎖。這個選項默認打開,不過可能在 AUTOCOMMIT=1 和 LOCK TABLES 應用中會導致死鎖
C API部分:

不兼容的變化:由于5.0中 DECIMAL 數據類型的實現方式發生了變化,因此如果使用就版本的庫文件需要注意這個問題
不兼容的變化:在5.0.3中,ER_WARN_DATA_TRUNCATED 警告符號改名為 WARN_DATA_TRUNCATED 了
MYSQL 結構體中的 reconnect 標志被 mysql_real_connect() 設為 0。
4、從 MySQL 4.0 升級到 MySQL 4.1

服務器部分:

不兼容的變化:以下好幾個都是需要重建數據表的,可以使用 mysqldump 導出表后重新導回去

如果在4.1.0到4.1.3版本的MySQL中創建了包含 TIMESTAMP 字段的 InnoDB 表。則在升級到4.1.4及更高時需要重建表,因為存儲格式發生變化了
從4.1.3開始,InnoDB 表采用同一種字符集比較函數來比較那些 非latin1_swedish_ci 字符集且不是 BINARY 的字符串
如果在4.1.0到4.1.5版本的MySQl中對 UTF8 字段或者其他多字節字段作了前綴索引,則在升級到4.1.6及更高時必須重建表
如果在4.1之前,數據庫、表、字段、約束名中使用了重音字符(字節值是128到255的字符),那么不能直接升級到4.1。因為4.1使用 UTF8 來存儲元數據名。
字符串根據標準SQL來比較:比較之前不刪除末尾的空格,以前用末尾空格擴展了比較短的字符串。現在的結果是 'a' > 'a\t',以前則不這樣。可以用 mysqlcheck 來檢查一下數據表
MyISAM 現在使用更好的校驗和算法了
不兼容的變化:MySQL把字符串類型字段的長度定義理解為字符長度而不是字節長度。
重要提示:MySQL 4.1用 UTF8 字符集存儲數據表名和字段名。如果有用標準 7字節 US-ASCII 范圍之外的字符作為表名/字段名的話,需要重建表
重要提示:升級到4.1.1或更高后,就很難降級回到4.0或4.1了,因為 InnoDB 使用了多個表空間的緣故
不兼容的變化:MySQL 4.1.13支持讓每個連接設定時區,因此系統變量 timezone 改成 system_time_zone
所有的數據表和非二進制字符串(CHAR, VARCHAR, 和 TEXT)的字段都有字符集,二進制字符串字段包括 BINARY, VARBINARY, 和 BLOB
MySQL4.0中,如果有字段類型為 CHAR BINARY 或 VARCHAR BINARY,則它們會被當作二進制字符串類型
如果數據表的字段中存儲著MySQL 4.1直接就能支持的字符集字符數據時,則可以將這個字段的值轉換成由合適的字符集存儲
MySQL 4.1中對數據結構描述文件 .frm 的格式稍作改進,新版本能兼容這個新格式,但是舊版本則不能
windows下的服務器啟動時增加 --shared-memory 選項即可支持從本地客戶端連接時使用共享內存
不兼容的變化:從MySQL 4.1.1開始,對用戶自定義函數集合接口發生了很大改進
不兼容的變化:從4.1.10a開始,除非和主函數之間有輔助的鏈接,否則服務器將不再默認地加載用戶自定義函數(UDFs),也可以通過 --allow-suspicious-udfs 選項來啟用
客戶端部分:

mysqldump 默認啟用 --opt 和 --quote-names 選項
SQL部分:

不兼容的變化:字符串根據標準SQL來比較,如上面的"服務器變化"部分中提到的
不兼容的變化:TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字符串。在MySQL 4.0中,可以增加選項 --new 來獲得MySQL 4.1中這方面的特性
不兼容的變化:二進制數據例如 0xFFDF 被當成字符串而非數字
不兼容的變化:在MySQL 4.1.1前,語句解析器不是那么嚴格,它在處理字符串轉時間轉換時會忽略第一個數字前的其他字符。在4.1.1之后,就比較嚴格了
不兼容的變化:在MySQL 4.1.2,SHOW TABLE STATUS 結果的 Type 字段改名為 Engine 了
當執行多表刪除語句時,要刪除的表只能使用它的別名,而不能用真實表名
返回結果是 DATE, DATETIME, 或 TIME 類型的函數的結果會被轉換成時間型
AUTO_INCREMENT 字段不能設定 默認(DEFAULT) 值了
LIMIT 不再接受負數參數了
SERIALIZE 不再是 sql_mode 變量的有效值了,它的取代值是 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
C API部分:

MySQL 4.1中的密碼哈希算法做了改進以提升安全性,不過會導致兼容性問題。使用MySQL 4.0及更早版本的客戶端庫文件會發生問題。

不兼容的變化:mysql_shutdown() 函數增加一個參數:SHUTDOWN-level
某些函數例如 mysql_real_query() 發生錯誤時返回 1 而非 -1
密碼處理部分:

MySQL 4.1中的密碼哈希算法做了改進以提升安全性,不過會導致兼容性問題。使用MySQL 4.0及更早版本的客戶端庫文件會發生問題。解決辦法有:

升級客戶端庫文件到4.1(不用升級服務器端庫文件)
運行 mysql_fix_privilege_tables 腳本來加寬 user 表中的 Password 字段值,以適應新的哈希算法。如果想要允許4.1以下的客戶端還能連接到服務器,那么服務器運行時要增加參數 --old-passwords
5、附錄

1、) 在Windows平臺上升級MySQL步驟:

備份舊數據
停止舊服務器
從windows的系統服務中刪掉mysql服務,用如下命令:
C:\> C:\mysql\bin\mysqld --remove用可執行安裝文件方式安裝mysql,或者解壓可直接執行的二進制壓縮包來安裝
重新注冊mysql服務,用如下命令:
C:\> C:\mysql\bin\mysqld --install 重啟服務器
其他的問題詳見上面提到的各種升級中會碰到的情況
2、) 升級授權表

升級授權表之前一定要備份好 mysql 數據庫,以備升級失敗時使用舊的授權表。

在unix或類unix系統中,運行 mysql_fix_privilege_tables 腳本來升級授權表:

shell> mysql_fix_privilege_tables 必須在 mysqld 運行著的時候執行這個腳本,它嘗試使用 root 帳號來連接服務器;因此,當 root 需要密碼時,用如下方式來指定密碼:

shell> mysql_fix_privilege_tables --password=root_password 在 MySQL 4.1之前,則是用如下形式來指定密碼:

shell> mysql_fix_privilege_tables root_password
接下來 mysql_fix_privilege_tables 腳本會升級授權表,在這個過程中可能會有一些 Duplicate column name 警告信息,無需理會它們。待它運行完之后,重啟一下服務器即可。

在windows平臺上,授權表想要升級到4.0.15并不容易。從4.0.15開始,發行版中包含一個sql腳本:mysql_fix_privilege_tables.sql,用 mysql 客戶端運行它來升級授權表,運行類似如下命令:

C:\> C:\mysql\bin\mysql -u root -p mysql
mysql> SOURCE C:/mysql/scripts/mysql_fix_privilege_tables.sql
把上面提到的目錄改成真實的目錄。

3、) 升級同步

請查看我翻譯的文檔"6.6 升級同步"

4、) mysql_update MySQL升級時檢查數據表

每次升級的時候都必須運行 mysql_upgrade 腳本。它檢查了當前版本的MySQL下的所有數據庫表的不兼容性,就會檢查這些表;并且發現有問題時,也會修復這些表。mysql_update 同時升級了系統表,因此可以兼容新的權限機制并且使用新增的權限。

由于 mysql_update 會把檢查過和修復過的表都標記上當前的MySQL版本號,因而保證了下一次在同一個MySQL版本下運行這個腳本時,都會再次報告哪些表需要修復或檢查。

它還會把MySQL的版本號記錄在數據文件目錄下的一個文件中:mysql_upgrade.info。這個文件用于標識當前發布版本檢查表時哪些表可以略過,檢查時想要忽略這個文件,只需附加上 --force 選項。

為了能檢查和修復數據表,并且升級系統表,mysql_update 執行了一下命令:

mysqlcheck --check-upgrade --all-databases --auto-repair
mysql_fix_privilege_tables
mysql_update 目前只支持類unix平臺;在windows下,需要手工執行 mysqlcheck 命令,升級授權表請看附錄"升級授權表"。

執行 mysql_update 時,MySQL服務器必須運行著,它有以下幾個參數:

--help
顯示幫助信息并且退出

--basedir=path
設定MySQL的安裝路徑

--datadir=path
設定MySQL的數據文件路徑

--force
告訴 mysql_update,在檢查時忽略是否存在 mysql_upgrade.info 文件,強行檢查該版本的MySQL數據表,不管是否已經檢查過了

--user=user_name, -u user_name
連接到MySQL的用戶名,默認是 root

--verbose
冗余模式。發生問題時打印出更多的信息

其他的選項諸如 --password[=password] 是要傳遞給 mysqlcheck 和 mysql_fix_privilege_tables 腳本的,并不是必須的。

MySQL?升級方法指南大全


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 国产97在线 | 亚洲 | 欧美刺激午夜性久久久久久久 | 亚洲综合资源 | 国产亚洲精品一区999 | 麻豆国产原创最新在线视频 | 欧美三级成人理伦 | 俄罗斯aaaa一级毛片 | 色综网| 成人动漫影院 | 日韩狠狠操 | 91尤物国产尤物福利 | 一级毛片免费在线观看网站 | 欧美日韩精品一区二区在线线 | 亚洲欧美中文日韩二区一区 | 一级黄色片免费 | 特级毛片全部免费播放a一级 | 国产一区二区三区免费播放 | 国产农村妇女毛片精品久久久 | 手机看片高清日韩精品 | 狠狠色狠狠色 | 国产精品亚洲片在线观看麻豆 | 日韩毛片免费线上观看 | 欧美三级午夜理伦三级小说 | 亚洲精品第五页中文字幕 | 国产精品亚洲综合色区韩国 | 欧美成人精品一区二区 | 精品一精品国产一级毛片 | 视频一区精品 | 亚洲精品久久久久久久久久久网站 | 九九爱www高清免费人成 | 国产亚洲精品久久久久久无 | 99r8这里精品热视频免费看 | 久久精品视频亚洲 | 国产成人青草视频 | 亚洲精品福利一区二区三区 | 婷婷色九月综合激情丁香 | 欧美日本一本线在线观看 | 极品吹潮视频大喷潮tv | 91精品国产乱码久久久久久 | 高清国产一区 | 国产人伦视频在线观看 |