Docker 数据库，赶时髦也先清楚肚子里面的墨水能不能驾驭这样的“时髦”。 本人是非常反感的，All Database  in Docker ， 

先声明两点

1 本人对容器化的技术，没有一点反感，反而是很想“急功近利”的去学习

2 本人不是对所有的数据库容器化感到反感

声明：完毕。

那就的说说，到底在反感什么

1 没有自知之明，有的公司连DOCKER 非数据库的前端还没有搞清楚怎么维护和运作，就要 数据库容器化，谁给你的自信让你驾驭数据库DOCKER化后的运维。 

可能不少人会轻描淡写的说一句，潮流，别人都这么干，哦，那我想问问，为什么 BAT 中的OCEAN DATABASE 我没有听到说 docker ,是 A 过时了，还是A 的技术没你好。 Oracle 数据库你可曾听说大批量进行进行DOCKER 化？

2 对DOCKER 容器化的盲目崇拜，认为任何东西进行DOCKER化后就可以更好的利用硬件资源，并且更容易管理相关容器化的系统。

其实首先我觉得要明白，一项技术你为什么要去做，而不是赶时髦，支持PG ，我并不是赶时髦，而是PG 在某些功能上，的确有爆发点。

所以DOCKER 容器化数据库我的好好的说一下我到底为什么反感

1 本公司技术还属于初级阶段，在本地实体机管理还一团糟的情况下，妄图用DOCKER 化来挽救混乱的局面，试想你连简单的实体机的管理都一塌糊涂，你怎么能有技术力量或者闲情逸致，或上帝赐予你的力量将容器化作为你的救命稻草。用另一个可能的失败，去掩饰现在的失败，这本身就是一个失败的想法。

2 Docker 到底适合什么，Docker适合小型，静态化，多态化的使用，例如你突然要发起一个秒杀活动，你的前端需要从目前的 2个 NGINX 扩展到10个，来应对洪水般的访问，并且在这个项目过后你很快的回收资源，我想如此的docker话，没有人会有底气来反对他。

3 数据库的docker化，基本都发生在那些数据库，MYSQL ，为什么？难道没有人问问？ 因为数据量小，并且整体的访问量都不是很大的情况下，试想一个 20T 的 ORACLE ,PG，SQL SERVER，你会很缺乏需求来将其DOCKER 化，一台机器的资源都已经不可以支持这样大的数据量计算，你的意义在哪里？ 为了时髦而在夏天穿上你从俄罗斯买来的毛皮大衣，are you a anoia?

4 增加更多的不确定性，众所周知数据库随着他的重要性，一般DBER都会有一个 stable level ，如果你的数据库是一个金融级别的数据库，你会随意更改你的数据库版本，你的数据库哪怕是一个细微的参数调整都心惊肉跳，况且大批量的DOCKER 各种数据库到现在都不是主流，出了任何问题怎么应对，你都心中有数了吗？

5 您是不是应该为无状态应用程序构建的工具中运行有状态应用程序多想想。这些工具被设计用来编排容纳无状态应用程序的Docker容器。这样的应用程序不介意在任何时候终止，任何数量的应用程序都可以同时运行，而不需要相互通信，而且没有人会真正注意到一个新的容器是否会接管另一台机器，这样的设计放在DB ，你带脑子了，Are you sure, again!

6 在容器崩溃后，你是否能保证你的数据库是正常关机的，如果容器崩溃，而你的数据库没有正常关闭，数据的损失是由谁来负责吗，如果我是DBER，我不会，谁提议DOCKER 化我的数据库，谁来负责，并且负责到底， I have no words to them.

当然，你不能让那些妄图 DOCKER 数据库化的 GUYS 静音，

他们想的理由

1 更容易快速的部署

2 更容易的管理

3 更容易横向扩展

4  程序与操作系统的去耦合性

好吧，bulabula， 我就一句，轻轻问， 和我的数据库有关吗

1 我的数据库是那么容易进行快速部署的，我需要吗？ 每个数据库都对应不同的配置和不同的任务，我可能这台机器可能被那个疯子要求关掉 BINLOG 那台机器要做MGR ，重要的机器我还用MHA ，你DOCKER 能帮助我快速部署这些变化多端的需求，即使你能，我需要快速部署吗？ 数据在任何地方都是固化的，数据每一皮秒都有可能变化，你和我谈快速部署，我要的是数据的安全稳定，而不是快速部署。任何对DB的不敬，都将是你失败的开始。

2 更容易管理，我不知道你在说什么，目前管理的DB的方法用DOCKER 管理后有什么进步吗，你是能然给我计算 TPS ,QPS 有地球和 火星之间大距离的进步，还是让我的计算方法有任何变化，还是你能让我的信息统计和计算变得更容易，哪怕有一点变化， 你能吗， 你不能，那你怎么就容易管理了， 我集群中的一台 DOCKER 挂掉了，然后你在启动一个新DOCKER ，问题就解决了，这大概是单细胞动物的优点，但不是 DBER 的复杂思维模式，数据启动不不意味着问题解决了，尤其对重要的数据的数据库，对DB 的不敬，将是你悔恨的开始。

3 更容易的扩展，数据库的扩展，说明目前你的任务对数据库的要求，数据库不能满足，可能是因为存储，可能是因为CPU 可能是因为内存，一个横向处理的 分布式处理，能否解决不是分布式的数据库的问题，你在和我讲什么，数据库的扩展要和业务和当前使用的数据库技术，数据库的拆分等等有关，一个DOCKER 就能解决数据库的扩展，不是我不把你当人看，因为你根本就不是。所有对数据库的不敬，就是你哭泣的开始

4  程序与操作系统的去耦合性，OMG 你见鬼去吧，我数据库不会成天没事进行各种的操作系统升级，我要的是稳定性，不是鸡飞狗跳的升级。

任何对数据库的不敬，都是你无地自容的开始。

所以，一个不看情况就随意将数据库DOCKER 化的开始（生产系统，或重要的测试系统），可以看做是一个，哭泣，失败，悔恨，无地自容的开始，所以当我面对有人对我说， 你生产数据库DOCKER 吧， 我的回答只有， leave me alone！