使用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核心技術》，但願你們可以一塊兒成長、進步。