关于有形态的运行服务而言，容器是一个相当完美的开发运维处置打算。但是关于带耐久形态的服务——数据库来说，事件就没有那么繁难了。 消费环境 的数据库能否应当放入容器中，依然是一个充溢争议的疑问。

站在开发者的角度上，我十分青睐，并置信容器兴许是未来软件开发部署运维的规范方式。但站在DBA的立场上，我以为就 目前而言 ，将消费环境数据库放入Docker/K8S中依然是一个馊主意。

Docker处置什么疑问？

让咱们先来看一看Docker对自己的描画。

Docker用于描画自己的词汇包括： 轻量、规范化、可移植、浪费老本、提高效率、智能、集成、高效运维 。这些说法并没有疑问，Docker在全体意义上确实让开发和运维都变得更容易了。因此可以看到很多公司都热切地宿愿将自己的软件与服务容器化。但有时刻这种激情会走向另一个极其：将一切软件服务都容器化，甚至是 消费环境的数据库 。

容器最后是针对 有形态 的运行而设计的，在逻辑上，容器内运行发生的暂时数据也属于该容器的一局部。用容器创立起一个服务，用完之后销毁它。这些运行自身没有形态，形态通常保留在容器外部的数据库里，这是经典的架构与用法，也是容器的设计哲学。

但当用户想把数据库自身也放到容器中时，事件就变得不一样了： 数据库是有形态的 ，为了维持这个形态不随容器中止而销毁，数据库容器要求在容器上打一个洞，与底层操作系统上的数据卷相联通。这样的容器，不再是一个能够轻易创立，销毁，搬运，转移的对象，而是与底层环境相绑定的对象。因此，传统运行经常使用容器的诸多好处，关于数据库容器来说都不复存在。

牢靠性

让软件跑起来，和让软件牢靠地运转是两回事。数据库是消息系统的外围，在绝大少数场景下属于 关键（Critical） 运行，Criticallication可按字面解释，就是出了疑问会要命的运行。这与咱们的日常阅历相符：//PPT这些办公软件假设崩了强迫重启即可，没什么大不了的；但正在编辑的文档假设丢了、脏了、乱了，那才是真的劫难。数据库亦然，关于不少公司，特意是互联网公司来说，假设数据库被删了又没有可用备份，基本上可以宣告关门大吉了。

牢靠性（Reliability） 是数据库最关键的属性。牢靠性是系统在困境（adversity）（配件缺点、软件缺点、人为错误）中仍可反常上班（正确成功性能，并能到达希冀的性能水准）的才干。牢靠性象征着容错（fault-tolerant）与韧性（resilient），它是一种 安保属性 ，并不像性能与可保养性那样的 活性属性 直观可权衡。它只能经过长期间的反常运转来证实，或许某一次性缺点来否证。很多人往往会在往常漠视安保属性，而在生病后，车祸后，被抢劫后才追悔莫及。安保消费重于泰山，数据库被删，被搅乱，被脱库后再捶胸顿足是没无心义的。

回头再看一看Docker对自己的个性描画中，并没有蕴含牢靠这个关于数据库至关关键的属性。

牢靠性证实与社区常识

如前所述，牢靠性并没有一个很好的权衡方式。只要经过长期间的正确运转，咱们才干对一个系统的牢靠性逐渐建设信念。在裸机上部署数据库堪称自古以来的通常，经过几十年的继续上班，它很好地证实了自己的牢靠性。Docker虽为DevOps带来一场反派，但仅仅五年的历史关于牢靠性证实而言依然是图样图森破。对关乎身家性命的消费数据库而言还远远不够： 由于还没有足够的小白鼠去趟雷 。

想要提高牢靠性，最关键的就是从缺点中吸取阅历。缺点是贵重的阅历财产：它将未知疑问变为已知疑问，是运维常识的体现方式。 社区的缺点阅历绝大多都基于裸机部署的假定 ，各式各样的缺点在几十年里都曾经被人们踩了个遍。假设你遇到一些疑问，大略率是他人曾经踩过的坑，可以比拟繁难地处置与处置。雷同的缺点假设加上一个Docker关键字，能找到的有用消息就要少得多。这也象征着当 疑难杂症 出现时，成功抢救复原数据的概率要更低，处置紧急缺点所需的期间会更长。

