【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
就是大家部署tidb的时候。是把各个tidb分开部署呢还是把tidb和在一起
比如你有30台硬件物理，你会分开部署成10个tidb集群给10个部门使用还是会合在一起部署一个大的tidb给大家一起用10个业务创建10个账号来监管。
参考一下甄嬛传
1 个赞
你说的这个情况加上Placement Rules in SQL，是不是就能做到租户之间的物理隔离了，如果此时是一套集群，管控上是不是容易点。这有点像是虚拟化方案和云方案的区别，显然，趋势是云。
显然是前者，物理隔离分化风险永远最靠谱。
详细说说
如果资源足够，意味着成本不是问题，按照我们的经验，还是尽量分开部署。
0.首先，具有相同业务特性、能合并在一个集群的业务，尽量放在同一个集群，毕竟可以节省机器成本、人力维护成本；纯AP、纯TP、HTAP的不同业务， 可能要尽量分开部署。
尽量分开部署的原因，主要考虑到：
1.物理隔离，任何问题、故障知会局限在单个集群，不会有扩大风险
2.运维是会相对繁琐，但是风险是隔离的，长远收益会更大
3.不同集群适配不同的业务需求，AP的、TP的、HTAP的，完全可以根据需要定制化，集群参数调整、升级等操作可以按需来做；不会出现因为一个业务的需要重启集群，而影响全部业务，风险太高
还有其他的一些因素，比如不同业务的监控、集群敏感性、数据安全管理、404审计等，这里不再详细说明。
具体操作，还是要根据业务情况、家底厚不厚、领导的要求等综合评估才能定
找到平衡点就很容易判断了
比如：隔离要素，不能因为某个业务占用了更多的资源，影响了其他的业务运行…
又比如：叠加要素，因为某个场景占用的资源较少，可以把一堆场景叠加在一起，不会影响资源不足，反而会提高利用率
你的场景是什么呢？
分开部署yyds，以前服务器上搞虚拟机，一个产品分几个虚拟机，到后来，某些产品组分配的资源还不如台笔记本。
分开，必须分开。
老哥说的是反话
一个业务搞100个微服务
卡死 然后集体毕业后大家的简历上多了微服务的经历
100个业务搞100个tidb
大家简历好看
搞多个集群运维成本增加，好处是各个业务互不影响，搞成1个大集群就是平时只需要看护一个集群就可以了，运维成本要小些，中间根据业务特性找个平衡点就好了。
有点像我们的k8s集群，以前一个业务部门一个k8s集群，整个公司差不多200多个集群，现在全部整合到一起了，维护起来省事不少
这个需要搞k8s的团队保证底层可用。tidb的底层根本不需要人维护。
多业务融合应该是趋势吧，可以合理利用资源。
3台物理机的集群同时坏了2台你害怕些 还是30台物理机的集群同时坏了2台你害怕些。
3台物理机的集群同时坏了2台你害怕些 还是30台物理机的集群同时坏了2台你害怕些。
多数时候是后者… 前者最多影响1/10的业务，后者坏2台如果是3节点pd集群同时坏2台直接完犊子，如果运气好坏的是tikv实例，那么某些region会变为单副本无法对外服务，虽然从数据量上来讲也是影响1/10但却是会涉及到所有服务的。
很多算法的核心思想就是分而划之，到这里一样，现实中适合集中部署的场景占比极底，K8S的思想更加契合无状态服务和share nothing的服务，tidb严格说算不上share nothing，集群需要的内部交互太多了。
其实还是得看 集群是否能稳定支撑当前数据量、是否高可用、资源隔离是否到位；
如果从集群的思路来看的话，大数据集群几十几百几千台都很正常，说到底还是稳定…
这里还有一个极端例子
假设是3副本，如果tikv同时2个节点不可用，刚好系统的元数据也在这两个tikv节点上，此时只剩下一个副本了，这个数据不可用，即集群元数据不可用，此时集群整体对外不可用，玩完。。。
所以机器越多，同时坏节点的概率也越高，风险也越大。不过，要它发生也是个小概率事件了，只是小概率事件一旦发生就是大故障
all in one 不可取，如果每个部门就三台机器还不如MySQL集群来的方便了，具体问题具体分析
我怀疑你在我司装了监控，一开始我们搞了N多微服务，后来合并成了两个微服务，一个业务，一个分析。 
从此我们的简历里就多了微服务的经历