抛开业务逻辑的因素,根据不同的版本、不同平台、不同停机时间需求,有不同的可选路径决定迁移方
今天发现有一个备份的mysql数据文件夹异常变大,一查发现是多了三个文件:ibdata1 ib_logfile0 ib_logfile1,前者18m,后两个各5m,原来是迁移的时候从mysql5.0迁移到了5.5,而5.5关闭innodb启动不起来,于是我就开启了innodb,由于innodb会默认增加这几个数据文件和日志文件,导致变大。尝试设置数据文件的大小,结果告诉我最小10m,还是太大,于是探索关闭innodb的方法。 看日志发现说由于mysql程序升级了,需要运行mysql_upgrade升级一下mysql里面的数据库,这个比较简单,和mysql命令用法是一样的,运行一遍就ok了。然后发现还是无法关闭innodb,很奇怪,查了下发现原来mysql5.5默认使用innodb了,所以无法简单的关闭掉,还要设置一下默认使用的引擎为myisam才可以,在my.cnf里加上如下两句: 复制代码 代码如下: default-storage-engine=MYISAM innodb=OFF 重启mysql,然后删掉那三个讨厌的文件即可。 MySQL 5.6 禁用INNODB INNODB是MySQL被ORACLE收购后开发的,支持事务和行级锁等高级功能,但是并不是所有人都需要INNODB的,对大部分人来说,以前的MYISAM引擎就够了,一般会选择将默认引擎改为MYISAM,但是INNODB还是会耗费内存和硬盘,这时候,就需要把INNODB彻底禁用。 在以前的MySQL中,一般可以这么设置就行了: 复制代码 代码如下: default-storage-engine=MYISAM skip-innodb 但是在最新的MySQL5.6里,这么设置是没法启动的,需要再增加一句设置: 复制代码 代码如下: default-tmp-storage-engine=MYISAM 不仅如此,还需要添加以下配置,否则程序会很容易退出的: 复制代码 代码如下: loose-innodb-trx=0 loose-innodb-locks=0 loose-innodb-lock-waits=0 loose-innodb-cmp=0 loose-innodb-cmp-per-index=0 loose-innodb-cmp-per-index-reset=0 loose-innodb-cmp-reset=0 loose-innodb-cmpmem=0 loose-innodb-cmpmem-reset=0 loose-innodb-buffer-page=0 loose-innodb-buffer-page-lru=0 loose-innodb-buffer-pool-stats=0 loose-innodb-metrics=0 loose-innodb-ft-default-stopword=0 loose-innodb-ft-inserted=0 loose-innodb-ft-deleted=0 loose-innodb-ft-being-deleted=0 loose-innodb-ft-config=0 loose-innodb-ft-index-cache=0 loose-innodb-ft-index-table=0 loose-innodb-sys-tables=0 loose-innodb-sys-tablestats=0 loose-innodb-sys-indexes=0 loose-innodb-sys-columns=0 loose-innodb-sys-fields=0 loose-innodb-sys-foreign=0 loose-innodb-sys-foreign-cols=0 摘自http://docs.oracle.com/cd/E17952_01/refman-5.6-en/innodb-turning-off.html 另外MYSQL 5.6 比 5.5占用了更多的物理内存,虚拟内存跟5.5使用差不多(5.5也是一个虚拟内存消耗大户)。性能上比5.5提升了30%左右(根据官方文档,没作具体测试)。
今天发现有一个备份的mysql数据文件夹异常变大,一查发现是多了三个文件:ibdata1 ib_logfile0 ib_logfile1,前者18m,后两个各5m,原来是迁移的时候从mysql5.0迁移到了5.5,而5.5关闭innodb启动不起来,于是我就开启了innodb,由于innodb会默认增加这几个数据文件和日志文件,导致变大。尝试设置数据文件的大小,结果告诉我最小10m,还是太大,于是探索关闭innodb的方法。 看日志发现说由于mysql程序升级了,需要运行mysql_upgrade升级一下
在MySQL中如果要迁移一个表导另外一个服务器/环境中,常规的做法就是使用备份工具备份,比如mysqldump,然后拷贝备份到目标服务器或者环境导入。如果某一个表数据量很大,导出dump文件很大的情况下,使用导出导入工具其实会花费不少的时间. 怎么样提高效率呢,可以有一种想法就是直接拷贝数据文件到目标环境,当然在早期版本中这么做是不可取的,因为会有很多关联数据在ibdata中,InnoDB的数据存在对应的数据字典信息,是存放在共享表空间中,无法直接剥离出来,而在5.6/5.7中,就推出了一个很不错
MySQL 8.0 brings a lot of new features. These features make MySQL database much more secure (like new authentication, secure password policies and management, …) and fault tolerant (new data dictionary), more powerful (new redo log design, less contention, extreme scale out of InnoDB, …), better operation management (SQL Roles, instant add columns), many (but really many!) replication enhancements and native group replication… and finally many cool stuff like the new Document Store, the new MySQL Shell and MySQL InnoDB Cluster that you should already know if you follow this blog (see these TOP 10 for features for developers and this TOP 10 for DBAs & OPS).
MySQL-大批量数据如何快速的数据迁移 背景:最近接触到一个诊所的项目,主要做二次开发,由于甲方没法提供测试数据库(只有生产环境),且二次开发还是基于之前的数据库结构,给了数据库文档和生产库数据地址。由于生产库数据量比较大,我们也没法直接在生产库下二次开发(胆小),我们打算从生产库环境下迁移需要用到表导入自己的开发环境下,迁移的是表结构和表中数据,大概一个表在400M左右(300万条数据),全是InnoDB的存储引擎,而且都带有索引结构。针对如上的迁移数据的需求,我们尝试过直接通过从生产库下导出SQL文件
MariaDB 10.4 是其当前的开发分支。 5 月 21 日, 10.4.5 的 RC release 版本发布,距离正式版本发布越来越近。 10.4 的新特性也越来越值得关注。本文总结 mariadb 官方发布一些的博客内容。对应详细信息,可以细读 MariaDB 10.4 的 changelog :https://mariadb.com/kb/en/library/mariadb-1040-changelog/
松哥原创的四套视频教程已经全部杀青,感兴趣的小伙伴戳这里-->Spring Boot+Vue+微人事视频教程
共享表空间,又称系统表空间,在数据目录中,存储多张表的索引和数据文件,以ibdata1,2,3的形式,可以跨多个数据库使用
本系列文章基于5.7.20 版本讲述MySQL的新特性。从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍5.7 的新特性和功能。同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化。前面写了一篇文章介绍 innodb 的特性,囿于相关知识点比较多 ,本文继续介绍5.7版本的innodb 新特性。
mysqldump 是 Mysql 自带的逻辑备份工具。其备份原理是通过协议连接到 Mysql 数据库,将需要备份的数据查询出来转换成对应的 insert 语句。当需要还原这些数据时,只要执行这些 insert 语句,即可将对应的数据还原。
大部分数据库都有存储数据文件扩展的功能,ORACLE 可以扩展你的表空间,SQL SERVER 可以多建立几个 FILEGROUP, PostgreSQL 也可以建立相关类似的扩展。这些都是对付当前存储空间不足,将数据文件跨物理位置进行存储。
近一个月处理历史数据问题时,居然连续遇到了2个MySQL BUG,分享给大家一下,也欢迎指正是否有问题。
墨墨导读:数据是以表空间来维护和存放的。在表空间中包含数据,结构,索引等信息,如何有效使用表空间对于MySQL来说非常重要。
MySQL Shell是目前MySQL最新的命令行客户端,它是一款全新的工具,支持使用下面的这些功能:
本文主要介绍中小型互联网企业,从本地机房迁移数据库到腾讯云的实践方法。其中包含了详细数据库迁移的方法和步骤,并且增加了实践演练和验证。实践与验证部分内容以常见的 Discuz! 论坛迁移上云做为案例。
计费组是为网易互娱产品提供统一登录和支付高效解决方案的公共支持部门,对内是互娱的各个游戏工作室,对外是国内外数百个渠道。由于业务场景的特殊性,我们为各个游戏产品部署了不同的应用服务,其中大产品环境独立,小产品集中部署。
事件起因:在测试一个数据迁移工具时,源端oracle19c数据迁移到目标端MySQL8.0,提示迁移目标端 Unknown database 'SBTEST',报错如下:
之前有写过mysql升级的文章的, 比如: mysql5.5.x升级到8.0.x 在win环境 mysql5.7升级到8.0报错MY-013140 contains an invalid utf8mb3 character 甚至还有mariadb迁移到Mysql的. 尽是些花里胡哨的....
Facebook 称,他们最近的一次大版本升级到 MySQL 5.6 花了一年多时间才完成,还在 5.6 版上开发 LSM 树存储引擎,MyRocks。在升级到 5.7 的同时构建一个新的存储引擎,会大大减慢 MyRocks 的进度,因此我们选择继续使用 5.6,直到 MyRocks 完成,MySQL 5.6 的寿命也即将结束,决定升级到 MySQL 8.0 。
此时查看 node1、node2 的数据库日志,可以看到双方角色的变换,node1 作为 DONOR 通过 SST 将数据全量同步给了 node2,之后 node2 成功加入集群。
点击关注公众号,Java干货及时送达 近日,Facebook 官博公布了他们的数据库版本从 MySQL 5.6 升级到了 MySQL 8.0,并且在官博记录了复盘详细的升级过程。 Facebook 称,他们最近的一次大版本升级到 MySQL 5.6 花了一年多时间才完成,还在 5.6 版上开发 LSM 树存储引擎,MyRocks。在升级到 5.7 的同时构建一个新的存储引擎,会大大减慢 MyRocks 的进度,因此我们选择继续使用 5.6,直到 MyRocks 完成,MySQL 5.6 的寿命也即将结束,
http://www.infoq.com/cn/articles/mariadb-vs-mysql
在国内不论是使用阿里云、腾讯云还是华为云的云平台版本的 MySQL 数据库,在遇到数据备份恢复的场景,都会遇到需要使用 Percona XtraBackup 工具进行备份还原的需求。
Facebook 使用了大量的MySQL以支持他们最重要的工作。并且他们积极开发了许多MySQL 中的新功能,以支持不断发展的需求。这些更改特性发生在 MySQL 的不同领域,包括客户端连接器、存储引擎、优化器和复制。当Facebook对MySQL 的每个新主要版本进行升级时,会面临许多挑战,包括:
对从事互联网 IT 技术岗位的来说,数据库也是我们日常必备的技能之一,而 MySQL 数据库更是常见、常用的数据库之一。
使用MySQL的有Facebook、Github、YouTube、Twitter、PayPal、诺基亚、Spotify、Netflix等。
最近有一个需求关于数据的清理的需求,但是这个需求里面有一个部分有一个部分是特殊,也就是在数据清理中,是需要进行数据的导出和导入的,并确定在导入和导出的过程中,导出数据在导出到清理的整个过程中中不能被改变,不能进行commited这些数据需要具有独占性 。
同事在客户现场利用DTS工具,从A实例将数据迁移到B实例过程中,发现几乎稍大点的表在迁移完成后,目标端表空间大小差不多都是源端的3倍,也就是说表空间膨胀了2倍。
问题现象:tdsql-xxxxxx 库plidb表letterperson字段PrintState被大量置为了‘0’
上节说到主从复制的一些问题 我们再来回忆一下 主从复制,增加了一个数据库副本,从数据库和主数据库的数据最终会是一致的 之所以说是最终一致,因为mysql复制是异步的,正常情况下主从复制数据之间会有一个微小的延迟 通过这个数据库副本看似解决了数据库单点问题,但并不完美 因为这种架构下,如果主服务器宕机,需要手动切换从服务器,业务中断不能忍受,不能满足应用高可用的要求
下午的时候接到业务部门的一个需求,他们有一个业务对性能要求比较高,在测试环境已经做了一些测试和优化,想看看在MySQL新版本中是否有一定的提升,现在使用的数据库版本是MySQL 5.5.19,想问问我能不能做下升级。
我们通常会遇到这样的一个场景,就是需要将一个数据库的数据迁移到一个性能更加强悍的数据库服务器上。这个时候需要我们做的就是快速迁移数据库的数据。
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
统计信息的作用 上周同事在客户现场遇到了由于统计信息的原因,导致应用数据迁移时间过慢,整个迁移差点失败。关键时刻同事发现测试环境与生产环境SQL语句执行计划不一致,立刻收集统计信息才保证迁移得以正常完成。 统计信息对于SQL的执行时间有重要的影响,统计信息的不准确会导致SQL的执行计划不准确,从而致使SQL执行时间变慢,Oracle DBA非常了解统计信息的收集规则,同样在MySQL中也有相关的参数去控制统计信息。 相关参数 innodb_stats_auto_recalc 控制innodb是否自动收集统
INODB和MyISAM有区别;(engine=innodb和engine=myisam)
前导: Mysql数据是存储到硬盘上的,这里有两张用不同存储引擎存储的表有兴趣的朋友可以先打开自己的mysql硬盘库,查看一下存储的表数据结构 📷 📷 通过观察上图,我们发现 一 . Myisam
对于千万级的表数据存储,删除大量记录后,表文件大小并没有随之变小。好奇怪,是什么原因导致的?不要着急,接下来,我们来深入剖析其中原因
Mysql最常用的三种备份工具分别是mysqldump、Xtrabackup(innobackupex工具)、lvm-snapshot快照。 前面分别介绍了: Mysql备份系列(1)--备份方案总结性梳理 Mysql备份系列(2)--mysqldump备份(全量+增量)方案操作记录 Mysql备份系列(3)--innobackupex备份mysql大数据(全量+增量)操作记录 lvm-snapshot:基于LVM快照的备份 1.关于快照: 1)事务日志跟数据文件必须在同一个卷上; 2)刚刚创立的快照卷,里
今天在看<<MySQL技术内幕>>这本书时 ,看到大师paul Dubois对于Falcon存储引擎的介绍,这是一种用来进行事务处理的存储引擎。在设计时增加了一些自我优化和免维护的功能,描述总体感觉和InnoDB很相似,不过整本书中讲解存储引擎的篇幅基本还是MyISAM和InnoDB为主。 所以对Falcon产生了好奇,网络中对于Falcon的大体描述如下。 Falcon存储引擎是MySQL当时寄以厚望的存储引擎,主要是为了面对当时Oracle收购了InnoBase公司的情况,用来取代InnoDB的一个存储
本文将对MySQL官方版本以及最流行的两个分支:MariaDB 和 Percona Server进行对比介绍。笔者曾经遇到过一些同学,在可能在一个公司待了可能几年了,问他公司用的数据库是什么,他只能回答出,使用的是Mysql。当问到只是用的官方版本,或是哪一个分支时,他就一无所知了。本文将介绍这些分支产生的原因,以及在实际生产中,应该如何进行选择。并不会进行过多细节介绍,算是一个小科普。
https://keithlan.github.io/2017/06/05/innodb_locks_1/
身处数据驱动快速变革的时代,数据库系统的选型和架构设计对于整个IT基础架构,甚至企业的发展都起到至关重要的作用。那么今天,如果您的企业需要搭建一套新的应用系统,你会选择什么数据库类型?如果当前的系统不
本文是MySQL创始人Monty在5月30日"腾讯云CDB/CynosDB技术揭秘"系列直播中的分享实录。 ---- 大家好,我是MariaDB的 Michael Widenius,我们今天来简单的聊下MariaDB10.5新特性和即将要做的事情。10.5已经是RC了,应该是下周四GA,所以非常近了。 Monty全程分享视频 从我个人加到MariaDB的特性开始,这也是我现在依然写代码的地方,差不多我花了我至少一半的时间在做这里。实际上在COVID-19期间,我花了90%的时间在做这里,这还是很好的。
本节列出了第一次添加,已弃用或已在MySQL 5.7中删除的服务器变量,状态变量和选项。
领取专属 10元无门槛券
手把手带您无忧上云