巧妙的事实是，假设没有不凡理由，企业与团体通常并不情愿分享缺点方面的阅历。缺点有损企业的声誉：或许泄露一些敏感消息，或许是企业与团队的渣滓水平。另一方面，缺点阅历简直都是真金白银的损失与学费换来的，是运维人员的外围价值所在，因此无关缺点方面的地下资料并不多。

额外失效点

开发关心Feature，而运维关注Bug。相比裸机部署而言，将数据库放入Docker中并不能降低配件缺点、软件错误、人为错误的出现概率。用裸时机有的配件缺点，用Docker一个也不会少。软件缺点关键是运行Bug，也不会由于驳回容器与否而降低，人为错误同理。相反，引入Docker会由于 引入了额外的组件、额外的复杂度、额外的失效点，造成系统全体牢靠性降低 。

举个最繁难的例子，dockerd守护进程崩了怎样办，数据库进程就间接歇菜了。虽然这种事件出现的概率并不高，但它们在裸机上—— 压根不会出现 。

此外，一个额外组件引入的失效点或许并不止一个：Docker发生的疑问并不只仅是Docker自身的疑问。当缺点出现时，或许是单纯Docker的疑问，或许是Docker与数据库相互作用发生的疑问，还或许是Docker与操作系统、编排系统、虚构机、网络、磁盘相互作用发生的疑问。可以参见官网PostgreSQLDocker镜像的Issue列表：。

正如《从降本增笑到降本增效》中所说， 智力功率很难在空间上累加 ——团队的智力功率往往取决于最资深几个灵魂人物的水平以及他们的沟通老本。当数据库出现疑问时要求数据库专家来处置；当容器出现疑问时要求容器专家来看疑问；但是当你把数据库放入Kubees时，独自的数据库专家和K8S专家的智力带宽是很难叠加的——你要求一个双料专家才干处置疑问。而同时知晓这两者的软件必要求比独自的数据库专家少得多。

此外，彼之蜜糖，吾之砒霜。某些Docker的Feature，在特定的环境下也或许会变为Bug。

隔离性

Docker提供了进程级别的隔离性，通常来说隔离性对运行来说是个好属性。运行看不见别的进程，人造也不会有很多相互作用造成的疑问，进而提高了系统的牢靠性。但隔离性关于数据库而言不必定齐全是善报。

一个巧妙的 实在案例 是 在同一个数据目录上启动两个PostgreSQL实例 ，或许在宿主机和容器内同时启动了两个数据库实例。在裸机上第二次启动尝试会失败，由于PostgreSQL能看法到另一个实例的存在而拒绝启动；但在经常使用Docker的状况下因其 隔离性 ，第二个实例无法看法到宿主机或其余数据库容器中的另一个实例。假设没有性能正当的Fencing机制（例如经过宿主机端口互斥，pid文件互斥），两个运转在同一数据目录上的数据库进程能把数据文件搅成一团浆糊。

数据库需不要求隔离性？当然要求，但不是这种隔离性。数据库的性能很关键，因此往往是独占物理机部署。除了数据库进程和必要的工具，不会有其余运行。即使放在容器中，也往往驳回独占绑定物理机的形式运转。因此Docker提供的隔离性关于这种数据库部署打算而言并没有什么意义；不过对云数据库厂商来说，这倒真是一个适用的Feature，用来搞多租户超卖妙用无量。

工具

数据库要求工具来保养，包括各式各样的运维脚本，部署，备份，归档，缺点切换，大小版本更新，插件装置，衔接池，性能剖析，监控，调优，巡检，修复。这些工具，也大多针对裸机部署而设计。这些工具与数据库一样，都要求精心而充沛的测试。 让一个物品跑起来，与确信这个物品能耐久稳固正确的运转，是齐全不同的牢靠性水准。

