我在MySQL版本:Ver 14.14 Distrib 5.1.61上创建存储过程是没有问题的,但是在版本:Ver 14.12 Distrib 5.0.26上面创建存储过程的时候就出现了上面的错误。甚至使用show procedure status 查看存储过程都会报上面的错误。
随着MySQL 8.0的推出,系统表已经全面采用InnoDB引擎,不再需要MyISAM引擎。另外,MGR中也不支持MyISAM引擎。
MySQL 8.0.16 开始,MySQL 不推荐使用mysql_upgrade。取而代之的是"server upgrade"的升级方式。
当前不少系统的数据库依旧是MySQL5.6,由于MySQL5.7及MySQL8.0在性能及安全方面有着很大的提升,因此需要升级数据库。本文通过逻辑方式、物理方式原地升级来介绍MySQL5.6 升级至MySQL5.7的方法,并介绍其使用场景。
在/etc/my.conf中修改host为127.0.0.1,无效 重新启动mysql,报错:
The mysql_upgrade client is now deprecated. The actions executed by the upgrade client are now done by the server.
GreatSQL是国产MySQL的一个重要分支,目前主推的是GreatSQL 8.0.25 和 GreatSQL 5.7.36,如果你的生产环境用到了MGR组复制技术,那升级GreatSQL可以提升你的用户体验,因为它在MGR方向做了很多性能改善。
线上有个数据库主从环境的MySQL版本是5.5.19版本的,由于5.5.19环境的MySQL在运维侧的支持不太好,例如:不能动态修改buffer_pool的值,alter table增加列的操作会长时间锁表等等。所以经过商量,需要对它进行升级,这次我采用的是在线升级的办法。我总结了一下在线升级过程中的总体步骤:
前面我们在解决宝塔MySQL无法开启时看到数据库错误日志显示InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name. Please run mysql_upgrade,如何解决呢?随ytkah一起来看看吧
最近在做灾备数据从库, 从库版本使用的是5.7.25, 主库版本是5.7.22. 配置完主从同步后,瞄了一眼从库的错误日志里面,突然蹦出一堆的下面这种:
今天晚上去看服务器,发现数据库的版本是5.7的,看起来挺新的。但是MySQL已经出了8.0了,受不了心中的渴望,所以就直接把源切到8.0新版本了。中国有一些坑,在此记录一下。
报错表明schema的结构有问题 但是尝试登录已经可以正常登录 并且发现已经是新的版本了 [root@upgrade-slave ~]# mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.6.27-75.0-log Percona Server (GPL), Release 75
打开新安装的navicat后,有个test_3306的mysql连接,里面有写默认的mysql、information_schema、sys、performance_schema数据库,我以为这是没用的就删除了,之后建立自己的mysql连接后,打开连接报错1146 – Table ‘historyhistoryperformance_schema.session_status’ doesn’t exist。
比如本人使用的云服务器,其中MySQL预装版本为老版本5.1.x。而最新的mysql版本在性能、功能、安全性等方面都有了很多的改进。 要从最新版本获益,你需要把现有系统升级到5.5+(最新的版本是5.7),我保守一点,升级到5.6.37。
该报错为那张表的那个字段包含了无效字符. 可以使用show create table XX查看发现注释确实有无效字符.
爱可生 DBA 团队成员,负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。
系统环境为CentOS6.5,安装的MySQL版本为5.6.29,现在要将此版本升级为MySQL5.7.29。
错误是由于你曾经升级过数据库,升级完后没有使用mysql_upgrade升级数据结构造成的。
今天翻看MySQL8.0的官方文档的时候,看到了MySQL8.0的几个新特性,简单测了下,跟MySQL5.7做了下对比,测试的结果如下:
APACHE: http://www.fayea.com/apache-mirror/httpd/
第一步:在管理员命令中输入: mysql_upgrade -u root -p --force 第二步:关闭并重启数据库 service mysql stop service mysql start
一、什么是 GTID GTID (Global Transaction Identifiers)是对于一个已提交事务的编号,事务的唯一编号,并且是一个全局唯一的编号。GTID 和事务会记录到 binlog 中,用来标识事务。 GTID 是用来替代以前 classic 复制方法,MySQL-5.6.2 开始支持 GTID,在 MySQL-5.6.10 后完善。 有了 GTID,一个事务在集群中就不再孤单,在每一个节点中,都存在具有相同标识符的兄弟们和它作伴,可以避免同一个事务,在同一个节点中出现多次的情况。 GTID 的出现,最直接的效果就是,每一个事务在集群中具有了唯一性的意义,这在运维方面具有更大的意义,因为使用 GTID 后再也不需要为了不断地找点而烦恼了,给 DBA 带来了很大的便利性。
对于商业数据库而言,数据库升级是一个优先级很高的事情,有版本升级路线图,有相应的补丁,而且对于方案还有一系列的演练,显然是一场硬仗。而在MySQL方向上,升级这件事情就被淡化了许多,好像只能证明它的存在而已,当然正是由于这种不重视,也让我今天走了不少弯路。
之前有写过mysql升级的文章的, 比如: mysql5.5.x升级到8.0.x 在win环境 mysql5.7升级到8.0报错MY-013140 contains an invalid utf8mb3 character 甚至还有mariadb迁移到Mysql的. 尽是些花里胡哨的....
下午的时候接到业务部门的一个需求,他们有一个业务对性能要求比较高,在测试环境已经做了一些测试和优化,想看看在MySQL新版本中是否有一定的提升,现在使用的数据库版本是MySQL 5.5.19,想问问我能不能做下升级。
目前公司部署MySQL是通过平台化操作的,周五的时候,平台暂时出了点儿问题,手上有个需求比较着急,就直接手动的部署了一下,由于好长时间没有部署环境了,竟然有些手生,这里把部署的步骤以及遇到的问题记录下来,希望对大家有所帮助。
再次尝试升级 [root@upgrade-slave ~]# time mysql_upgrade -u root -p Enter password: Looking for 'mysql' as: mysql Looking for 'mysqlcheck' as: mysqlcheck Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/lib/mysql/mysql.sock' Warning
今天发现有一个备份的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%左右(根据官方文档,没作具体测试)。
5.进入 mysql> 环境后,通过修改mysql库中user表的相关记录,重设root用户从本机登录的密码:
今天发现有一个备份的mysql数据文件夹异常变大,一查发现是多了三个文件:ibdata1 ib_logfile0 ib_logfile1,前者18m,后两个各5m,原来是迁移的时候从mysql5.0迁移到了5.5,而5.5关闭innodb启动不起来,于是我就开启了innodb,由于innodb会默认增加这几个数据文件和日志文件,导致变大。尝试设置数据文件的大小,结果告诉我最小10m,还是太大,于是探索关闭innodb的方法。 看日志发现说由于mysql程序升级了,需要运行mysql_upgrade升级一下
新升级的mysql到5.7后,发现默认情况下,如果不做修改会发现MySQL之前的远程登录账号都无法登陆了。
此时多出来一个文件 general_log.CSM [root@upgrade-slave mysql]# ll general_log.* -rw-rw----. 1 mysql mysql 35 Dec 15 00:22 general_log.CSM -rw-rw----. 1 mysql mysql 0 Dec 15 00:18 general_log.CSV -rw-------. 1 mysql mysql 8776 Dec 15 00:22 general_log.frm [root
网上这类教程太多了,此处仅作为一个常用命令的记录,详细教程会在参考资料中给出地址,有兴趣的可以去看一下。
报错 在5.1->5.6升级过程中,执行upgrade之后产生如下报错 [root@upgrade-slave ~]# time mysql_upgrade -u root -p Enter password: Looking for 'mysql' as: mysql Looking for 'mysqlcheck' as: mysqlcheck Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/l
由于之前电脑上安装的MySQL版本是比较老的了,大概是5.1的版本,不支持JSON字段功能。而最新开发部门开发的的编辑器产品,使用到了JSON字段的功能。 因此需要升级MySQL版本,升级的目标版本是MySQL 5.7.30(虽然最新版本已经到8.x,但是5.7基本够用了)。 发现在升级安装过程中,会有一些坑,所以使用本文记录一下。
最近在规划CentOS7版本中的MySQL测试情况,于是找了公司内部的虚拟机来做下模拟测试。
当使用apt-get安装mysql后,ubuntu会自动生成一个用户名和密码。所以在第一次登陆时会报如下错误 ERROR 1045 (28000): Access denied for user 'db'@'localhost' (using password: NO) 而真正的用户名和密码在 /etc/mysql/debian.cnf # Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localh
MYSQL 5.6 --> MySQL 5.7 --> MySQL8.0.x
最近业务反馈,8.0.32在使用union和union all的过程中,发现含有中文等特殊字符时查询返回数据为空。这个影响是比较严重的。
几天写了个小项目,在ecs上装了个mysql5.7,结果程序报语法错误了,检查本机上没有问题,怀疑就是MySQL版本问题了,一查本地mysql版本5.5.27,不是一般的低了。今天就升级一下。mysql我采用原地升级,直接将数据文件进行拷贝。
这是因为你的安装服务器只绑定了能够本地访问,你需要修改配置,让你的服务器能够支持远程访问。
爱可生 MySQL DBA 团队成员,Oracle 10g OCM,MySQL 5.7 OCP,擅长数据库性能问题诊断、事务与锁问题的分析等,负责处理客户 MySQL 及我司自研 DMP 平台日常运维中的问题,对开源数据库相关技术非常感兴趣。
使用sudo apt install mysql-server方法安装的MySQL服务,安装之后没有临时密码的日志,想着直接修改root密码,但是尝试了很多网上的方法,但是都无法生效,包括
Percona 在10月31日 发布对Percona Server 8.0 RC版本。
https://dev.mysql.com/downloads/mysql/5.7.html#downloads
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
mysql安装目录 /usr/local/mysql/ 数据目录/usr/local/mysql/data
按我的习惯总会先跑个demo演示下,本想打开Navicat建个表 ,额~ ,几天没打开这是什么局面?
描述 出现场景:这个问题一般出现在刚刚安装完mysql的时候 出现原因:由于使用命令sudo apt-get install mysql安装时,并没有提示输入密码,则密码没有初始化,使用root用户登录自然失败. 具体情况: :~$ mysql -uroot -p Enter password: ERROR 1698 (28000): Access denied for user 'root'@'localhost' 下面是解决问题的方法。 解决方法 思路:既然密码没有初始化,那么直接使用默认密码登录就可
领取专属 10元无门槛券
手把手带您无忧上云