首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    面试题107:如果需要分库分表,数据是如何做迁移的?

    当我们在初创公司或者公司的一个新的业务线的初期,通常来说不会采用分库分表的,但是随着业务发展,就会有需要分库分表的情况产生。那么针对于之前单库表中的数据我们如何迁移到新的分库分表上呢?我们最先想到的方案应该就是发公告停机停服的数据迁移。 停机停服数据迁移 比如我们已经准备好某一天要进行数据迁移了,那么我会们在当天发布公告,比如通告一下用户,凌晨12点到早上6点系统升级,服务暂不可用。那么到了凌晨12点,所有服务停机,并观察数据库中是否还有数据写入变更删除等操作,如果发现现在数据库中的数据已经静止了,那么一部

    04

    我的一点企业上云经验

    作者按:日前,工信部印发《推动企业上云实施指南(2018—2020年)》,其中指出:到2020年,力争实现企业上云环境进一步优化,行业企业上云意识和积极性明显提高,上云比例和应用深度显著提升,云计算在企业生产、经营、管理中的应用广泛普及,全国新增上云企业100万家,形成典型标杆应用案例100个以上,形成一批有影响力、带动力的云平台和企业上云体验中心。统计数字表明,当前传统企业用户“上云”的比例仅为20%,仍有高达70%以上的传统企业没有“上云”。本文是作者在HH集团作为企业上云项目技术负责人在项目完成后,对这次企业上云历程的一些总结以及思考。

    03

    虹科方案|在虚拟化环境中使用ATTO XstreamCORE®智能网桥的安全、简单SAN解决方案

    在具有外部串行连接存储 (SAS) 阵列的典型直连环境中,使用 vMotion® 完成从一台 ESXi 主机到另一台主机的数据传输可能需要数小时,即使遵循了隔离 vMotion 网络的正确建议也是如此。除了常见的负载均衡迁移,vMotion 迁移虚拟机 (VM) 最关键的时间通常是主机资源关闭或处于胁迫状态时。在这些情况下,据观察,运行大约 250-400 GB大小的VM 需要30多个小时才能完成迁移。在这些环境中,避免这种情况的最佳方法是使用存储区域网络 (SAN) 技术。 在SAN环境中,这些实时vMotion迁移可能需要不到三分钟的时间,因为所有ESXi主机都连接到所有存储阵列。

    02

    【JavaP6大纲】MySQL篇:现在有一个未分库分表的系统,未来要分库分表,如何设计才可以让系统从未分库分表动态切换到分库分表上?

    我先给你说一个最 low 的方案,就是很简单,大家伙儿凌晨 12 点开始运维,网站或者 app 挂个公告,说 0 点到早上 6 点进行运维,无法访问。 接着到 0 点停机,系统停掉,没有流量写入了,此时老的单库单表数据库静止了。然后你之前得写好一个导数的一次性工具,此时直接跑起来,然后将单库单表的数据哗哗哗读出来,写到分库分表里面去。 导数完了之后,就 ok 了,修改系统的数据库连接配置啥的,包括可能代码和 SQL 也许有修改,那你就用最新的代码,然后直接启动连到新的分库分表上去。 验证一下,ok 了,完美,大家伸个懒腰,看看看凌晨 4 点钟的北京夜景,打个滴滴回家吧。 但是这个方案比较 low,谁都能干,我们来看看高大上一点的方案。

    02

    【JavaP6大纲】MySQL篇:如何设计可以动态扩容缩容的分库分表方案?

    对于分库分表来说,主要是面对以下问题: 选择一个数据库中间件,调研、学习、测试; 设计你的分库分表的一个方案,你要分成多少个库,每个库分成多少个表,比如 3 个库,每个库 4 个表; 基于选择好的数据库中间件,以及在测试环境建立好的分库分表的环境,然后测试一下能否正常进行分库分表的读写; 完成单库单表到分库分表的迁移,双写方案; 线上系统开始基于分库分表对外提供服务; 扩容了,扩容成 6 个库,每个库需要 12 个表,你怎么来增加更多库和表呢? 这个是你必须面对的一个事儿,就是你已经弄好分库分表方案了,然后一堆库和表都建好了,基于分库分表中间件的代码开发啥的都好了,测试都 ok 了,数据能均匀分布到各个库和各个表里去,而且接着你还通过双写的方案咔嚓一下上了系统,已经直接基于分库分表方案在搞了。 那么现在问题来了,你现在这些库和表又支撑不住了,要继续扩容咋办?这个可能就是说你的每个库的容量又快满了,或者是你的表数据量又太大了,也可能是你每个库的写并发太高了,你得继续扩容。这都是玩儿分库分表线上必须经历的事儿。

    04

    腾讯会议核心存储治理:Redis分库和异地多活

    会控为整个会议最为核心的业务,由于海量请求的高性能要求,后台存储全部为 Redis。在业务飞速发展期,各模块边界不够清晰,大家对存储的使用处于失控状态,随着 PCU 的不断上涨,逐步暴露出存储和架构的诸多问题,同时也对系统容灾能力有了更高的要求。会控业务历史包袱重,存储改造伤筋动骨,要做到平滑迁移需要考虑的细节较多。有幸作为 owner 负责(2022.12-2023.08)了会控存储的优化改造,本文主要从业务、个人和企业数据分库、异地容灾和多活(下一步目标)层面总结了会控存储治理的成功实践,目的是形成一套方法论,沉淀下来一套可以复用的工具,以供大家后续工作中参考。

    03
    领券