一个繁难的例子是插件与包治理，PostgreSQL提供了很多适用的插件，譬如PostGIS。假构想为数据库装置该插件，在裸机上只需yuminstall而后createextensionpostgis两条命令就可以。但假设是在Docker里，依照Docker的通常准则，用户要求在镜像档次启动这个变卦，否则下次容重视启时这个裁减就没了。因此要求修正Dockerfile，从新构建新镜像并推送到主机上，最后 重启数据库容器 ，毫无不懂，要费事得多。

包治理是操作系统发行版的外围疑问。但是Docker搅乱了这一切，例如，许多PostgreSQL不再以RPM/DEB包的方式颁布二进制，而是以加装裁减的PostgresDocker镜像散发。这就会立刻发生一个清楚的疑问，假设我想同时经常使用两种，三种，或许PG生态的一百多种裁减，那么应该如何把这些散碎的镜像整合到一同呢？相比牢靠的操作系统包治理，构建Docker镜像总是要求消耗更多期间与精神才干反常起效。

再比如说监控，在传统的裸机部署形式下， 机器 的各名目的是数据库目的的关键组成局部。容器中的监控与裸机上的监控有很多巧妙的区别。不留意或许会掉到坑里。例如，CPU各种形式的时长之和，在裸机上一直会是100%，但这样的假定在容器中就不必定总是成立了。再比如说依赖/proc文件系统的监控程序或许在容器中取得与裸机上涵义齐全不同的目的。虽然这类疑问最终都是可解的（例如把Proc文件系统挂载到容器内），但相比繁复明了的打算，没人青睐复杂奇丑的workaround。

相似的疑问包括一些缺点检测工具与系统罕用命令，虽然通常上可以间接在宿主机上口头，但谁能保障容器里的结果和裸机上的结果有着相反的涵义？更为辣手的是紧急缺点处置时，一些要求暂时装置经常使用的工具在容器里没有，外网不通，假设再走Dockerfile→Image→重启这种门路毫无不懂会让人抓狂。

把Docker当成虚构机来用的话，很多工具大致上还是可以反常上班的，不过这样就丢失了经常使用的Docker的大局部意义，不过是把它当成了另一个包治理器用而已。有人觉得Docker经过规范化的部署方式参与了系统的牢靠性，由于环境更为规范化更为可控。这一点不能否定。私以为，规范化的部署方式虽然很不错，但假设运维治理数据库的人自身了解如何性能数据库环境，将环境初始化命令写在Shell脚本里和写在Dockerfile里并没有实质上的区别。

可保养性

软件的大局部开支并不在最后的开发阶段，而是在继续的保养阶段，包括修复破绽、坚持系统反常运转、处置缺点、版本更新，归还技术债、参与新的性能等等。可保养性关于运维人员的上班生存品质十分关键。

应该说可保养性是Docker最讨喜的中央：Infrastructureascode。可以以为Docker的最大价值就在于它能够把软件的运维阅历积淀成可复用的代码，以一种简便的方式积攒起来，而不再是散落在各个角落的install/setup文档。

在这一点上Docker做的相当杰出，尤其是关于逻辑经常变动的有形态运行而言。Docker和K8s能让用户轻松部署，成功扩容，缩容，颁布，滚动更新等上班，让Dev也无能Ops的活，让Ops也无能DBA的活（迫真）。

环境性能

假设说Docker最大的好处是什么，那兴许就是环境性能的规范化了。规范化的环境有助于交付变卦，交流疑问，复现Bug。经常使用二进制镜像（实质是物化了的Dockerfile装置脚本）相比口头装置脚本而言更为快捷，治理更繁难。一些编译复杂，依赖如山的裁减也不用每次都从新构建了，这些都是很不错的个性。

可怜的是，数据库并不像通常的业务运行一样来来去去更新频繁，创立新实例或许交付环境自身是一个极低频的操作。同时DBA们通常都会积攒下各种装置性能保养脚本，一键性能环境也并不会比Docker慢多少。因此在环境性能上Docker的好处就没有那么清楚了，只能说是Nicetohave。当然，在没有专职DBA时，经常使用Docker镜像或许还是要比自己瞎折腾要好一些，由于最少镜像中多少积淀了一些运维阅历。

