<span id="mktg5"></span>

<i id="mktg5"><meter id="mktg5"></meter></i>

        <label id="mktg5"><meter id="mktg5"></meter></label>
        最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
        問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
        當(dāng)前位置: 首頁 - 科技 - 知識百科 - 正文

        [MySQL5.1體驗]MySQL復(fù)制

        來源:懂視網(wǎng) 責(zé)編:小采 時間:2020-11-09 15:39:36
        文檔

        [MySQL5.1體驗]MySQL復(fù)制

        [MySQL5.1體驗]MySQL復(fù)制:作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下
        推薦度:
        導(dǎo)讀[MySQL5.1體驗]MySQL復(fù)制:作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下

        作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下三種模式來實

        作/譯者:葉金榮(Email: ),來源:http://imysql.cn

        MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前
        的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下三種模式來實現(xiàn):基于SQL語句的復(fù)制(statement-based replication, SBR),基于行的復(fù)制(row-based replication, RBR),混合模式復(fù)制(mixed-based replication, MBR)。相應(yīng)地,binlog的格式也有三種:STATEMENT,ROW,MIXED。MBR 模式中,SBR 模式是默認(rèn)的。

        在運行時可以動態(tài)低改變binlog的格式,除了以下幾種情況:

      1. 存儲過程或者觸發(fā)器中間
      2. 啟用了NDB
      3. 當(dāng)前會話試用 RBR 模式,并且已打開了臨時表
      4. 如果binlog采用了 MIXED 模式,那么在以下幾種情況下會自動將binlog的模式由 SBR 模式改成 RBR 模式。

      5. 當(dāng)DML語句更新一個NDB表時
      6. 當(dāng)函數(shù)中包含 UUID() 時
      7. 2個及以上包含 AUTO_INCREMENT 字段的表被更新時
      8. 行任何 INSERT DELAYED 語句時
      9. 用 UDF 時
      10. 視圖中必須要求使用 RBR 時,例如創(chuàng)建視圖是使用了 UUID() 函數(shù)
      11. 設(shè)定主從復(fù)制模式的方法非常簡單,只要在以前設(shè)定復(fù)制配置的基礎(chǔ)上,再加一個參數(shù):

        binlog_format="STATEMENT"
        #binlog_format="ROW"
        #binlog_format="MIXED"

        當(dāng)然了,也可以在運行時動態(tài)修改binlog的格式。例如

        mysql> SET SESSION binlog_format = 'STATEMENT';
        mysql> SET SESSION binlog_format = 'ROW';
        mysql> SET SESSION binlog_format = 'MIXED';

        mysql> SET GLOBAL binlog_format = 'STATEMENT';
        mysql> SET GLOBAL binlog_format = 'ROW';
        mysql> SET GLOBAL binlog_format = 'MIXED';

        現(xiàn)在來比較以下 SBR 和 RBR 2中模式各自的優(yōu)缺點:
        SBR 的優(yōu)點:

      12. 歷史悠久,技術(shù)成熟
      13. binlog文件較小
      14. binlog中包含了所有數(shù)據(jù)庫更改信息,可以據(jù)此來審核數(shù)據(jù)庫的安全等情況
      15. binlog可以用于實時的還原,而不僅僅用于復(fù)制
      16. 主從版本可以不一樣,從服務(wù)器版本可以比主服務(wù)器版本高
      17. SBR 的缺點:

      18. 不是所有的UPDATE語句都能被復(fù)制,尤其是包含不確定操作的時候。
      19. 調(diào)用具有不確定因素的 UDF 時復(fù)制也可能出問題
      20. 使用以下函數(shù)的語句也無法被復(fù)制:
        * LOAD_FILE()
        * UUID()
        * USER()
        * FOUND_ROWS()
        * SYSDATE() (除非啟動時啟用了 --sysdate-is-now 選項)
      21. INSERT ... SELECT 會產(chǎn)生比 RBR 更多的行級鎖
      22. 復(fù)制需要進(jìn)行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時,需要比 RBR 請求更多的行級鎖
      23. 對于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 語句會阻塞其他 INSERT 語句
      24. 對于一些復(fù)雜的語句,在從服務(wù)器上的耗資源情況會更嚴(yán)重,而 RBR 模式下,只會對那個發(fā)生變化的記錄產(chǎn)生影響
      25. 存儲函數(shù)(不是存儲過程)在被調(diào)用的同時也會執(zhí)行一次 NOW() 函數(shù),這個可以說是壞事也可能是好事
      26. 確定了的 UDF 也需要在從服務(wù)器上執(zhí)行
      27. 數(shù)據(jù)表必須幾乎和主服務(wù)器保持一致才行,否則可能會導(dǎo)致復(fù)制出錯
      28. 執(zhí)行復(fù)雜語句如果出錯的話,會消耗更多資源
      29. RBR 的優(yōu)點:

      30. 任何情況都可以被復(fù)制,這對復(fù)制來說是最安全可靠的
      31. 和其他大多數(shù)數(shù)據(jù)庫系統(tǒng)的復(fù)制技術(shù)一樣
      32. 多數(shù)情況下,從服務(wù)器上的表如果有主鍵的話,復(fù)制就會快了很多
      33. 復(fù)制以下幾種語句時的行鎖更少:
        * INSERT ... SELECT
        * 包含 AUTO_INCREMENT 字段的 INSERT
        * 沒有附帶條件或者并沒有修改很多記錄的 UPDATE 或 DELETE 語句
      34. 執(zhí)行 INSERT,UPDATE,DELETE 語句時鎖更少
      35. 從服務(wù)器上采用多線程來執(zhí)行復(fù)制成為可能
      36. RBR 的缺點:

      37. binlog 大了很多
      38. 復(fù)雜的回滾時 binlog 中會包含大量的數(shù)據(jù)
      39. 主服務(wù)器上執(zhí)行 UPDATE 語句時,所有發(fā)生變化的記錄都會寫到 binlog 中,而 SBR 只會寫一次,這會導(dǎo)致頻繁發(fā)生 binlog 的并發(fā)寫問題
      40. UDF 產(chǎn)生的大 BLOB 值會導(dǎo)致復(fù)制變慢
      41. 無法從 binlog 中看到都復(fù)制了寫什么語句
      42. 當(dāng)在非事務(wù)表上執(zhí)行一段堆積的SQL語句時,最好采用 SBR 模式,否則很容易導(dǎo)致主從服務(wù)器的數(shù)據(jù)不一致情況發(fā)生
      43. 另外,針對系統(tǒng)庫 mysql 里面的表發(fā)生變化時的處理規(guī)則如下:

      44. 如果是采用 INSERT,UPDATE,DELETE 直接操作表的情況,則日志格式根據(jù) binlog_format 的設(shè)定而記錄
      45. 如果是采用 GRANT,REVOKE,SET PASSWORD 等管理語句來做的話,那么無論如何都采用 SBR 模式記錄
      46. 注:采用 RBR 模式后,能解決很多原先出現(xiàn)的主鍵重復(fù)問題。

        聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

        文檔

        [MySQL5.1體驗]MySQL復(fù)制

        [MySQL5.1體驗]MySQL復(fù)制:作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下
        推薦度:
        標(biāo)簽: 復(fù)制 體驗 5.1
        • 熱門焦點

        最新推薦

        猜你喜歡

        熱門推薦

        專題
        Top
        主站蜘蛛池模板: 日本特黄a级高清免费大片| 日本一道高清不卡免费| 伊人久久五月丁香综合中文亚洲| 69成人免费视频无码专区| 免费一区二区无码视频在线播放 | 日本免费A级毛一片| 亚洲性天天干天天摸| 女人被免费视频网站| 久久久WWW成人免费精品| 亚洲一区二区三区在线| 国产精品免费αv视频| 亚洲欧洲无码AV电影在线观看 | 亚洲av日韩综合一区久热| 久久久久亚洲爆乳少妇无| 免费看又黄又爽又猛的视频软件| 国产免费人人看大香伊| 国产亚洲精品美女久久久久久下载| 国产免费av片在线播放| 国产精品亚洲av色欲三区| 亚洲成AV人在线播放无码| 日韩免费高清视频| 日韩精品人妻系列无码专区免费 | 久久综合亚洲色hezyo| va亚洲va日韩不卡在线观看| h视频在线免费观看| 亚洲国产精品成人精品无码区| **毛片免费观看久久精品| 亚洲娇小性色xxxx| 国产成人亚洲综合色影视| 国产精品公开免费视频| 1000部拍拍拍18勿入免费视频软件 | 久久精品亚洲一区二区三区浴池| 国产精品美女自在线观看免费| 91人人区免费区人人| 尤物视频在线免费观看| 亚洲看片无码在线视频| 久久丫精品国产亚洲av不卡| 国产成人亚洲精品影院| 尤物永久免费AV无码网站| 国产成人免费午夜在线观看| 97无码人妻福利免费公开在线视频|