【MySql】M-M 架构下的 DDL 一则

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:         一个应用的表 auto_inrement 字段为int 类型的,当前已经用了完了!需要重建表结构,又因为生产环境是M-M 架构,为了不影响应用对所操作表的访问,先操作一个备库,执行切换,再操作另一个数据库!注意 使用  set sql_log_...
        一个应用的表 auto_inrement 字段为int 类型的,当前已经用了完了!需要重建表结构,又因为生产环境是M-M 架构,为了不影响应用对所操作表的访问,先操作一个备库,执行切换,再操作另一个数据库!
注意 使用  set sql_log_bin=0; 防止对另外的master的影响!
大致的步骤如下:
1 连接备库 
  use monitor;
  set sql_log_bin=0;
2 创建临时表
 CREATE TABLE `rrd_value_tmp` (
  `value_id` bigint(20) unsigned  NOT NULL AUTO_INCREMENT,
  `state_id` int(11) NOT NULL,
  `row_no` int(11) NOT NULL,
  `value` double DEFAULT NULL,
  PRIMARY KEY (`value_id`),
  KEY `rrd_val_state_row_ind` (`state_id`,`row_no`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
3 插入数据
insert into rrd_value_tmp(state_id,row_no,value) select state_id,row_no,value from rrd_value; 
4 重命名表
rename table rrd_value to rrd_value_bak;
rename table rrd_value_tmp to rrd_value;
5 切换
#sh aurora.sh status 10.249.238.69
#sh aurora.sh takeover 10.249.238.69
#sh aurora.sh status 10.249.238.69
确定是否已经成功切换到备库 
对新的备库进行操作
1 连接备库 
  use monitor;
  set sql_log_bin=0;
2 创建临时表
 CREATE TABLE `rrd_value_tmp` (
  `value_id` bigint(20) unsigned  NOT NULL AUTO_INCREMENT,
  `state_id` int(11) NOT NULL,
  `row_no` int(11) NOT NULL,
  `value` double DEFAULT NULL,
  PRIMARY KEY (`value_id`),
  KEY `rrd_val_state_row_ind` (`state_id`,`row_no`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

2 插入数据
insert into rrd_value_tmp(state_id,row_no,value) select state_id,row_no,value from rrd_value; 
 
3 重命名表
rename table rrd_value to rrd_value_bak;
rename table rrd_value_tmp to rrd_value;
操作完成,开发验证应用重新可用,所以要将旧表删除,因为涉及的表比较大,采用了 《如何更快的删除大表》这篇文章
实现原理:巧用LINK(硬链接),就是利用OS HARD LINK的原理,当多个文件名同时指向同一个INODE时,这个INODE的引用数N>1, 删除其中任何一个文件名都会很快.
因为其直接的物理文件块没有被删除.只是删除了一个指针而已;当INODE的引用数N=1时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时;
查看表的大小以及状态
mysql> select (data_length+index_length)/1024/1024/1024  from information_schema.tables where table_name='rrd_value_bak';
+-------------------------------------------+
| (data_length+index_length)/1024/1024/1024 |
+-------------------------------------------+
|                           20.113281250000 |
+-------------------------------------------+
mysql> show table status like 'rrd_value_bak' \G
*************************** 1. row ***************************
           Name: rrd_value_bak
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 324777861
 Avg_row_length: 44
    Data_length: 14360248320
Max_data_length: 0
   Index_length: 7236222976
      Data_free: 5242880
 Auto_increment: 665835601
    Create_time: 2012-04-06 13:16:19
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_general_ci
       Checksum: NULL
 Create_options: 
        Comment: 
1 row in set (0.06 sec)
对此表的数据文件建立物理连接:
root@rac1# ll rrd_value_bak*
-rw-rw---- 1 mysql mysql        8672 Apr  6 13:16 rrd_value_bak.frm
-rw-rw---- 1 mysql mysql         8672 Apr  6 13:16 rrd_value_bak.frm
-rw-rw---- 1 mysql mysql  21906849792 Apr  6 14:53 rrd_value_bak.ibd
root@rac1# ln rrd_value_tmp.ibd rrd_value_bak.ibd.hdlk
建立好之后 node 显示为2!
root@rac1# ll rrd_value_bak*
-rw-rw---- 1 mysql mysql        8672 Apr  6 13:16 rrd_value_bak.frm
-rw-rw---- 2 mysql mysql 21906849792 Apr  6 14:54 rrd_value_bak.ibd
-rw-rw---- 2 mysql mysql 21906849792 Apr  6 14:54 rrd_value_bak.ibd.hdlk
root@rac1# mysql 
mysql> use monitor;
Database changed
mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
mysql> 
mysql> 
mysql> show table status like 'rrd_value_bak' \G
*************************** 1. row ***************************
           Name: rrd_value_bak
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 312084387
 Avg_row_length: 46
    Data_length: 14360248320
Max_data_length: 0
   Index_length: 7236222976
      Data_free: 5242880
 Auto_increment: 665835601
    Create_time: 2012-04-06 13:16:19
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_general_ci
       Checksum: NULL
 Create_options: 
        Comment: 
1 row in set (0.08 sec)
mysql> drop table rrd_value_bak;
Query OK, 0 rows affected (19.46 sec) 耗费了19.46秒
mysql> exit
Bye
table删除了table,数据文件依然存在,还需要将数据文件删除:
root@rac1# ll rrd_value_bak*
-rw-rw---- 1 mysql mysql 21906849792 Apr  6 14:57 rrd_value_bak.ibd.hdlk 
root@rac1# rm rrd_value_bak.ibd.hdlk
rm: remove regular file `rrd_value_tmp.ibd.hdlk'? y
root@rac1#
整个删除操作 并没有想参考文章所提及的那样快!可能和机器的配置有关!
阅读(3603) | 评论(0) | 转发(0) |
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
4月前
|
存储 SQL 监控
数据中台架构解析:湖仓一体的实战设计
在数据量激增的数字化时代,企业面临数据分散、使用效率低等问题。数据中台作为统一管理与应用数据的核心平台,结合湖仓一体架构,打通数据壁垒,实现高效流转与分析。本文详解湖仓一体的设计与落地实践,助力企业构建统一、灵活的数据底座,驱动业务决策与创新。
|
8月前
|
SQL 缓存 分布式计算
vivo 湖仓架构的性能提升之旅
聚焦 vivo 大数据多维分析面临的挑战、StarRocks 落地方案及应用收益。 在 **即席分析** 场景,StarRocks 使用占比达 70%,查询速度提升 3 倍,P50 耗时从 63.77 秒缩短至 22.30 秒,查询成功率接近 98%。 在 **敏捷 BI** 领域,StarRocks 已完成 25% 切换,月均查询成功数超 25 万,P90 查询时长缩短至 5 秒,相比 Presto 提升 75%。 在 **研发工具平台** 方面,StarRocks 支持准实时数据查询,数据可见性缩短至 3 分钟,查询加速使 P95 延迟降至 400 毫秒,开发效率提升 30%。
vivo 湖仓架构的性能提升之旅
|
2月前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
336 0
|
存储 SQL 缓存
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
快手 OLAP 系统为内外多个场景提供数据服务,每天承载近 10 亿的查询请求。原有湖仓分离架构,由离线数据湖和实时数仓组成,面临存储冗余、资源抢占、治理复杂、查询调优难等问题。通过引入 Apache Doris 湖仓一体能力,替换了 Clickhouse ,升级为湖仓一体架构,并结合 Doris 的物化视图改写能力和自动物化服务,实现高性能的数据查询以及灵活的数据治理。
649 3
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
|
7月前
|
SQL 分布式数据库 Apache
网易游戏 x Apache Doris:湖仓一体架构演进之路
网易游戏 Apache Doris 集群超 20 个 ,总节点数百个,已对接内部 200+ 项目,日均查询量超过 1500 万,总存储数据量 PB 级别。
635 3
网易游戏 x Apache Doris:湖仓一体架构演进之路
|
9月前
|
SQL 消息中间件 Kafka
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
本文介绍了阿里云实时数仓Hologres负责人姜伟华在Flink Forward Asia 2024上的分享,涵盖实时数仓的发展历程、从实时数仓到实时湖仓的演进,以及总结。文章通过三代实时数仓架构的演变,详细解析了Lambda架构、Kafka实时数仓分层+OLAP、Hologres实时数仓分层复用等方案,并探讨了未来从实时数仓到实时湖仓的演进方向。最后,结合实际案例和Demo展示了Hologres + Flink + Paimon在实时湖仓中的应用,帮助用户根据业务需求选择合适的方案。
1372 20
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
|
存储 边缘计算 运维
实时数仓Hologres发展问题之实时数仓对Lambda架构的问题如何解决
实时数仓Hologres发展问题之实时数仓对Lambda架构的问题如何解决
157 2
|
9月前
|
SQL 运维 BI
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
浙江霖梓早期基于 Apache Doris 进行整体架构与表结构的重构,并基于湖仓一体和查询加速展开深度探索与实践,打造了 Doris + Paimon 的实时/离线一体化湖仓架构,实现查询提速 30 倍、资源成本节省 67% 等显著成效。
490 3
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
|
8月前
|
SQL 消息中间件 Serverless
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
261 4
|
8月前
|
存储 缓存 Apache
小红书湖仓架构的跃迁之路
小红书研发工程师李鹏霖(丁典)在StarRocks年度峰会上分享了如何通过结合StarRocks和Iceberg实现极速湖仓分析架构。新架构使P90查询性能提升了3倍,查询响应时间稳定在10秒以内,存储空间减少了一半。RedBI自助分析平台支持灵活、快速的即席查询,优化了排序键和Join操作,引入DataCache功能显著提升查询性能。未来将探索近实时湖仓分析架构,进一步优化处理能力。