通常来说，数据库初始化之后延续运转几个月几年也并不稀罕。占据数据库治理上班关键内容的并不是创立新实例与交付环境，关键还是日常运维的局部——Day2Operation。可怜的是，在这一点上Docker并没有什么好处，反而会发生不少的额外费事。

Day2Operation

Docker确实能极大地简化有形态运行的日常保养上班，诸如创立销毁，版本更新，扩容等，但雷同的论断能加长到数据库上吗？

数据库容器无法能像运行容器一样轻易销毁创立，重启迁徙。因此Docker并不能对数据库的日常运维的体验有什么优化，真正有协助的倒是诸如ansible之类的工具。而关于日常运维而言，很多操作都要求经过dockerexec的方式将脚本透传至容器外口头。底下跑的还是一样的脚本，只不过用docker-exec来口头又额外多了一层包装，这就有点脱裤子放屁的象征了。

此外，很多命令行工具在和Docker配合经常使用时都相当难堪。譬如dockerexec会将stderr和stdout混在一同，让很多依赖管道的命令无法反常上班。以PostgreSQL为例，在裸机部署形式下，某些日常ETL义务可以用一行bash轻松搞定：

psql<src-url>-c'COPYtblTOSTDOUT'|

psql<dst-url>-c'COPYtdbFROMSTDIN'

但假设宿主机上没有适合的客户端二进制程序，那就只能这样用Docker容器中的二进制：

dockerexec-itsrcpggosupostgresbash-c"psql-c"COPYtblTOSTDOUT"2>/dev/null"|dockerexec-idstpggosupostgrespsql-c'COPYtblFROMSTDIN;'

当用户想为容器里的数据库做一个物理备份时，原本很繁难的一条命令如今要求很多额外的包装：docker套gosu套bash套pg_basebackup：

dockerexec-ipostgres_pg_1gosupostgresbash-c'pg_basebackup-Xf-Ft-cfast-D-2>/dev/null'|tar-xC/tmp/backup/basebackup

假设说客户端运行psql|pg_basebackup|pg_dump还可以经过在宿主机上装置对应版本的客户端工具来绕开这个疑问，那么服务端的运行就真的无解了。总不能在一直更新容器内数据库软件的版本时每次都一并把宿主机上的主机端二进制版本更新了吧？

另一个Docker青睐讲的例子是软件 版本更新 ：例如用Docker更新数据库小版本，只需繁难地修正Dockerfile里的版本号，从新构建镜像而后重启数据库容器就可以了。没错，至少关于有形态的运行来说这是成立的。但当要求启动数据库原地大版本更新时疑问就来了，用户还要求同时修负数据库形态。在裸机上一行bash命令就可以处置的疑问，在Docker下或许就会变成这样的物品：。

假设数据库容器不能像AppServer一样轻易地调度，极速地裁减，也无法在初始性能，日常运维，以及紧急缺点处置时相比个别脚本的方式带来更多便利性，咱们又为什么要把消费环境的数据库塞进容器里呢？

Docker和K8s一个很讨喜的中央是很容易启动扩容，至少关于有形态的运行而言是这样：一键拉起起几个新容器，轻易调度到哪个节点都次要。但数据库不一样，作为一个有形态的运行，数据库并不能像个别AppServer一样轻易创立，销毁，水平裁减。譬如，用户创立一个新从库，即使经常使用容器，也得从主库上从新拉取基础备份。消费环境中动辄几TB的数据库，创立正本也要求个把钟头才干成功，也要求人工参与与审核，并逐渐放量预热缓存才干上线承载流量。相比之下，在雷同的操作系统初始环境下，运转现成的拉从库脚本与跑dockerrun在实质上又能有什么区别——期间都花在拖从库上了。

