MySQL 如何避免克隆失败后再次初始化
本文章讨论了当您没有足够的磁盘空间来存储两个数据集时,使用带有安全选项DATA DIRECTORY 的 CLONE INSTANCE 命令。
作者:Sveta Smirnova,数据库专家。
本文来源:https://www.percona.com/,爱可生开源社区翻译。
本文约 800 字,预计阅读需要 3 分钟。
在我之前关于 CLONE INSTANCE
命令的博客文章《MySQL 克隆插件不是你的备份》中,我提到使用选项 DATA DIRECTORY
有助于避免在克隆操作失败时需要从头开始重新初始化副本和克隆相关设置的情况。
MySQL 克隆插件简化了新副本的配置,但不会简化失败后的服务器恢复,除非您准备从头开始重新安装 MySQL 实例。
但是,当您克隆一个已经有巨大数据集的复制副本时,您可能没有足够的空间容纳两个数据集:一个来自源服务器,另一个来自复制副本上的数据。
由于您决定从另一台服务器克隆复制副本,因此您同意丢失当前数据。DATA DIRECTORY
选项的唯一需要是在出现故障时保持与克隆相关的权限和设置不变。您可以使用以下策略之一安全地执行克隆操作。
从头开始
要执行此操作,请停止当前服务器,删除数据目录,再次初始化它,进行连接,并设置与克隆相关的权限和选项。这样,您将拥有一个带有小数据目录的新实例,因此您可以使用选项 DATA DIRECTORY
,而不用担心超出可用磁盘空间。
保留现有 MySQL 架构
如果不想重新安装实例,可以从中删除用户数据。
- 列出所有带查询的非系统数据库。
SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');
- 将它们逐一移除。您可以使用以下存储过程来执行此操作。
CREATE PROCEDURE p1() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE dbname VARCHAR(64); DECLARE c1 CURSOR FOR SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema', 'test'); DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN c1; drop_loop: LOOP FETCH c1 INTO dbname; IF done THEN LEAVE drop_loop; END IF; SET @temp = CONCAT('DROP DATABASE ', dbname); PREPARE stmt FROM @temp; EXECUTE stmt; END LOOP; CLOSE c1; END
如果您将 InnoDB 数据存储在共享表空间中(InnoDB_file_per_table=0),则文件
ibdata
将不会收缩,并且您将无法以这种方式释放磁盘空间。
克隆实例
手动删除数据释放磁盘空间后,可以使用带有选项 DATA DIRECTORY
的 CLONE INSTANCE
命令。
CLONE INSTANCE FROM ‘clone_user'@'source_host':3306 \ IDENTIFIED BY 'password' DATA DIRECTORY = '/path/to/custom_dir';
如果克隆成功,您需要通过一个额外的步骤来完成它:停止 MySQL 实例,并将数据目录的内容替换为用于克隆操作的目录的内容。之后,启动服务器。
如果克隆操作失败,请删除克隆的数据,修复错误,然后重试。
结论
克隆操作可能会失败,并迫使您通过重新初始化副本上的 MySQL 实例来执行额外的步骤。要避免这种情况,请使用选项 DATA DIRECTORY
。如果磁盘空间不足,无法存储两个数据副本,请在克隆之前清理现有数据。
更多技术文章,请访问:https://opensource.actionsky.com/
关于 SQLE
爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者,支持多场景审核,支持标准化上线流程,原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
SQLE 获取

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
为何在中国 Navicat 远比 DBeaver 流行
Bytebase 面向全球,通常调研我们产品的 DBA 和开发者之前已经在用可视化 SQL 客户端来操作数据库。我们发现一个现象,在国内 Navicat 的占有率要远远高于其他的 SQL 客户端。而在我们接触的国外客户里,Navicat 的存在感又远没有国内那么高,海外最流行的客户端是 DBeaver。 这个差异在 Google Trends 上也一目了然 🔍 本文也尝试探究一下这背后的原因。 公司起源 Navicat 是一家香港公司,起步于 2008 年,看起来一开始就是以公司方式商业化运营的。 DBeaver 起步于 2010 年,长期就一个作者「Daily commits, almost a one man show!」。看时间线,一开始人在俄罗斯,商业化后跑到了美国。 官网对比 Navicat 提供了中文版的官网,而 DBeaver 只有英文版的。Navicat 的官网也确实更贴合国内的设计风格。 产品界面对比 截图是在相同窗口尺寸下,Navicat (左) 和 DBeaver 的主功能界面对比。Navicat 布局相对松散,信息更加清晰一些。而 DBeaver 信息密度非常...
- 下一篇
PolarDB-X 混沌测试实践:如何衡量数据库索引选择能力
引言 随着PolarDB分布式版的不断演进,功能不断完善,新的特性不断增多,整体架构扩大的同时带来了测试链路长,出现问题前难发现,出现问题后难排查等等问题。原有的测试框架已经难以支撑实际场景的复杂模拟测试。因此,我们实现了一个基于业务场景面向优化器索引选择的混沌查询实验室,本文之后简称为CEST(complex environment simulation test)。 CEST能够提供灵活生产各种数据的测试工具,包括有无倾斜,有无全局二级索引,大,小,宽,窄等等类型的表。为日后的扩展的测试框架提供了测试的数据保障。其次,CEST针对目前的优化器进行了评测,从而复现出目前业务场景存在的多种问题,主要包括索引错选和plan cache等问题。最后,CEST能够探测尚未在业务场景发现的设计隐患,从而在问题发生之前就将其消灭。 索引选择 在介绍CEST之前,本文先对PolarDB-X的索引选择策略进行简要的回顾: 以是否选择使用全局二级索引为例介绍索引选择策略。简单的来说,全局二级索引一般是一张有索引键,主键,覆盖索引键的表。由于其按索引键分区,如果索引和查询过滤条件配合得当,那么使用全局二...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS6,CentOS7官方镜像安装Oracle11G
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7设置SWAP分区,小内存服务器的救世主