正文

在容器化的時(shí)代，當(dāng)然一切皆可容器化。在docker官網(wǎng)首頁(yè)赫然有下面這幾個(gè)大字。足以知道docker的優(yōu)勢(shì)。那么且問(wèn)，mysql適合跑在docker中嗎?

當(dāng)然，這個(gè)問(wèn)題有人說(shuō)可以，也有人說(shuō)不可以。下面我們就正反都來(lái)看下各自的觀點(diǎn)。

1. 不可以容器化　　

大部分人的理由有兩個(gè)：

其一，數(shù)據(jù)安全性不能保障

在容器或者docker出現(xiàn)故障時(shí)，不易恢復(fù)。即使使用數(shù)據(jù)卷掛載（volume）也會(huì)在容器故障時(shí)產(chǎn)生數(shù)據(jù)問(wèn)題，共享的數(shù)據(jù)卷且對(duì)宿主機(jī)也會(huì)有損傷。即數(shù)據(jù)的持久化和完整性不能保證。docker適合無(wú)狀態(tài)的服務(wù)，不適合有數(shù)據(jù)狀態(tài)的mysql。

其二，影響mysql性能

mysql我們常用來(lái)讀寫(xiě)，那么IO性能就會(huì)受docker影響，最終瓶頸出現(xiàn)在寫(xiě)（在做了掛載情況下）；且如果物理機(jī)其他應(yīng)用占用過(guò)多資源，也會(huì)影響到容器。

當(dāng)然，以上的問(wèn)題，也都有對(duì)應(yīng)的解決方案，但時(shí)也足夠復(fù)雜；對(duì)研發(fā)力量不足的企業(yè)來(lái)說(shuō)，如果盲目容器化的話，可能會(huì)撿了芝麻，丟了西瓜?！　?/p>

2. 可以容器化　　

有的小伙伴就會(huì)說(shuō)了，同樣是服務(wù)，業(yè)務(wù)服務(wù)都是跑在docker中的，數(shù)據(jù)庫(kù)服務(wù)有何不可？

我只要配置下數(shù)據(jù)卷掛載，解決掉數(shù)據(jù)持久化問(wèn)題，基本上就問(wèn)題不大了。

比如：

docker run -p 3306:3306 --name mysql 
-v /mydata/mysql/log:/var/log/mysql 
-v /mydata/mysql/data:/var/lib/mysql 
-v /mydata/mysql/conf:/etc/mysql
-e TZ=Asia/Shanghai -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7

亦或是docker官方給的mysql容器化的配置sample

services:
  backend:
    build: backend
    ports:
      - 8080:8080
    secrets:
      - db-password
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    restart: always
    secrets:
      - db-password
    volumes:
      - db-data:/var/lib/mysql
    environment:
      - MYSQL_DATABASE=example
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db-password
    expose:
      - 3306
      - 33060   
volumes:
  db-data:
secrets:
  db-password:
    file: db/password.txt

兩個(gè)例子都是通過(guò)-v把mysql相關(guān)目錄數(shù)據(jù)做好掛載，那么在容器出現(xiàn)故障或者被刪除時(shí)，能夠保證相關(guān)數(shù)據(jù)在宿主機(jī)中存在。讓數(shù)據(jù)恢復(fù)成為了可能性。注意！是可能性

當(dāng)然還有docker天然的優(yōu)勢(shì)：　　

• 簡(jiǎn)化部署，可移植性高　
• 保證環(huán)境一致性
• 這兩個(gè)優(yōu)勢(shì) 就足以促使很多人去做容器化部署。（估計(jì)大家都被手動(dòng)部署，遷移，多環(huán)境問(wèn)題搞得頭大過(guò)）

小結(jié)

兩種觀點(diǎn)或者是叫兩種方案沒(méi)有對(duì)錯(cuò)。也不應(yīng)該有爭(zhēng)論。而應(yīng)該實(shí)事求是，根據(jù)當(dāng)前的業(yè)務(wù)發(fā)展，研發(fā)力量來(lái)決策。如果沒(méi)有那個(gè)技術(shù)力量，就老老實(shí)實(shí)部署在物理機(jī)上，成本和風(fēng)險(xiǎn)更小。只是“萬(wàn)事開(kāi)頭難”而已。如果有實(shí)力，有技術(shù)，那么需要設(shè)計(jì)出一個(gè)好的架構(gòu)方案；比如需要考慮鏡像管理，監(jiān)控，容器災(zāi)備，存儲(chǔ)擴(kuò)展，k8s等。技術(shù)的潮流一定是容器化，serverless化。作為技術(shù)人們要擁抱變化，要去踏浪，否則只會(huì)被淹沒(méi)在歷史的浪潮里。

以上就是mysql是否需要容器化深入解析的詳細(xì)內(nèi)容，更多關(guān)于mysql容器化的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論