经常使用Docker盛放消费数据库的一个难堪之处就在于，数据库是有形态的，而且为了建设这个形态要求额外的工序。通常来说设置一个新PostgreSQL从库的流程是，先经过pg_baseback建设本地的数据目录正本，而后再在本地数据目录上启动postmaster进程。但是容器是和进程绑定的，一旦进程分开容器也随之中止。因此为了在Docker中扩容一个新从库：要么要求先后启动pg_baseback容器拉取数据目录，再在同一个数据卷上启动postgres两个容器；要么要求在创立容器的环节中就指定定好复制目的并期待几个小时的复制成功；要么在postgres容器中再经常使用pg_basebackup偷天换日交流数据目录。无论哪一种打算都是既不优雅也不繁复。由于容器的这种进程隔离形象，关于数据库这种充溢形态的多进程，多义务，多实例单干的运行存在 形象走漏 ，它很难优雅地笼罩这些场景。当然有很多折衷的方法可以打补丁来处置这类疑问，但是其代价就是少量 额外复杂度 ，最终受伤的还是系统的可保养性。

总的来说，Docker在某些层面上可以提高系统的可保养性，比如简化创立新实例的操作，但它引入的新费事让这样的好处显得惨白有力。

性能

性能也是人们经常关注的一个维度。从性能的角度来看，数据库的基本部署准则当然是离配件越近越好，额外的隔离与形象不利于数据库的性能：越多的隔离象征着越多的开支，即使只是内核栈中的额外拷贝。关于谋求性能的场景，一些数据库选用绕开操作系统的页面治理机制间接操作磁盘，而一些数据库甚至会经常使用FPGA甚至GPU减速查问处置。

捕风捉影地讲，Docker作为一种轻量化的容器，性能上的折损并不大，通常不会超越10%。但毫无不懂的是， 将数据库放入Docker只会让性能变得更差而不是更好 。

总结

容器技术与编排技术关于运维而言是十分有价值的物品，它实践上补偿了从软件到服务之间的空白，其愿景是将运维的阅历与才干代码化模块化。容器技术将成为未来的包治理方式，而编排技术将进一步开展为数据中心散布式集群操作系统，成为一切软件的底层基础设备Runtime。当越来越多的坑被踩完后，人们可以安心大胆地把一切运行，有形态的还是有形态的都放到容器中去运转。但如今最少关于数据库而言，还只是一个美妙的愿景与鸡肋的选项。

要求再次强调的是，以上探讨仅限于 消费环境数据库 。关于开发测试而言，虽然有基于Vagrant的虚构机沙箱，但我也支持经常使用Docker——毕竟不是一切的开发人员都知道怎样性能本地测试数据库环境，经常使用Docker交付环境显然要比一堆手册繁难明了得多。关于消费环境的 有形态 运行，甚至一些带有衍生形态的不甚关键衍生数据系统（譬如缓存），Docker也是一个不错的选用。但关于消费环境的外围相关型数据库而言，假设外面的数据真的很关键，经常使用Docker前还是要求三思：这样做的价值究竟在哪里？出了疑难杂症能Hold住吗？搞砸了这锅背得动吗？

任何技术决策都是一个利害权衡的环节，譬如这里经常使用Docker的外围权衡或许就是 就义牢靠性换取可保养性 。确实有一些场景，数据牢靠性并不是那么关键，或许说有其余的考量：譬如关于云计算厂商来说，把数据库放到容器里混部超卖就是一件很好的事件：容器的隔离性，高资源应用率，以及治理上的便利性都与该场景十分符合。这种状况下将数据库放入Docker中，兴许 对他们而言 就是利大于弊的。但关于更多的场景来说，牢靠性往往都是优先级最高的属性，就义牢靠性换取可保养性通常并不是一个可取的选用。更何况也很难说运维治理数据库的上班，会由于用了Docker而轻松多少：为了装置部署一次性性的便利而就义短暂的日常运维可保养性并不是一个好主意。

综上所述，将消费环境的数据库放入容器中确实不是一个理智的选用。

---

我们是否应该将数据库也容器化？

Docker不适合部署数据库的7大原因

1、数据安全问题

不要将数据储存在容器中，这也是 Docker 官方容器使用技巧中的一条。容器随时可以停止、或者删除。当容器被rm掉，容器里的数据将会丢失。为了避免数据丢失，用户可以使用数据卷挂载来存储数据。但是容器的 Volumes 设计是围绕 Union FS 镜像层提供持久存储，数据安全缺乏保证。如果容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。

