使用MySQL服務一般會遇到的疑惑

使用MySQL服務一般會遇到的疑惑

來自專欄 一枚程序員的自我修養

主題

本文首發公眾號【一名打字員】

今天主要分享一下在服務端使用MySQL服務時，會遇到的幾個經典問題以及對應的建議解決方案，如有雷同，絕對不是巧合。

MYSQL容災快速切換方案

說到容災，本猿公司以前就是自己買的伺服器，然後找的機房託管，然而估計是一家不咋「靠譜」的機房，為啥這麼說呢，誰家機房沒事就遷移，然後臨時性的斷電就出現了不下於兩次，由於公司的資料庫都是自己維護，斷電導致了幾次數據異常，吃了幾次苦頭之後，公司就捨棄了地方機房，果斷放在雲上面。

當然，當時我們也沒有做任何容災措施，面對機房級災難根本束手無措。接下來，本猿簡單介紹一下自己所理解的MySQL中常用的容災方案.

1. 複製

通常，我們的客戶端進行讀寫操作是，往往是對主庫進行寫入，然後在從庫中進行讀操作，然後主從庫之間會進行replication(複製)。

當主庫宕機的時候，我們可以很快的將備庫推出來，充當主庫的角色，來保證業務的順利進行。

這樣的話對複製過程中延遲的時間要求比較高。假設，如果是執行單挑數據執行時間為T，則延遲為T，那麼耗費的時間是2T。執行一個事務（N條操作）的話，會先緩存到cache中，等待全部執行寫入操作結束，延遲的時間則為N*T。

當資料庫吞吐量到達一定程度時，這個延遲會變的很大，這時候就會產生許多其它的維護成本。至於主備庫如何解決延遲問題，請移步下面的問題。

2.利用zookeeper容災切換

在上面我們介紹了MySQL複製的相關知識，而且MySQL的複製機制很強大，我們能夠保證數據不丟失，但是如何保證主備如何在宕機時無縫切換並將相應的故障轉移處理呢，怎麼才會馬上知道自己的主庫掛掉了，而不是痴痴的等其他部門找上門來興師問罪，這時候就需要一個好的監控工具了，在這裡本猿推薦使用zookeeper，之前公司也是用zookeeper管理的dubbo的一個微服務集群，這樣MySQL的監控和失效備援就能順利的解決了，同時也能夠協調多個服務之間進行事件處理。

通常，我們監控服務的時候，基本上是採用保持存活或者心跳的方式，就像之前對dubbo服務的管理，本猿更中意與發送心跳包來檢測服務存活的方式。所以對於每一個MySQL實例，都會有一個AGENT程序，它與MySQL示例放在同一台機器上，並定時對齊檢測可用性，這樣當機器掛掉的時候，agent與zookeeper斷開連接，zookeeper則會馬上感知。又或者是agent無法檢測到MySQL的存活狀態，則也會對zookeeper發出通知，另外agent掛掉的時候，失敗事件也會進行重啟或者其它的操作。

MYSQL哪種存儲引擎好

在網路上有關於針對InnoDB引擎與MyISAM引擎進行了測試。

其結果大致為1W與10W的select、update與delete操作都很快，在1ms一下。insert操作受數據規模影響較少。在100w調數據以上InnoDB引擎有相對優勢，在數據規模在10w條以下的，MyISAM引擎有相對優勢，但是注意，使用InnoDB引擎要注意填寫配置，在預設參數配置下性能較差。

MYSQL的應用是否會造成數據的丟失

答案肯定是會的，正所謂常在河邊走，哪能不濕鞋。無論是上面說的機房斷電或者伺服器異常還是硬碟壞掉都會造成數據的丟失，一般大廠在線上時，都會使用應用雙寫，也就是寫兩份來保證數據的準確。另外應用會記錄log，發送同志消息來保證數據準確寫入不丟失。

MYSQL主備庫延遲解決方案基本思路

首先，造成主備庫延遲，說明其中肯定會參雜有網路延遲、主庫負載、備庫負載的因素。

這個時候我們可以在從庫裡面選出一台專用的伺服器，只來作為備份用，不進行其它操作，也就能最大限度的達到減少延遲的要求。當然這只是外部的粗淺解決方案，我們需要減少從庫同步延時，就需要在架構上做優化，讓主庫的DDL快速的執行，另外從庫對數據安全要求不高，sync_binlog與innodb_flush_log_at_trx_commit之類的完全可以去掉，同時也可以配備比主庫更好或者相同配置的硬體設備。

MySQL5.6+已經支持多線程的主從複製，不像oracle那樣以schema來做多線程，不同的庫使用不同的複製線程，MySQL則是採用淘寶丁奇所類似的方法，以表來做多線程。

結論

關於MySQL，還有許多值得去深入研究的問題。另外推薦一本書《深入理解MySQL核心技術》，希望大家能夠一起成長、進步。

推薦閱讀：