备份与恢复⼯具BR:https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-tool
最近在看TiDB的系统管理课程,对TiDB周边的配套工具做了一下了解,今天总结下。
作为一名MySQL DBA,就应该了解MySQL备份无论是逻辑备份还是物理备份,都会使用FLUSH TABLES WITH READ LOCK(下面简称FTWRL)锁来保证数据库备份的一致性。
数据库作为基础设施,其安全性不言而明,因此数据安全备份和恢复功能是在严肃使用场景下的标配。TiDB 作为一款分布式数据库,目前可以满足超大集群的备份恢复的需求,经过测试,10T 数据的备份恢复速度可以达到 GB/s 级别。这得益于我们研发的分布式备份恢复工具 Backup&Restore That Scales(以下简称 BR)。
本文介绍了 TiDB 数据库的基于时间点的恢复(PiTR)特性,该特性允许用户将数据库恢复到特定时间点,从而避免丢失重要数据。文章首先介绍了 PiTR 技术的基本概念和工作原理,接着探讨了 TiDB 对 PiTR 的优化,包括 PiTR 的技术指标,稳定性和性能提升。最后,文章展望了 TiDB PiTR 未来的改进方向,将持续探索备份恢复的更多可能性。
本文档将详细介绍如何对 TiDB 进行全量备份与恢复。增量备份与恢复可使用 TiDB Binlog。
TiDB Binlog 组件用于收集 TiDB 的 binlog,并准实时同步给下游,如:TiDB/MySQL等。该组件在功能上类似于 MySQL 的主从复制,会收集各个 TiDB 实例产生的 binlog,并按事务提交的时间排序,全局有序的将数据同步至下游。利用 TiDB Binlog 可以实现数据准实时同步到其他数据库,以及 TiDB 数据准实时的备份与恢复。TiDB Binlog 作为 TiDB 的核心组件之一,已经在上百家用户的生产环境中长时间稳定运行。
学习一款数据库,要学会备份和恢复。备份是一个严谨的工作,作为一个dba,掌握数据库备份、恢复的各种手段。
在上篇文章中,我司 CTO 黄东旭分享了 我们对“未来数据库”的展望,很高兴我们一直走在「写一个更好的数据库」的初心之路上。4 月 8 日是 PingCAP 成立五周年的日子,我们也在这一天发布了具有里程碑意义的 TiDB 4.0 首个 RC 版本。
分库分表是一个非常普遍的问题,会增加我们业务逻辑的复杂性,并且多维度的 mapping 可能导致我们整体性能的下降。有了 TiDB 我们可以不用再考虑分库分表,不再需要写那么多的复杂逻辑。
TiDB在集群部署方便可以说非常的方便,尤其是4.0版本引入了TiUP集群运维工具,日常管理维护非常的方便;通过 TiUP cluster 组件就可以进行日常的运维工作,包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群,以及管理 TiDB 集群参数。目前 TiUP 可以支持部署 TiDB、TiFlash、TiDB Binlog、TiCDC,以及监控系统。
TiDB4.0版本在4月份发布了RC版本,新增一些好用的功能:TiUP、BR、Dashboard、TiFlash、大事务的支持等等一些新功能,让我们快来体验一下吧。
数据库的备份在普通的数据库是很正常不过的,但对于分布式数据库来说,备份是比较复杂. 下面就的说说TIDB 分布式数据库的备份和恢复的问题了.
本文主要分享 TiDB 4.0 版本在 VIPKID 的一个应用实践。主要涉及两个部分,第一部分是现在 TiDB 在 VIPKID 的一些应用场景,第二部分是介绍一下 TiDB 4.0 给我们带来哪些惊喜和收益。
本文主要介绍了如何使用 Ansible 在 Kubernetes 集群中部署 TiDB 和 TiKV 集群,包括初始化集群、安装组件、配置数据同步和集群巡检等。
在2023 伊始,我们很高兴向大家宣布,TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版(上一个是 TiDB 6.1),除了携带了诸多备受期待的新特性,同时也将得到 TiDB 开发社区的长期维护,是推荐企业级用户采用的最新版本。
对于金融企业来说,尤其是银行、证券、保险这些行业,在一个 IT 系统运行支撑业务的过程当中,考虑到硬件的故障、网络的故障,等一切可能会对业务产生影响的突发故障。那么,在过去漫长的 IT 发展的过程当中,大量的技术被应用在关于如何解决组件级的高可用,整个服务的容灾和灾备,包括如何保证整体业务的连续性。
TiDB Binlog(github.com/pingcap/tidb-binlog)用于收集 TiDB 的 binlog,并准实时同步给下游。 同步数据这一步重要操作由 Drainer 模块支持,它可以将 binlog 同步到 TiDB / MySQL / Kafka / File (增量备份)等下游组件。
在 2023 伊始,我们很高兴向大家宣布,TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版(上一个是 TiDB 6.1),除了携带了诸多备受期待的新特性,同时也将得到 TiDB 开发社区的长期维护,是推荐企业级用户采用的最新版本。
本文介绍了企查查在数据中台建设中使用 TiDB 的经验和应用。通过从 MySQL 到 TiDB 的迁移,企查查构建了基于 TiDB+ Flink 的实时数仓框架 ,充分利用了 TiDB 的分布式架构、MySQL 兼容性和完善的周边工具等特性,实现了数据的在线化处理。2023 年 9 月,企查查的 TiDB 数据库已升级至 v7.1.1 版本。文章还分享了企查查在使用 TiDB 过程中的一些好用特性和版本升级经验,包括 TiDB 开源社区的活跃以及 TiDB 的稳定性对其决策的重要性。
株式会社 FUNYOURS JAPAN 自 2014 在日本成立以来,营运多款颇受好评的页游跟手游,如:剣戟のソティラス、九十九姬 等,对于营运游戏来说,能够了解游戏中的玩家在做什么,喜欢的偏好是什么,关卡的设计是否平衡,都是相当重要的,所以随着营运时间的增长,资料库数据在亿笔以上也是寻常的。
TiDB Binlog 组件用于收集 TiDB 的 binlog,并准实时同步给下游,如 TiDB、MySQL 等。该组件在功能上类似于 MySQL 的主从复制,会收集各个 TiDB 实例产生的 binlog,并按事务提交的时间排序,全局有序的将数据同步至下游。利用 TiDB Binlog 可以实现数据准实时同步到其他数据库,以及 TiDB 数据准实时的备份与恢复。随着大家使用的广泛和深入,我们遇到了不少由于对 TiDB Binlog 原理不理解而错误使用的情况,也发现了一些 TiDB Binlog 支持并不完善的场景和可以改进的设计。
TiDB 5.4 作为 2022 年开山之作,包含了许多有用有益的新功能和持续性的性能/稳定性提升。本文着重介绍重要新增功能和特性所带给用户的新体验和价值,按照以下章节来组织:
所以在我们引入前从以下六个方面分别对 TiDB 进行测试验证,其中功能与架构、配置与管理、备份与恢复都是针对我们运维管理,SQL 特性、基准测试、应用场景测试则是应对业务需求和业务场景的。
线上tidb集群都是2.1.[5,7,8,17],因版本太低,面临诸多问题,比如管理难度大,热点问题,执行计划失效,性能瓶颈,其他已知/未知且无法解决的问题,现在需要升级至4.0.13版本。在调研后发现,如果原地升级将需要多次升级【2.1--> 3.0 --> 4.0】,担心原地升级遇到不可逆的故障,更担心的是解决不掉而影响业务,所以经过测试和评估,最终采用数据迁移的方式进行升级。
随着 TiDB Operator 社区的壮大,越来越多的开发者参与到了 TiDB Operator 的开发中。目前,TiDB Operator 的开发门槛比较高,需要开发者对 TiDB Operator 的代码进行详细阅读之后才能了解到项目的全貌。有鉴于此,我们希望系统性地介绍一下 TiDB Operator 的代码细节,为刚入门的开发者提供指导,提供一份长期的查阅手册。通过这一系列文章,我们希望能扫清 TiDB Operator 理解的障碍,让更多的创意在社区中萌发。
自 TiDB 5.0 发布以来,陆续在金融、互联网 & 新经济、物流等行业用户的生产环境得到应用,收获不少用户的积极评价:
计费组是为网易互娱产品提供统一登录和支付高效解决方案的公共支持部门,对内是互娱的各个游戏工作室,对外是国内外数百个渠道。由于业务场景的特殊性,我们为各个游戏产品部署了不同的应用服务,其中大产品环境独立,小产品集中部署。
首先对我来说,我觉得能够开发数据库,而且能够有很深的技术情结,真是一件很cool的事情,我比较欣赏极客精神,同时满足了业务,也在技术上的价值得以体现,这种模式值得很多开源项目参考借鉴。
TiDB 作为一款高效稳定的开源分布式数据库,在国内外的银行、证券、保险、在线支付和金融科技行业得到了普遍应用,并在约 20 多种不同的金融业务场景中支撑着用户的关键计算。在TiDB 在金融行业关键业务场景的实践(上篇)中,我们介绍了 TiDB 在银行核心交易场景的应用,本篇文章将主要分享 TiDB 在核心外围的关键业务场景的实践。
大家好,我是PingCAP CEO刘奇。今天我将和大家分享一下如何构建一个NewSQL数据库。 首先,来介绍下我自己。和你们当中很多人一样,我是一名开源Hacker,一名架构工程师,并长期致力于创建新一代数据库。我曾投身于以下几个开源项目的工作,包括TiKV、TiDB 和Codis,这些项目都已在Github上发布。今天,我的演讲将涉及下列话题: 简要介绍NewSQL; 如何建立一个NewSQL数据库; 以及roadmap。 ▌为什么我们需要一个新的数据库? 在正式开始前,我先问一个
Mydumper 采用更先进的Stream流式管道技术,能够通过一条命令实现备份和恢复,显著加快了恢复速度。它可以:
本文介绍了某省妇幼健康管理系统的建设和数据库架构优化的过程。原有的数据库架构使用了 StarRocks 作为分析层,但随着业务的发展,这套架构暴露出诸多痛点,不再适应妇幼业务的需求。为解决这些问题,该系统选择了将原有架构中的 StarRocks 替换为 TiFlash 组件,并引入了 Yearning 自动化 SQL 审计平台,提高了运维效率和业务扩展能力。新架构在人力成本释放、运维成本降低等方面取得了显著的成效。
曾几何时,人们在换手机时如何将数据备份/恢复还是一个令人头疼的问题。iCloud 的出现将 iPhone 的备份管理解决得无比漂亮,而且非常深入人心,现在 iPhone 用户换手机已经是一件没什么压力的事情。
60 云平台对 360 集团各大业务线均有提供服务支持,涉及的数据库支持方案有:MySQL、Redis、MongoDB、ES、GP、PiKA。
TiDB v6.2 于 8 月 23 日发布了。在全新的版本中,TiDB 提供了诸多方面的提升,它们主要集中于:可观测性、性能、稳定性、数据生态加强以及 MySQL 兼容几个领域。
这是一个关于世界级别的数据库信息的翻译性的系列,相关信息来自于世界级的IT 或 数据库信息类网站。相关文章来自于世界级的world IT info 网站
咪咕是中国移动旗下的视频科技公司,门户系统是其核心业务之一。 为满足用户的多样化需求,咪咕计划对其数据库进行升级。 经过对中国主流国产数据库的测试评估后,咪咕选择了 TiDB,并成功将其落地于门户系统云化项目。 TiDB 为咪咕在业务增长、高可用性、性能提升、数据整合等方面带来了显著价值。 未来,咪咕计划拓展 TiDB 在更多业务场景中的应用,助力其业务创新和降本增效 。
TiDB是开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理(Hybrid Transactional and Analytical Processing, HTAP)的融合型分布式数据库产品,具备水平扩容、缩容、金融级高可用、实时HTAP、云原生的分布式数据库、兼容MySQL5.7协议和MySQL生态等重要特性。目标是为用户提供一站式OLTP(OnlineTransactionalProcessing)、OLAP(OnlineAnalyticalProcessing)、HTAP解决方案。
经过一年多的开发,TiDB 4.0 终于迎来 GA 版本,作为 TiDB「面向未来的数据库」道路上面的一个重要的里程碑,TiDB 4.0 不光在稳定性、易用性、性能、云原生等各个方面都有了巨大的进步,新增的特性也让 TiDB 产品能够支持更多元的业务类型。
数字化时代下,企业的发展与数据库的建设息息相关。如果搭建云下数据库,不仅要通过大量的运维投入保证数据库稳定运行,随着企业规模与数据量的发展,还要应对数据库扩容、弹性、运维、备份等各种各样的问题,云下数据库对企业提出的要求日益增长。此时有两种应对之法,一是凭借扩充技术团队解决问题,但这无疑将会带来不菲的运维与人员成本,二则是把一切交给云服务。
**TiDB-Lightning Toolset 是一套快速全量导入 SQL dump 文件到 TiDB 集群的工具集**,自 2.1.0 版本起随 TiDB 发布,最新的测试结果显示,速度可达到传统执行 SQL 导入方式的至少 5 倍,导入 1T 数据需要 5 ~ 6 个小时,适合在上线前用作迁移现有的大型数据库到全新的 TiDB 集群。
天翼电子商务有限公司(翼支付)成立于 2011 年 3 月,是中国电信股份有限公司的全资子公司、中国人民银行核准的第三方支付机构、中国证监会核准的基金支付结算机构,是中国电信布局互联网金融的重要板块,是行业领先的创新型金融科技企业。业务覆盖全国近 400 个主要城市,注册用户超 5 亿,合作商户超过 1000 万,覆盖餐饮、娱乐、交通出行、电商购物、民生缴费,通信交费等多个生活场景的便民服务。秉承“响应监管、服务民生、资源共享、合作共赢”的理念,致力于打造安全、便捷、时尚的支付解决方案。
MySQL在达到一定数据量(我的经验是3T、单表1亿)时,复杂查询会有明显的延迟。继续分库分表,会严重增加业务复杂性,尤其对很多非互联网产品来说,急需一个分布式存储。
TiDB-Lightning Toolset 是一套快速全量导入 SQL dump 文件到 TiDB 集群的工具集,自 2.1.0 版本起随 TiDB 发布,速度可达到传统执行 SQL 导入方式的至少 3 倍、大约每小时 100 GB,适合在上线前用作迁移现有的大型数据库到全新的 TiDB 集群。
TiDB Binlog 主要由 Pump 和 Drainer 两部分组成,其中 Pump 负责存储 TiDB 产生的 binlog 并向 Drainer 提供按时间戳查询和读取 binlog 的服务,Drainer 负责将获取后的 binlog 合并排序再以合适的格式保存到对接的下游组件。
vivo 是一家全球性的移动互联网智能终端公司,品牌产品包括智能手机、平板电脑、智能手表等 ,截至 2022 年 8 月,已进驻 60 多个国家和地区,全球用户覆盖 4 亿多人。
得物 App 从创立之初,关系型数据库一直使用的开源数据库产品 MySQL。和绝大部分互联网公司一样,随着业务高速增长、数据量逐步增多,单实例、单库、单表出现性能瓶颈和存储瓶颈。从选型和架构设计角度来看这很符合发展规律,一开始没必要引入过于复杂的架构导致资源成本和开发成本过高,而是逐步随着业务发展速度去迭代架构。为了应对这些问题,我们采取了诸多措施如单库按业务逻辑拆分成多个库的垂直拆分,分库分表的水平拆分、一主多从读写分离等。这些技改同时也使得整个业务层架构更加复杂,且无法做到透明的弹性,因此我们逐步把目光转向了已经趋于成熟的分布式关系型数据库 TiDB。
本文根据 PingCAP DevCon 2021 上来自微众银行资深数据库架构师黄蔚的分享整理而成,主要阐述 TiDB 在微众银行的应用实践,包括微众银行选择 TiDB 的背景和 TiDB 的部署架构,以及 TiDB 在贷款核心批量场景的应用,最后分享了基于 TiDB 优化方案的最佳实践和未来规划。
领取专属 10元无门槛券
手把手带您无忧上云