即使你要把 Docker 数据放在主机来存储 ，它依然不能保证不丢数据。Docker volumes 的设计围绕 Union FS 镜像层提供持久存储，但它仍然缺乏保证。

使用当前的存储驱动程序，Docker 仍然存在不可靠的风险。如果容器崩溃并数据库未正确关闭，则可能会损坏数据。

2、性能问题

大家都知道，MySQL 属于关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 MySQL 的读写性能。

在一次Docker应用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的性能瓶颈一般出现在IO上面，如果按 Docker 的思路，那么多个docker最终IO请求又会出现在存储上面。现在互联网的数据库多是share nothing的架构，可能这也是不考虑迁移到 Docker 的一个因素吧”。

针对性能问题有些同学可能也有相对应的方案来解决：

(1)数据库程序与数据分离

如果使用Docker 跑 MySQL，数据库程序与数据需要进行分离，将数据存放到共享存储，程序放到容器里。如果容器有异常或 MySQL 服务异常，自动启动一个全新的容器。另外，建议不要把数据存放到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比较大。

(2)跑轻量级或分布式数据库

Docker 里部署轻量级或分布式数据库，Docker 本身就推荐服务挂掉，自动启动新容器，而不是继续重启容器服务。

(3)合理布局应用

对于IO要求比较高的应用或者服务，将数据库部署在物理机或者KVM中比较合适。目前TX云的TDSQL和阿里的Oceanbase都是直接部署在物理机器，而非Docker 。

3、网络问题

要理解 Docker 网络，您必须对网络虚拟化有深入的了解。也必须准备应付好意外情况。你可能需要在没有支持或没有额外工具的情况下，进行 bug 修复。

我们知道：数据库需要专用的和持久的吞吐量，以实现更高的负载。我们还知道容器是虚拟机管理程序和主机虚拟机背后的一个隔离层。然而网络对于数据库复制是至关重要的，其中需要主从数据库间 24/7 的稳定连接。未解决的 Docker 网络问题在1.9版本依然没有得到解决。

把这些问题放在一起，容器化使数据库容器很难管理。我知道你是一个顶级的工程师，什么问题都可以得到解决。但是，你需要花多少时间解决 Docker 网络问题？将数据库放在专用环境不会更好吗？节省时间来专注于真正重要的业务目标。

4、状态

在 Docker 中打包无状态服务是很酷的，可以实现编排容器并解决单点故障问题。但是数据库呢？将数据库放在同一个环境中，它将会是有状态的，并使系统故障的范围更大。下次您的应用程序实例或应用程序崩溃，可能会影响数据库。

**知识点：**在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。

Docker 快速扩展的一个重要特征就是无状态，具有数据状态的都不适合直接放在 Docker 里面，如果 Docker 中安装数据库，存储服务需要单独提供。

目前，TX云的TDSQL(金融分布式数据库)和阿里云的Oceanbase(分布式数据库系统)都直接运行中在物理机器上，并非使用便于管理的 Docker 上。

5、资源隔离

资源隔离方面，Docker 确实不如虚拟机KVM，Docker是利用Cgroup实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。如果其他应用过渡占用物理机资源，将会影响容器里 MySQL 的读写效率。

需要的隔离级别越多，获得的资源开销就越多。相比专用环境而言，容易水平伸缩是Docker的一大优势。然而在 Docker 中水平伸缩只能用于无状态计算服务，数据库并不适用。

我们没有看到任何针对数据库的隔离功能，那为什么我们应该把它放在容器中呢？

6、云平台的不适用性

大部分人通过共有云开始项目。云简化了虚拟机操作和替换的复杂性，因此不需要在夜间或周末没有人工作时间来测试新的硬件环境。当我们可以迅速启动一个实例的时候，为什么我们需要担心这个实例运行的环境？

这就是为什么我们向云提供商支付很多费用的原因。当我们为实例放置数据库容器时，上面说的这些便利性就不存在了。因为数据不匹配，新实例不会与现有的实例兼容，如果要限制实例使用单机服务，应该让 DB 使用非容器化环境，我们仅仅需要为计算服务层保留弹性扩展的能力。

