admin
-
从XtraBackup的RC版本到1.0版本，一直在使用这个产品进行数据库备份。最近在群里面，依旧有一些在讨论MySQL的备份到底是应该使用物理备份还是逻辑备份。在本文中，我们将比较这两种备份方式，并提供有关它们的概要介绍。
当前， MySQL 数据库备份，有两种主要的备份方式，即 mysqldump（逻辑备份）和 XtraBackup（物理备份）。
mysqldump vs Xtrabackup
mysqldump XtraBackup 归属 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 存储引擎的数据和日志文件。
- 优点：
- 高性能备份和还原，特别适用于大型数据库。
- 备份期间不会锁定表，对生产环境的影响较小。
- 支持增量备份，可以节省存储空间和备份时间。
- 缺点：
- 备份文件通常较大。
- 不容易查看备份内容，因为它是二进制备份。
建议
根据你的数据库需求和性能要求，选择适当的备份方式：
- mysqldump： 适用于小型数据库或需要定期备份和还原的数据库，以及对备份文件易于查看和编辑的情况。
- XtraBackup： 适用于大型数据库或对备份性能和恢复速度有高要求的数据库，尤其是在需要避免表锁定和支持增量备份的情况下。
- 在某些情况下，可以结合使用两种备份方式，以满足不同的需求。这也是一种常用策略。
- 无论选择哪种备份方式，都应定期测试备份恢复过程，以确保备份的可用性和完整性。这一点非常重要。
最终的选择取决于数据库的特定需求和性能要求。根据实际情况，你可以灵活地使用 mysqldump 和 XtraBackup 来满足你的数据库备份和恢复需求。
-
MySQL已经流行了非常长时间，已经有一代数据库从业者最初就是从MySQL起接触数据库。再重新了解其他数据库的时候，虽然底层原理很多类似，但是上层实现、接口与使用上还是有非常大的不同。本文，就简单的介绍一下SQL Server中的Schema、dbo概念。
参考阅读：
- Why do table names in SQL Server start with “dbo”?@2013年
- Understanding the Difference between Owners and Schemas in SQL Server@2007年
- dbo User and dbo Schema@Microsoft SQL Docs SQL Server 2019
- Create a database schema@Microsoft SQL Docs SQL Server 2019
- CREATE SCHEMA (Transact-SQL)@Microsoft SQL Docs SQL Server 2019
- Why Use Schemas? 这时一篇延续了11年的关于是否应该使用Schema的争论，所以，你的观点是什么？你的实践经验是什么？
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
GCP
-
最近，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这种”化简为繁”做法，也许和业务的压力有一定的关系，更像是为了概念而做的产品决策，最终让用户对混乱的产品名称和定位买单，这种事情在大公司的企业级产品中，还是经常出现的。事情做不了什么突破，那么就在产品名称上做一些突破吧（这是一段不负责任的“臆断”，谨慎参考）。
