实际上这个问题可以从两个部分看1  在你使用pg_resetwal 不指定时间的情况下，并启动数据库发现数据丢失，是由于 WAL日志没有正确应用到数据库中造成的，数据库是通过WAL来保证数据的一致性，那么你的WAL 没有应用对，那么必然数据丢失。但比较遗憾的是，基于操作这对于数据...

个人感觉，从性能出发，小数据量可以容器化，大数据量还是物理机；

OpenShift 的服务注册发现用的是 ectd 。这是一个强一致性的 K-V 数据库。 Etcd 心跳默认是 200ms 。所以，如果跨地域、跨可用区的网络不能满足网络延迟小于 200ms ，那每个环境部署单独的容器云，通过类似 ArgoCD 的 gitops 多集群的应用部署。不建议将 OpenShift 集群跨网络...

建议从以下几方面去考虑：1、数据安全问题，例如 容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。2、性能问题， 关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 读写性能。3、网络问题， 要理解 ...

不适合

由于典型应用程序将具有跨多个主机运行的容器集群，因此所有这些容器都需要相互通信。因此，要做到这一点，你需要一些能够负载平衡，扩展和监控容器的东西。由于Kubernetes与云无关并且可以在任何公共/私有提供商上运行，因此必须是您简化容器化部署的选择。...

微服务的主要好处是一个服务“类型”可以通过使用多个容器实例和负载均衡来扩展以提供吞吐量。从而保证业务的高并发，稳定性。这也是容器化的一大优点。这个容器化的横向扩展，不是由容器本身实现的，而是通过容器编排引擎如kubernetes来实现的，也就是我们通常所说的pod的水平...

对于容器化故障运维保障，需要做到以下几个方面：1 对整个集群的状态，做健康检查，目前可以通过prometheus, Grafana监控系统 ,通过prometheus定期抓取指标，设置告警，送到altermanager,altermanager调用短信网关，或者邮件，就可以下发短信，或者邮件告警，这样运维人员可以立马相应处理...

cAdvisor+Influxdb+Grafana是一套为容器集群性能监控设计的开源解决方案，利用cAdvisor 对容器信息的良好监控能力，Influxdb对时间序列数据的快速检索能力，以及Grafana的强大图标展示能力，形成性能数据的实时查看和历史回溯。日志管理方面，当下最主流的容器日志开源工具组合EL...

从架构上来说,同城双中心可以考虑主备方案注册中心有多种实现方式，最简单的是用容器平台自身的注册机制，部署到两个中心的服务分别注册到两个中心的容器平台，彼此不影响。如果采用Eureka、consul等，也需要考虑主备方式，可能两个中心都需要部署，不管容器化部署或非容器化部署。2...