我觉得,同城其实不是演练,是实操。异地的代价很大,才需要以演练的形式来做。
我觉得关键是有总体规划,系统建设时就预先定好容灾级别、各种策略。这样才能估算好各种资源。在公有云上运营系统,如果建设时合规做得好,容灾时合规这块特殊的地方就不多了
保险行业内保险公司可分为原保险、再保险,中介分为专业代理、兼业代理、经纪,还有公估……这么多业态,不能一概而论。即便是业务连续性做的比较好的原保险公司,在RTO/RPO的指标上也有差距。但是从大的趋势来说,随着业务的
保险行业内可以继续分为保险公司、中介公司、公估公司。不同的细分领域对系统服务的连续性要求差异很大。监管近年来逐渐从严治理,有向银行业看齐的趋势;另外,由于互联网渠道、综合性服务功能逐渐成为主流,对服务的要求也
希望您是在演习的时候发现的问题。系统依赖关系是灾备设计甚至架构设计时就必须考虑的,哪些外围系统要保持松耦合,有些系统属于核心必须同步切换都要设计好。如果真是到了事件发生、正式切换后在发现,就得具体情况评估,看
一堆小文件,比较适合做对象存储,方案也比较成熟。感觉难点有2个,一是开发要配合,二是归档策略要预先设计好。这些文件平时是基本用不到的,占用高成本资源有点不划算。
只读的库至少可以做bi的数据源吧?如果开发能配合做到读写分离,那么适当调整分表分库,性能有提升数量级的可能。
别忘了改表之前先统计,确定优化方案。然后重建,然后导入数据,改表名,重绑定。同时通知开发优化策略(主要是分区字段)。运行一段时间再统计一下,总结优化效果。
看了上边各位专家的建议,很受启发。感觉如果数据库之前没有做过优化的话,慢点删也是可以接受的。最好不要做ddl操作,虽然快,有可能涉及重绑定等问题。写到这里,请问一下,您确认过这个表和其他数据对象的依赖关系吗?如果能这
rsh可以用吗?
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30