前段时间,在优雅的使用pt-archiver进行数据归档一文中介绍了pt-archiver的使用方法,也将pt-archiver部署到了生产环境,这时候问题来了~
生产环境需要做归档的任务有十几个,如果要知道每个归档任务成功与否、跑了多长时间、归档了多少数据,就得手工逐个查看日志,非常枯燥的重复劳动,那是否有办法可以统一管理呢?
一,引言 前段时间在优雅的使用pt-archiver进行数据归档一文中介绍了pt-archiver的使用方法,也将pt-archiver部署到了生产环境,这时候问题来了…… 生产环境需要做归档的任务有十余个,如果要知道每个归档任务成功还是失败、跑了多长时间、归档了多少数据,就得手工逐个日志查一查,非常枯燥的重复劳动,是否有办法可以统一管理呢?于是用python折腾了一个小工具…… 二,mysql_archiver 2.1 归档调度 db_archive_exec.py,从数据库获取归档任务的基本信息
MySQL数据库归档历史数据主要可以分为三种方式:一.创建编写SP、设置Event;二.通过dump导入导出;三.通过pt-archiver工具进行归档。第一种方式往往受限于同实例要求,往往被大家舍弃。第二种,性能相对较好,但是归档表较多时运维也是比较头疼的事。所以很多DBA往往采用第三种方式--pt-archiver。
特分享出来最近在整理 MySQL 热备工具的实验题目时遇到的 REDO 日志归档问题!
相信很多小伙伴们,在日常对接开发时,有很多大表在业务上并没有采取任何形式的切分,数据不停地往一张表里灌入,迟早有一天,磁盘空间报警。作为一个DBA,侧重点是对数据库的操作性能(大表增加字段/索引,QPS等)和存储容量加以考虑,我们会建议开发对数据库里的大表进行数据归档处理,例如将3个月内的订单表保留在当前表,历史数据切分后保存在归档表中,之后归档表从主库上移走以便腾出磁盘空间,并将其迁移至备份机中(有条件的可以将其转换为TokuDB引擎),以便提供大数据部门抽取至HDFS上。
在不久前有位客户在进行数据迁移时发现。自己使用pt-archiver备份时总是会少一条数据;如源数据库中某表数据为2333,导入目的数据库后select结果只有2332。
MySQL是目前最受欢迎和广泛使用的关系型数据库之一。在企业中,经常会遇到MySQL实例磁盘告警的情况,这对于保持数据库的稳定性和可用性非常重要。本文将详细介绍一次MySQL DB实例磁盘告警的处理过程,以及相关的操作和注意事项。
云数据库 MySQL(TencentDB for MySQL)是腾讯云基于开源数据库 MySQL 专业打造的高性能分布式数据存储服务,让用户能够在云中更轻松地设置、操作和扩展关系数据库。同时云数据库MySQL集成了数据库的备份功能,可以针对数据库实现数据库的自动数据备份、手动数据备份以及日志备份。
DBA经常会遇到需定期对数据进行归档和清除,可利percona的pt-archiver工具能完成这一功能,使得数据归档变得方便简单。pt-archiver可以很轻松的将生产环境的历史数据归档到文件或者直接删除,还可以不同主机间同步数据,而不用将数据落盘,实现的功能有点类似Oracle的数据泵和dblink;pt-archiver一款非常好用的数据归档及清理历史数据的工具,工作中可以起到事半功倍的效果;
业务不断地在增长,集群分片中的数据也会随着时间的推移而增加,其中有相当一部分的数据是很少被使用的,例如几年前的订单记录、交易记录、商品评论等数据。这部分数据就称之为冷数据,与之相反经常被使用的数据则称之为热数据。
最近由于业务需求,需要将公有云RDS(业务库)的大表数据归档至私有云MySQL(历史库),以缩减公有云RDS的体积和成本。
到数据归档,很多人的第一个概念就是,不就是无用的数据,换个地方放吗,直接拷贝,删除不就得了,有那么麻烦。
我们有需要将物理盘上的mysql迁移到ssd上,先说一下生产环境一直有数据产生,且数据量达到500G。 方案一:使用mysqldump,不管是导入导出都太耗时,没有一天拿不下 方案二:直接物理磁盘上拷贝也是非常耗时,拷贝过程中需要停服务,这就导致停服务时间太长。 方案三:这个方案本来是很有优势的,但是实际情况导出导入也需要锁表或锁库,也是需要停服务,本来我们就不需要增量拷贝,innobackupex优势体现在增量拷贝。 方案四:拷贝速度快 综合停服务时间以及操作难易度,最终选择了方案四。 下面描述下操作步骤
据小道消息,MYSQL 将不在8个开头混了,要转变为 9 这个开头了,那么目前最新的8.030 这个版本的MYSQL 在两个部分的变化较大,并且这两个地方的变化预示这什么,MYSQL将往哪个地方继续变化,这是一个需要研究和理解的地方。
MySQL 中删除大表之前可以使用 pt-archiver 批量删除所有记录。这样助于避免在某些情况下您的服务器可能会意外的情况,比如磁盘 IO 满导致数据库hang或者影响正常 SQL 慢查。
-多年互联网运维工作经验,曾负责过大规模集群架构自动化运维管理工作。 -擅长Web集群架构与自动化运维,曾负责国内某大型金融公司运维工作。 -devops项目经理兼DBA。 -开发过一套自动化运维平台(功能如下): 1)整合了各个公有云API,自主创建云主机。 2)ELK自动化收集日志功能。 3)Saltstack自动化运维统一配置管理工具。 4)Git、Jenkins自动化代码上线及自动化测试平台。 5)堡垒机,连接Linux、Windows平台及日志审计。 6)SQL执行及审批流程。 7)慢查询日志分析web界面。
Plus (读音:[plʌs],全称:ThinkSNS+ [θɪŋk es en es plʌs],是 ThinkSNS 系列产品一个重要版本,其软件识别名称为 Plus 即 +) 是一个基于 Latest Laravel 框架进行开发的一个功能强大、易于开发和强拓展的社交系统。与其他开源社交程序不同的是 Plus 拥有多年社交系统经验,不仅易于上手,还便于应用拓展。另一方面,程序采用 PHP 7 严格模式,从根本上尽量避免弱级错误的产生。同时因为从零开始选择较好的带有较好 ORM 的原因,Plus 允许你更具你的需求使用不同数据库。
TiDB 6.0 正式提供了数据放置框架(Placement Rules in SQL )功能,用户通过 SQL 配置数据在 TiKV 集群中的放置位置,可以对数据进行直接的管理,满足不同的业务场景需要。如:
今天给大家介绍一个非常好用的工具集--percona-toolkit,该工具集可以说是mysql dba的得力助手。
我们知道,在MySQL中,redo log是一个文件组,一般是3个文件,循环写入,写满的时候会做redo log层面的checkpoint,然后覆盖之前的redo log;而binlog是有归档功能的,每个binlog写满之后,都会重新开启下一个binlog开始写入,这也是为什么可以使用binlog来进行数据恢复的一个原因,就是因为它的归档功能。
在工单详情可快速提交相同SQL内容到其他实例,可适用于test>beta>ga等多套环境维护的需求
一般现在对于业务要查询的数据量以及要保持的并发量高于一定配置的单实例 MySQL 的极限的情况,都会采取分库分表的方案解决。当然,现在也有很多 new SQL 的分布式数据库的解决方案,如果你用的是 MySQL,那么你可以考虑 TiDB(实现了 MySQL 协议,兼容 MySQL 客户端以及 SQL 语句)。如果你用的是的 PgSQL,那么你可以考虑使用 YugaByteDB(实现了 PgSQL 协议,兼容 PgSQL 客户端以及 SQL 语句),他们目前都有自己的云部署解决方案,你可以试试:
如果将应用的所有数据简单地放在一台 MySQL 服务器实例上,就不用谈什么扩展性了。但是业务能稳定持续的增长,那么应用肯定会碰到性能瓶颈。
数栈是云原生—站式数据中台PaaS,我们在github和gitee上有一个有趣的开源项目:FlinkX,FlinkX是一个基于Flink的批流统一的数据同步工具,既可以采集静态的数据,也可以采集实时变化的数据,是全域、异构、批流一体的数据同步引擎。大家喜欢的话请给我们点个star!star!star!
随着互联网技术的不断发展, MySQL 相关生态也越来越完善,越来越多的工具涌现出来。一些公司或个人纷纷开源出一些不错的工具,本篇文章主要介绍几款 MySQL 相关实用工具。提醒下,这里并不介绍 Navicat 等这类图形化操作工具哦。
MySQL数据库是轻量级、开源数据库的佼佼者,其功能和管理,健壮性与Oracle相比还是有相当的差距。因此有很多功能强大第三方的衍生产品,如percona-toolkit,XtraBackup等等。percona-toolkit是一组高级命令行工具的集合,可以查看当前服务的摘要信息,磁盘检测,分析慢查询日志,查找重复索引,实现表同步等等。这个工具套件对DBA及运维人员着实不可多得。本文简要描述这个工具的安装及其工具的大致介绍。
前些天处理了一个需求,当时的数据库环境是Oracle,我算是想尽了Oracle相关的方案,而且在问题的处理过程中,还在不断的琢磨,如果失败了还有什么其他的方案。 所以尽管Oracle这么一个成熟的商业数据库,做起来还是有些难度,需要一些额外的技巧,比如规避bug,间接实现需求等。 但是换个角度,2亿多数据的表,其实MySQL也不是新鲜事儿了。如果MySQL碰到了这种情况,该怎么处理呢。 梳理业务需求 假设业务需求还是不变,如下: 业务同学反馈,数据库中有一个表数据量很大,因
”工欲善其事,必先利其器“。数据备份是DBA的日常工作,也是保证数据安全的重要工作,要尽善尽美的完成这项工作,必须要使用一款高效可靠的备份工具。MySQL在其企业版里提供了一款备份工具——MySQL Enterprise Backup,简称MEB。
改造总是要付出很多代价的,肯定会跌很多坑,这是必然的... 性能问题也总会呈现先下降后再上升的一个历程(调试、磨合、找到针对性、适应性解决方案)。
在此博客中,我将演示如何在许多mysql实例之间将审计日志进行合并归档。在后续文章中,我将展示如何通过在该归档文件上创建一个简单的哈希链来扩展此示例–这样您就可以证明是否可以通过任何方式对其进行了修改或污染,以及在何处进行了修改。
在以MySQL为主要存储组件的业务系统中,MySQL的性能直接影响到应用的响应速度、用户体验和系统的可扩展性。因此,优化数据库的性能,特别是SQL查询的执行效率,成为了提升整个应用性能的关键环节。
目前,在很多OLTP场景中,MySQL数据库都有着广泛的应用,也有很多不同的使用方式。从数据库的业务需求、架构设计、运营维护、再到扩容迁移,不同的MySQL架构有不同的特点,适应一定的业务场景,或者解决一定的业务问题。
所以说,当公司业务有跨库分析时(一般情况是,业务数据库分布在各个部门),一些数据需要配合其他部门的数据进行关联查询,这个时候可以考虑Presto。但是目前,对于MySQL统计查询在性能上有瓶颈。可考虑将数据按时间段归档到HDFS中,以提高统计效率。
在以往的一些面试过程中,我发现了一些有趣的回答,它们很容易被为归类为“错误答案”。但有时,这些答案却发人深省或包含深刻的含义。本文涉及一些常见的 MySQL 问答,这些问答可能看起来“错误”或“有趣”,但实际上还有更多内容。我将分享一些看似“错误”或异想天开的答案,并仔细研究它们提供的宝贵经验和观点。
开始和数据库玩耍以后,我们将一直与SQL和数据打交道。在日常的操作中,我们只需要对指定的数据库进行操作,执行增删改查,权限管理等。但有些时候由于项目的升级,或者服务器的更换,我们要将数据从一个地方转移到另一个地方,准确的说是从一个数据库服务转移到另一个数据库服务中,因为我们还要继续使用这些数据。
It can generate markdown structure documents of MySQL succinctly~
一、测试背景: TokuDB一直被传说有着较高压缩比、较高insert性能、以及在线添加索引和字段速度较快等等优点,对此进行了相关的调研,针对压缩比、写入性能以及DDL速率进行了相关测试;根据相关资料以及测试报告得出相关结论,了解实用场景以及对应优势。 二、测试环境: CPU:Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz * 32 内存:128G 操作系统:CentOS release 6.6 Mysql版本:5.6 Mysql版本:5.5 Tokudb版本:7.5.1
很多的时候,在Presto上对数据库跨库查询,例如Mysql数据库。这个时候Presto的做法是从MySQL数据库端拉取最基本的数据,然后再去做进一步的处理,例如统计等聚合操作。
# tar -zxvf percona-toolkit-2.2.17.tar.gz # yum -y install perl perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl-TermReadKey # yum -y install perl-Digest-MD5
查看当前归档日志路径,空间的使用率已经到了100%,于是在rman中,删除30天之前的归档日志文件,
“增删改查”都是查找问题,因为你都得先找到数据才能对数据做操作。那存储系统性能问题,其实就是查找快慢问题。
说明:K8S单机安装可能遇到很多坑,网上目前的大部分教程已经不适用最新版了。踩过坑后与大家分享一下方法
使用起来和不分区是一样的,看起来只有一个数据库,其实有多个分区文件,比如我们要插入一条数据,不需要指定分区,MySQL会自动帮我们处理
Percona Toolkit简称pt工具,是Percona公司开发用于管理MySQL的工具,功能包括检查主从复制的数据一致性、检查重复索引、定位IO占用高的表文件、在线DDL等,DBA熟悉掌握后将极大提高工作效率。
自增主键没有持久化是个比较早的bug,这点从其在官方bug网站的id号也可看出(https://bugs.MySQL.com/bug.php?id=199)。由Peter Zaitsev(现Perco
最近一直在写《手撕MySQL系列》文章,我发现自己的切入点有一些问题,虽尝试深入探究MySQL中的一些关键特性,但对于MySQL的知识掌握不太能够形成较好的体系化的知识网络。我感到在对全局了解不够清晰的时候,去深究一个知识点往往会事倍功半。所以打算通过这篇文章,分析SQL语句从头到尾的执行,串连一下MySQL当中的基础知识点。
领取专属 10元无门槛券
手把手带您无忧上云