7、运行数据库的环境需求

常看到 DBMS 容器和其他服务运行在同一主机上。然而这些服务对硬件要求是非常不同的。

数据库（特别是关系型数据库）对 IO 的要求较高。一般数据库引擎为了避免并发资源竞争而使用专用环境。如果将你的数据库放在容器中，那么将浪费你的项目的资源。因为你需要为该实例配置大量额外的资源。在公有云，当你需要 34G 内存时，你启动的实例却必须开 64G 内存。在实践中，这些资源并未完全使用。

怎么解决？您可以分层设计，并使用固定资源来启动不同层次的多个实例。水平伸缩总是比垂直伸缩更好。

总结

针对上面问题是不是说数据库一定不要部署在容器里吗？

答案是：并不是

我们可以把数据丢失不敏感的业务（搜索、埋点）就可以数据化，利用数据库分片来来增加实例数，从而增加吞吐量。

docker适合跑轻量级或分布式数据库，当docker服务挂掉，会自动启动新容器，而不是继续重启容器服务。

数据库利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点，也是可以进行容器化的。

见仁见智，一般不推荐用容器做状态或持久化的东西，因为无法保证数据安全。当然，你如果是类似于一主多从，并对数据一致性没有变态的要求，那用容器跑几个只读从库也没啥不可以

怎样当一个好的数据库管理员 DBA 详细�0�3

