我们的解决策略是:只做大版本升级,减少升级次数。 厂商经常会做一些打补丁、优化的操作,大部分都是小版本更新,那么除非对业务或应用影响大的情况会单独升级,否则我们会把所有小版本更新集中到一个包里,一次性做个较大版本
目前我们测试的几款分布式数据库,对存储过程支持度并不好。所以对于存储过程,我们做了上移,放到应用侧去实现逻辑了。
管理集群放在一地,统一管理。在异地建一套备份管理集群。
人员增加,这个看贵司有无招聘计划。从技术角度,建议引入1-2名有经验的人士。 我司还是原班人马,兼做分布式数据库运维。 运维工作量在引入之初增加了接近100%,因为要参加新技术培训、解决各种问题、负责双轨数据库的维护
两地三中心的话,两地一般都会离得很远,异地中心一定会有延迟。所以一般把异地灾备中心里的分部署数据库副本仅作为从副本,主副本都设置在同城两中心,并且同城副本数占大多数。
双轨运行。直至平稳后再切单轨。 双轨运行的目的就是在真实业务数据中查漏补缺,找到分布式数据库的不足,该调优去调优,该让应用改造去改造。 异构备份不一定有效,因为分布式数据库并不是100%兼容传统数据库的。
数据同步用的binlog和厂商自带工具。只在迁移时做了数据同步,上线后不再有数据连通性。 备份恢复验证频率根据自己的需求。验证时也分全量数据恢复、部分库表恢复等不同的层级。全量数据恢复定期做一次,比如半年、一年;
选择物理机还是虚拟机的问题,可能更多的是预算层面的问题。 单纯从技术角度来说,计算节点建议选物理机,管理节点选虚拟机。 即使上云,云化资源池中也有物理机和虚拟机资源之分,如果贵行的云资源池全部做了虚拟化,那么还是建
如果开展市场调研,几乎所有的分布式数据库都在推出 for mysql和for oracle的版本,宣称兼容语法。 我们在选型的时候,特别测试了兼容性,选取了真实业务代码,覆盖常用的业务数据库使用场景,去进行了测试。在测试过程中进行
第一步调研: 市场调研 产品调研,包括需求初应答、产品应用案例等 同业调研,技术交流 第二步测试: POC 测试方案; 测试产品关键功能点; 可移植性测试。 第三步综合选型采购: 综合考虑技术测试结果、非技术因素,采购产
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30