admin

  • 从XtraBackup的RC版本到1.0版本,一直在使用这个产品进行数据库备份。最近在群里面,依旧有一些在讨论MySQL的备份到底是应该使用物理备份还是逻辑备份。在本文中,我们将比较这两种备份方式,并提供有关它们的概要介绍。

    当前, MySQL 数据库备份,有两种主要的备份方式,即 mysqldump(逻辑备份)和 XtraBackup(物理备份)。

    mysqldump vs Xtrabackup

    mysqldumpXtraBackup
    归属Oracle MySQL(是MySQL的一部分)Percona(是一家非常了不起的MySQL开源服务商)
    备份文件格式SQL(文本)物理数据文件(二进制)
    使用场景小到中型数据库,定期备份和还原,跨版本迁移大型数据库,高性能备份和还原,避免表锁定
    优点– 备份以文本格式存储,易于查看和编辑。– 高性能备份和还原,适用于大型数据库。
    – 跨 MySQL 版本兼容性较好。– 备份期间不会锁定表,对生产环境影响小。
    – 可备份指定数据库、表或查询结果。– 支持增量备份,可节省存储空间和备份时间。
    缺点– 对于大型数据库,备份和还原速度相对较慢。– 备份文件通常较大。(通常压缩率要低一些)
    – 在备份期间,可能会锁定表,影响生产环境查询。– 不容易查看备份内容,因为是二进制备份。
    原理通过导出 SQL 语句来备份数据和结构。备份 InnoDB 存储引擎的物理数据文件和日志文件。
    增量支持不直接支持。(可以通过备份binlog来实现)支持增量备份,可减少备份数据的大小。

    一些其他的重要差异

    两者除了上述差异,根据经验一些重要的建议如下:

    • mysqldump是逻辑备份,在恢复的时候一方面跨版本的效果会更好,因为都是SQL语句;同时,也可能会因为字符集、数据库参数配置(如SQL_MODE等),导致恢复的时候失败或者出现一致性的问题。而XtraBackup是物理备份,数据一致性总是可以保障,但是跨版本恢复能力比较弱。
    • mysqldump的备份与恢复的是官方自带的产品,所以也是被广泛使用的产品,但是因为他在大数据量(例如超过几百GB)时备份的性能、恢复的性能较差,所以,XtraBackup会是很好的补充。
    • 在实践中,XtraBackup也是广泛被使用的,稳定性有比较好的保障,但是配置与使用的成本略微要高一些。在构建自己的复制方案的时候,对于大型的生产系统中,比较建议使用。

    概述mysqldump(逻辑备份)

    概要介绍: mysqldump 是 MySQL 数据库备份的一种经典工具,它通过导出 SQL 语句来备份数据库中的数据和结构。这种备份方式被称为逻辑备份,因为它备份的是数据的逻辑表示,而不是物理数据文件。以下是 mysqldump 的一些关键特点:

    • 适用性: mysqldump 适用于小型到中型的 MySQL 数据库,或者数据库大小不超过几百 GB 的情况。
    • 备份内容: mysqldump 会生成包含 CREATE TABLE 和 INSERT 语句的 SQL 文件,其中包括数据表结构和数据内容。
    • 优点:
      • 数据备份以文本格式存储,易于查看和编辑。
      • 跨 MySQL 版本的兼容性较好,可以在不同版本之间迁移备份数据。
      • 具有备份数据库、表或特定查询结果的灵活性。
    • 缺点:
      • 对于大型数据库,备份和还原速度相对较慢。
      • 在备份期间,数据库可能会锁定表,影响生产环境的查询。
      • 逻辑备份的还原速度相对较慢。

    概述XtraBackup(物理备份)

    概要介绍: XtraBackup 是一种高性能的 MySQL 物理备份工具,主要用于备份 InnoDB 存储引擎的数据文件和二进制日志文件。以下是 XtraBackup 的一些关键特点:

    • 适用性: XtraBackup 适用于大型 MySQL 数据库,对备份性能和恢复速度有高要求的情况。
    • 备份内容: XtraBackup 备份的是数据库的物理数据文件,包括 InnoDB 存储引擎的数据和日志文件。
    • 优点:
      • 高性能备份和还原,特别适用于大型数据库。
      • 备份期间不会锁定表,对生产环境的影响较小。
      • 支持增量备份,可以节省存储空间和备份时间。
    • 缺点:
      • 备份文件通常较大。
      • 不容易查看备份内容,因为它是二进制备份。

    建议

    根据你的数据库需求和性能要求,选择适当的备份方式:

    1. mysqldump: 适用于小型数据库或需要定期备份和还原的数据库,以及对备份文件易于查看和编辑的情况。
    2. XtraBackup: 适用于大型数据库或对备份性能和恢复速度有高要求的数据库,尤其是在需要避免表锁定和支持增量备份的情况下。
    3. 在某些情况下,可以结合使用两种备份方式,以满足不同的需求。这也是一种常用策略。
    4. 无论选择哪种备份方式,都应定期测试备份恢复过程,以确保备份的可用性和完整性。这一点非常重要。

    最终的选择取决于数据库的特定需求和性能要求。根据实际情况,你可以灵活地使用 mysqldump 和 XtraBackup 来满足你的数据库备份和恢复需求。

  • 周末早上探访净慈寺

    ·

    净慈寺

    大概因为杨万里的《晓出净慈寺送林子方》,也让这个禅寺更有一些不同。加上寺院里不时传出悠扬的钟声–“南屏晚钟”(西湖十景之一)更让西湖多添了一份韵味。

    (more…)
  • SQL Server中的Schema、dbo

    ·

    MySQL已经流行了非常长时间,已经有一代数据库从业者最初就是从MySQL起接触数据库。再重新了解其他数据库的时候,虽然底层原理很多类似,但是上层实现、接口与使用上还是有非常大的不同。本文,就简单的介绍一下SQL Server中的Schema、dbo概念。

    参考阅读:

    Schema or dbo or Database?

    这是一个问题。也有很多人做了很多深入的讨论,关于这一点可以参考这篇文章,以及这篇文章后面的100个评论: Why Use Schemas?

    有几个观点吧:

    • 使用Schema的想法是”美好的”,但是实际的情况往往并不理想,甚至是还不如统一使用dbo。文章作者说,随着时间推移,他看到的实际情况是,使用了多个Schema之后,往往不同Schema中存储的内容并是逻辑上在一起的,而是由于各种历史原因,各个业务的数据表都会混杂在一起,这时候,由于修改应用的成本太高,大家也往往也不会去移动Schema下的表,去让他们在逻辑上更加合理。所以,基于此,作者并不赞同使用Schema,而是倾向于在需要的时候使用不同的Database去隔离逻辑上没什么关系的数据表。
    • 很多的第三方的应用,都是使用一个数据库、一个用户访问所有的数据表,因此Schema方式虽然很理想,但是现实世界并不常用。
    • 另一方观点是在于,在一个设计较好的数据库中,Schema可以很好的对不同的数据表进行分组,例如,用户相关的表,库存相关的表,店铺相关的表等。另外,在基于这样设计下,权限系统也会更加好管理。另外,否则可能会使用大量的前缀的方式(例如,user_开头代表用户,shop_开头代表店铺相关业务)来区分这些表,看起来并不整齐,整体的授权管理也会比较难一些。
    • 比较多人,认为虽然多Schema的设计,前期是比较理想的,但是随着业务和需求的变化,表的业务属性也会发生变化,按照多Schema设计来说,这时候是需要将表移动到合适的Schema下面,但是因为代码的SQL中都带有Schema,这就到这个”移动”的操作变得异常困难,所以也就会最终一定会破坏当初使用Schema的初衷。
    • 很多人认为,所有表放在dbo中,从业务角度来说,其实问题是最少的。
    • 有人提到,他这样使用schema,将所有的基础表都放在dbo中,但是某些特殊用户的表或者对象放在特定的schema中。例如,一些特定用途的视图、存储过程等。这样,更加便于权限管理。(个人注:这似乎是一种非常适合schema的场景)
    • (Mark Broadbent)提到,相比Oracle数据库的Schema,SQL Server权限系统设计更加面向的是Database,而不是Schema。用户通常都有多个Schema的访问权限。
    • Ben Thul提到,在大量存储过程的权限管理过程中,schema应该是非常有效的。这和前面的观点是有一定的相似的。Brent Ozar则认为,权限管理更多是通过用户角色组来管理,就可以了。Ben Thul也反驳到,当你已经有100个存储过程的时候,当写101个存储过程,如果没有schema,那么还是要单独管理这个存储过程的访问权限,这时候如果通过以schema为单位的权限管理,确实是高效的。
    • 有来曾经在MSFT PMs相关项目的员工(Clifford Dibble),回忆schema设计的初衷如下:
      • 在单个数据库中,提供一种命名空间隔离的方式
      • 在使用GRANT语句授权时,大大简化对一组对象进行授权管理
      • 微软公司内部”WinFS”团队需要该功能
      • 与ANSI/ISO SQL有更好的兼容性
      • SQL Server自己需要一个系统使用schema:sys
      • 让用户删除更加简单(有一些明确的客户需要)
      • 允许让角色组作为schema的owner
      • 允许多个用户都有某个特定的默认schema
    • vinod jain在2021年给出回答(是的,这个帖子是2010年发的,这个讨论延续了11年)有一定代表性,也是两种观点的一个中间形态:
      • 所有的核心表全部都放在dbo中
      • 其他的辅助功能表都独立放在不同的schema中,例如结构记录变更时用到的临时表和数据、导入导出时的中间表、用户日志表
  • 重要更新

    构建实时分析和搜索的数据库Rockset获得4400万美元融资,该产品致力于简化实时索引构建与使用:参考 参考

    最近,数据库学术会议VLDB在加拿大举行,阿里以及相关合作共有17篇论文入选。阿里云数据库负责人李飞飞受邀发表主旨演讲《Modernization of Databases in the Cloud Era: Building Databases that Run Like Legos》:参考

    阿里云PolarDB发布了1核1 GB入门规格,最低月价格约21元(计算11+存储10),如果只是需要一个测试MySQL的话,真的是没必要自己安装了,折腾一小时的成本也不止这个价格: 参考

    云数据库更新详情

    阿里云
    • PolarDB 推出1核1 GB入门规格,计算节点包月仅需11元/月: 参考
    • PolarDB 优化了冷数据归档到OSS的效率,修复了若干问题:参考
    • 托管MongoDB 新增存储类型ESSD AutoPL云盘:参考
    • 托管MongoDB 分片集群实例支持回收站功能:参考
    腾讯云
    • 云数据库支持 SQL Server 2022 Enterprise ,支持云盘版架构双节点、单节点:参考
    • 云数据库 SQL Server 云盘版架构单双节点支持修改系统字符集排序规则、支持修改系统时区:参考
    火山云
    • RDS SQL Server 支持将实例的私有网络 VPC 域名在公网环境下解析为私网 IP 地址:参考
    • RDS SQL Server 支持按时间点和备份集将数据恢复到已有实例:参考
    • RDS SQL Server 备份时间窗口的时间粒度由 6 小时改为 1 小时,方便您更加灵活地调整备份执行时间:参考
    AWS
    • RDS PostgreSQL 13/14版本支持了 PL/Rust: 参考
    • RDS MySQL/MariaDB写优化实例新增m6i/m6g实例支持: 参考
    • Aurora MySQL 支持使用Xtrabackup物理迁入数据:参考
    Azure
    • 托管 PostgreSQL支持了多个最新的小版本: 参考
    • 托管MySQL支持跨区域的恢复能力: 参考
    GCP
    • 发布 BigQuery Studio,向用户提供完整的数据分析体验: 参考
    • Cloud Spanner Studio 集成 Duet AI,帮助用户通过更高效使用Spanner:参考
  • 最近,Google Cloud SQL(Google云上的RDS)做了一次大的产品调整与发布:将原来的Cloud SQL分为了两个版本,分别为”Enterprise”和”Enterprise Plus”版本。本文概述了两个版本的异同,以帮助大家更好的了解Google Cloud SQL。

    关于”Enterprise”和”Enterprise Plus”版的Cloud SQL实例

    整体上:

    • Google Cloud SQL相当于AWS或阿里云平台的RDS,Cloud SQL for MySQL就相当于AWS RDS for MySQL
    • 这次调整之后,原来的Cloud SQL for MySQL/PostgreSQL全部变更为Enterprise版本,价格和产品本身没有什么改动,只是名称发生了变化
    • 新增的Enterprise Plus版本提供了更高的产品能力,例如通过硬件/软件优化提供的Data Cache能力,可以提升MySQL的读取和写入性能;Enterprise Plus还提供了更大的规格、更灵活的CPU/内存配比等能力
    • Enterprise Plus资源的价格比Enterprise版本贵约30%,Data Cache空间是额外计费的
    • 本质上,猜测,Enterprise Plus使用了更新更强的机型,具备非常强的本地存储能力(本地可能使用NVMe SSD或者其他存储设备),在数据库层则利用该能力使得用户获得更好的读与写的能力
    • 从产品发布节奏来看,今年GCP(Google云)增加了在Cloud SQL上的投入,这一点与阿里云现在应该是比较类似的。而在以前,在Google数据产品体系中,Spanner、AlloyDB或者BigTable才是投入最大的产品,而Cloud SQL似乎不受重视。现在大概发现,无论Spanner、AlloyDB架构多领先,最简单的Cloud SQL才一直都是更多用户的首选。
    • 这次更名调整,感觉是比较混乱的。对于Cloud SQL for MySQL来说,”Enterprise”和”Enterprise Plus”之间的区别还是比较明显,一个有Data Cache、另一个没有。但对于PostgreSQL来说,两者的区别更像是对资源多少的使用的一种简单限制(最大规格、cpu内存比、PITR的时间限制等)。另外,当前SQL Server又并不区分这两个类型。所以,整体给人感觉比较混乱。而像AWS Aurora新增一个I/O-Optimized选项的做法可能会更简单一点。GCP这种”化简为繁”做法,也许和业务的压力有一定的关系,更像是为了概念而做的产品决策,最终让用户对混乱的产品名称和定位买单,这种事情在大公司的企业级产品中,还是经常出现的。事情做不了什么突破,那么就在产品名称上做一些突破吧(这是一段不负责任的“臆断”,谨慎参考)。
    (more…)
  • 重要更新

    据悉,OceanBase可能会从蚂蚁集团剥离出来,同时厘清和海外投资者的关系,以更好支持国内的核心行业的核心系统:参考 参考

    中国数据库技术大会在北京举行,错过的朋友可以参考如下内容做个回顾:

    更新详情

    阿里云
    • PolarDB优化了”存储包”抵扣项,包含了包括备份、冷存储等项目的计费:参考
    • PolarDB 分布式版日志节点新增flush logs命令、优化了CDC多项功能、AUTO模式新增default_single选项
    腾讯云
    • 云数据库 MySQL 优化实例详情页面,支持查看实例健康状态、异常告警,增加实例在可用性、性能与安全方面的配置展示:参考
    • TDSQL-C Serverless 集群支持挂载只读实例,支持单独配置只读实例算力区间,支持只读实例自动启停,提升读取性能和并发度,减轻主实例的负载压力:参考
    火山云
    • 数据库工作台 DBW 慢日志分析功能支持查看云数据库 veDB MySQL 版实例的慢日志趋势、统计和明细。同时,可按需下载慢日志分析结果:参考
    AWS
    • RDS for MariaDB 现在支持 MariaDB 10.11,事务吞吐量提高了 40%: 参考
    • Amazon Aurora 全球数据库推出全局数据库故障转移(Failover): 参考
    GCP
    • Cloud Spanner 新增支持德国柏林 (europe-west10) 地区: 参考
    • Cloud SQL for PostgreSQL 新增支持德国柏林 (europe-west10) 地区
    • Cloud SQL for MySQL、PostgreSQL支持了Private Service Connect: 参考
    • Spanner Studio 增强了查询编辑器功能,完全支持 SQL、DML 和 DDL 操作
    • Cloud SQL for MySQL 现在支持版本 8.0.34