D BA 最简单的定义就是数据库管理员，一个管理数据库或数据库服务器的人。 你可以想象得到，对于一个DBA，要知道的东西远比听起来的要多。 要做一个好的 SQL Server DBA，需要学很多知识。 这些不仅仅是与SQL Server 有关的。 因为 SQL Server 与Windows NT 捆绑在一起，所以他们至少对Windows NT 要有一个大致了解。 新术语D BA(数据库管理员)是一个管理数据库和数据库服务器的人。 对于一个SQL Server DBA 来说需要哪些技能呢?有许多，其中一部分会更重要些。 下面是一些作为一个优秀的SQL Server DBA 应掌握的技能： ★SQL Server--要想成为一个好的SQL Server DBA，你必须掌握SQL Server。 一个S QL Server DBA 需要掌握怎样安装、配置、维护SQL Server，并能解决问题。 这看起来不多，但你要明白，SQL Server 是一个很大的产品。 有利之处是微软增加了许多功能来帮助你完成这些任务。 ★Windows NT--正如前面所提到的，一个SQL Server DBA 至少要了解 Windows NT 的 运行机制。 SQL Server 7.0 与以前发布的版本相比与Windows NT 捆绑得更紧密了。 S QL Server DBA 的一些基本技能就是熟练地管理用户和用户组；建立、修改和管理共享软件；改变和管理权限；启动和停止Windows NT 服务；使用Event Vi ew er(事件浏览器)。 ★关系型数据库--因为SQL Server 最主要的功能就是管理关系型数据库，所以对于一个SQL Server DBA 来说，掌握关系型数据库怎样运行以及它的基本结构是非常重要的。 ★S QL--每个D BA 都需要对S QL 语言有一个基本的了解。 这并不是说要你成为一个程序员，但你确实要知道怎样将S EL EC T 语句组织到一起。 这样做的好处是：你越多用S QL 语言，收益越大。 ★备份和恢复过程--随着你在数据库中有更多的经历，你遇到的问题可能并不是数据库或服务器是否会崩溃，而是何时会崩溃。 当一个数据库损坏后，最好的选择是将最近备份的数据恢复回去。 如果一个数据库崩溃了，而你又没做日常备份，通常你就需要写求职履历和找工作了。 ★业务处理--每个D BA，不管使用什么R DB MS，都需要精通基本的业务运作。 可以断定，无论从事什么业务，你的数据库都将模拟你的业务运作。 例如：一种在因特网上售物的业务可能需要有一个数据库来跟踪货物、用户帐目和帐单的信息。 现在你已经知道什么是SQL Server DBA 了，你可能会想，SQL Server DBA 需要做什么呢?作为一个SQL Server DBA 要负责许多工作，并面临巨大的潜在压力。 下面是一个D BA 所负责的一些基本工作： ★安装SQL Server--这大概是一个SQL Server DBA 所要做的第一件事。 安装SQL Server 比较简单，但是如果没有很好地计划，后面的路将会很难走。 常见的情况是，安装一个SQL Server 并使它能在片刻之后运行起来，但发现安装了软件的服务器功能不够强大，以至无法处理所担负的工作量。 这时，你只好考虑升级硬件或换一个服务器了。 ★建立和维护数据库--在SQL Server 上建立新数据库是D BA 的另一个常规任务，维护现有的数据库也将是最重要的工作之一。 如果不能正确地维护数据库，数据库将不能正常启动，某种意义上，这对 D BA 来说意味着更多的工作。 ★负责维修数据库--这是与维护数据库相伴而来的任务。 这包括诸如运行数据库的工具来保证每件事情都正确地建立和分配。 关键是在你和用户遇到问题之前，就要去发现并解决导致这些问题的错误。 ★管理用户--每当一个新成员加入或离开你的公司时，增加或删除这些用户的登录I D 就是D BA 的事了。 这非常重要，尤其是考虑到一些人在离开公司时可能会悄悄对数据库做些手脚。 ★管理权限--作为一名SQL Server DBA，另一项重要的有关安全方面的工作是管理权限。 这之所以非常重要，是因为通常数据都保存在数据库中，你不想让公司里的一般人接触到这些数据。 例如有关薪水的资料。 一名SQL Server DBA 需要为有这类数据的表分配权限。 这样，只有被允许的人才能访问这些数据。 ★备份和恢复数据--这是作为一名SQL Server DBA 非常可能遇到的重要工作之一。 从某种意义上讲，任何一种数据库都可能损坏。 除了做一些日常备份外，对此别无他法。 当数据库损坏后，通常最快的补救措施是从一个备份中恢复数据。 ★调度任务--调度任务的能力是SQL Server 最有用的特点之一。 这使得任务能在你的用户不工作的时间里自动执行。 这对运行备份、维护、批处理来说尤其有用。 这些进程通常会抢先占用大量的服务，还会与你的数据库中活动的用户发生严重冲突。 ★数据的导入和导出--SQL Server 经常要和任何地方的操作平台上别的数据库管理系统进行协作，从大型机到U NI X 服务器，到个人电脑的数据库。 为了使协作顺利，就需要在系统之间移动数据。 这种数据传输通常可能是一次性过程，也可能是日常性过程。 ★管理SQL Server 复制--SQL Server 复制是一个工具，用来把数据复制为几份，并发送到不同地方。 作为D BA，你要设置并监视复制过程。 ★监视和调整服务器--SQL Server 7.0 在服务器调整方面有许多优点。 事实上，S QL Server 7.0 可以为你自动调整大部分选项。 除非你想自己决定SQL Server 怎样使用资源。 这是一项非常难做的工作，因为要配置太多的选项。 在掌握了什么可以配置后，可以试着进行不同的设置并看看会对服务器的运行产生什么影响。 ★解决SQL Server 问题--当SQL Server 出现问题后，你的第一反应可能会是惊慌失措。 而当遇到的问题多了，你就会想到怎样去解决问题。 通常，当解决完一个问题后，会发现又有新的问题等着你去解决。 课时小结 在本学时中，我讲解了SQL Server 的所有特点和SQL Server DBA 到底是什么样的人。 在SQL Server 中使用了许多相关的技术，一下子全部弄懂似乎不太容易。 在后面的课程里，你 将会学到我讨论到的所有这些技术以及怎样去应用它们。 专家答疑 问题：掌握SQL Server 很难吗? 解答：可能是。 这并不是要使你丧失学习进而掌握这个产品的勇气。 SQL Server 之所以难学，是因它涵盖了太多的不同学科。 要完全精通SQL Server，你必须要掌握有关软件开发、网络、体系结构和业务等各方面的知识。 问题：除了读这本书，我还应该做什么? 解答：最好的方法就是实践。 如果你有一台用于开发的服务器，尽可能去在那台服务器上进行实践，以便掌握我讲到的概念。