• 关于

    MySQL删除binlog

    的搜索结果

问题

数据传输服务DTS中源库binlog检查

源库binlog是否开启检查 这个配置项只有当进行MySQL->MySQL增量迁移时,才会进行检查。这个检查项主要检查源数据库是否开启binlog日志。如果检查项失败,那么说明源数据库没有开启binlo...
云栖大讲堂 2019-12-01 21:24:29 1458 浏览量 回答数 0

问题

MySQL Binlog日志的生成和清理规则

Binlog日志的生成规则 MySQL实例空间内生成binlog日志的规则如下: 通常情况下,当前binlog大小超过500MB时会切换到下一序号文件继续写入,即写满500MB就会生成新的bin...
云栖大讲堂 2019-12-01 21:32:16 2396 浏览量 回答数 0

问题

用户指南-MySQL Binlog日志的生成和清理规则

Binlog日志的生成规则 MySQL实例空间内生成binlog日志的规则如下: 通常情况下,当前binlog大小超过500MB时会切换到下一序号文件继续写入,即写满500MB就会生成新的bin...
李沃晟 2019-12-01 21:39:26 729 浏览量 回答数 0

新人多重礼,优惠不断档!

商标注册320起,工商财税299元起,域名首购1元购,资质办理免费咨询

问题

用户指南- 备份与恢复- MySQL设置本地Binlog

背景信息 RDS for MySQL支持您手动设置本地Binlog日志的清理规则,您可以根据需求灵活设置Binlog。在设置Binlog之前请先了解MySQL Binlog日志生成和清理规则。 MySQL实例空间内生成Bi...
李沃晟 2019-12-01 21:39:26 602 浏览量 回答数 0

问题

为 MySQL/MariaDB 开启 Binlog 功能

介绍 说到 Binlog 就不得不提一下 MySQL Server 的四种类型的日志:Error Log、General Query Log、Slow Query Log 和 Binary Log 。 Error L...
妙正灰 2019-12-01 21:43:30 1193 浏览量 回答数 1

问题

MySQL复制:如果我未指定任何数据库,log_bin是否会记录所有内容?

我正在为运行一堆数据库(每个客户端一个)的服务器设置复制,并计划一直在my.cnf上添加更多数据库,而不是: binlog-do-db = databasena...
保持可爱mmm 2019-12-01 21:58:00 2 浏览量 回答数 1

回答

增量备份的原理就是使用了mysql的binlog日志。本次操作的MySQL版本为5.5.40 for Linux (x86_64)。增量备份要确保打开了二进制日志,参考mysql的日志系统:mysql> show variables like '%log_bin%';首先对pak数据库做一个完整备份:$ mysqldump -h localhost -upak -ppwd -P3306 --master-data=2 --single-transaction --opt pak > pak_bak_full.sql这时候就会得到一个全备文件pak_bak_full.sql。mysqldump操作会导致滚动一次log,假设新的binlog文件是mysql-bin.000002。模拟插入数据和误操作 在pak库的某个表插入一些数据,然后执行flush logs命令。这时将会产生一个新的二进制日志文件mysql-bin.000003,mysql-bin.000002则保存了全备过后的所有更改,既增加记录的操作也保存在了mysql-bin.00002中。 再在pak库中的t_user表中增加两条记录,然后误删除t_user表。t_user中增加记录的操作和删除表的操作都记录在mysql-bin.000003中。 开始恢复 恢复过程不要记录日志: 首先导入全备数据 我们也可以看到全备时的binlog位置:查看当前所在二进制日志中的位置:根据上面两个position能大概确定需要完整恢复哪几个binlog文件。恢复mysql-bin.000002在待恢复的position或时间点以前、全备以后的binlog需要全部恢复,多个文件以空格隔开此时查询可以得到前两条数据。 恢复部分mysql-bin.000003这个日志中包括了新增记录和误删表两个部分,我们需要恢复到新增记录之后、误删操作以前的位置。如果知道误操作的命令如DROP TABLE,则可以通过下面的方法在binlog文件中找到误操作之前的那个position:(如下面的信息显示,误操作DROP TABLE之前的pos是775,在datetime 141204 15:08:04或pos 882时完成DROP TABLE操作)恢复命令:如果position难以确定,但知道需要恢复到的确切(服务器)时间,也可以使用datetime:如果不是误操作导致的,而是迁移数据库,那么不需要position或datetime,使用所有binlog文件增量恢复即可。 确定恢复成功后记得打开日志记录:报错 unknown variable 'default-character-set=utf8'在使用mysqlbinlog查看二进制日志的时候,提示下面的错误: 原因是在我为了统一mysql客户端到服务端的的字符编码,在/etc/my.cnf文件的[client]、[mysqld]等节加入了default-character-set = utf8,mysqlbinlog会从my.cnf中的[client]读取配置,但奈何mysqlbinlog并不认识这个选项(据说是个bug)导致的。应对这个bug的方法有两个:第一,自然是注释到[client]中的这个字符集配置;第二,改用loose-default-character-set = utf8。在选项前加了loose-,表示当程序不认识此选项时会略过此选项,并给出一个警告。
蛮大人123 2019-12-02 01:44:20 0 浏览量 回答数 0

回答

binlog是mysql用来构建复制时候用的文件。目测楼主没有从库,所以可以把binlog给关掉。方法就是在配置文件中注释掉log-bin。在关闭前,可以下使用reset master把现有的binlog都删除掉
韩逸 2019-12-01 23:35:23 0 浏览量 回答数 0

回答

现象:网站访问越来越慢,最后无法访问了,经过检查发现磁盘满了。仔细查询下来确认是由于mysql的binlog太多太大占用了空间。 分析过程及解决方案:通常出现这种问题都应该登录服务器检查磁盘、内存和进程使用的情况,通过top、df –h和free –m来检查,发现磁盘空间满了。再进一步通过du –sh对可以的目录进行检查,发现是mysql的binlog占用空间过大。清理binlog的方法如下: 1) 设置日志保留时长expire_logs_days自动删除 查看当前日志保存天数: show variables like '%expire_logs_days%'; 这个默认是0,也就是logs不过期,可通过设置全局的参数,使他临时生效: set global expire_logs_days=7; 设置了只保留7天BINLOG, 下次重启mysql这个参数默认会失败,所以需在my.cnf中设置 expire_logs_days = 7 2) 手动删除BINLOG (purge binary logs) 用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件 PURGE {MASTER | BINARY} LOGS TO 'log_name' PURGE {MASTER | BINARY} LOGS BEFORE 'date' 例如: PURGE MASTER LOGS TO 'mysql-bin.010'; PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);
KB小秘书 2019-12-02 02:07:29 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:14 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:13 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:13 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:14 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:13 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:13 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:14 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:13 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:14 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:14 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:14 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 您可以通过设置备份策略调整 RDS 数据备份和日志备份的周期来实现自动备份,也可以通过手动备份 RDS 数据。 实例备份文件占用备份空间,空间使用量超出免费的额度将会产生额外的费用,请合理设计备份周期,以满足业务需求的同时,兼顾备份空间的合理利用。关于免费额度详情,请参见查看备份空间免费额度。关于备份空间使用量的计费标准,请参见云数据库 RDS 详细价格信息。 备份策略 阿里云数据库支持数据备份和日志备份。如要按照时间点恢复数据,需启用日志备份。各类型数据库备份策略如下: 数据库类型 数据备份 日志备份 MySQL MySQL 5.5/5.6/5.7 本地SSD盘(含高可用版和金融版): 自动备份支持全量物理备份。 手动备份支持全量物理备份、全量逻辑备份和单库逻辑备份。 MySQL 5.7 SSD云盘(基础版): 仅支持快照备份,且不支持逻辑备份。 备份文件免费保存,最多7天。 MySQL 5.7 SSD云盘(高可用版): 仅支持快照备份,且不支持逻辑备份。 Binlog (500MB/个)产生完后立即压缩上传,24 小时内删除本地文件。 Binlog 文件会占用实例的磁盘容量。 用户可以通过一键上传 Binlog将 Binlog 文件上传至 OSS,不影响实例的数据恢复功能,Binlog 也不再占用实例磁盘空间。 SQL Server 支持全量物理备份和增量物理备份。 自动备份以全量备份-增量备份-增量备份为周期循环。 如:星期一为全量备份,则星期二和星期三为增量备份,星期四为全量备份,星期五和星期六为增量备份,依次循环。 如果备份周期循环期间执行过手动全量备份,则后续两次将自动执行增量备份。 每次备份时SQL Server会收缩事务日志。 用户可以在目标实例管理控制台上的备份恢复页面,单击收缩事物日志,手动收缩事物日志。 包含在数据备份内,不单独提供事物日志下载。 PostgreSQL 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 PPAS 支持全量物理备份 WAL(16MB/个)产生完后立即压缩上传,24小时内删除本地文件。 自动备份(设置备份策略) 阿里云数据库会执行用户设定的备份策略,自动备份数据库。 说明 本例以MySQL 5.7 本地SSD盘(高可用版)为例。 登录 RDS 管理控制台。 单击目标实例的ID,进入基本信息页面。 在菜单中选择 备份恢复。 在 备份恢复页面中选择 备份设置,单击 编辑。 在 备份设置页面设置备份规格,单击 确定。参数说明如下: 参数 说明 数据备份保留 默认为7天,可以设置 7~730 天 MySQL 5.7 SSD云盘(基础版),备份文件免费保存,最多7天。 备份周期 可以设置为一星期中的某一天或者某几天 SQL Server、PostgreSQL、PPAS 实例默认每天都进行备份,不可修改。 备份时间 可以设置为任意时段,以小时为单位。 日志备份保留 日志备份文件保留的天数,默认为 7 天。 可以设置 7~730 天,且必须小于等于数据备份天数。 手动备份 说明 本例以MySQL 5.7 本地SSD盘(高可用版)单库逻辑备份为例。 登录 RDS 管理控制台。 选择目标实例所在地域。 单击目标实例的 ID,进入基本信息页面。 单击页面右上角的备份实例,打开备份实例对话框。 说明 备份方式、备份策略:各引擎支持的备份策略不同,请参见备份策略。 单库备份时,选择左侧的数据库,单击>将要备份的数据库加入列表。若您还没有数据库,请先创建数据库。 设置好备份方式、备份策略,单击确定。
2019-12-01 22:57:13 0 浏览量 回答数 0

问题

技术运维问题 - MYSQL使用 -RDS for MySQL备份、SQL审计容量相关问题

1. SQL 审计是否会影响实例性能? 2. SQL 审计采集量在哪里查看? 3. 是否可以删除部分 SQL 审计内容? 4. SQL 审计功能是否默认关闭? 5. SQL 审...
李沃晟 2019-12-01 21:42:23 626 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 使用数据传输服务(DTS)将本地数据库迁移到 RDS for MySQL,可以实现应用不停服务的情况下,平滑完成数据库的迁移工作。 背景信息 DTS 数据迁移支持 MySQL 的结构迁移、全量迁移和增量迁移。 结构迁移 DTS 会将本地数据库的结构定义迁移到目标实例。目前 DTS 支持结构迁移的对象有:表、视图、触发器、存储过程、存储函数。 全量迁移 DTS 会将本地数据库迁移对象的数据全部迁移到目标实例。如果用户还选择了增量迁移,那么全量迁移过程中,为了保证数据一致性,无主键的非事务表会被锁定,锁定期间这些表无法写入,锁定时长依赖于这些表的数据量大小,在这些无主键非事务表迁移完成后,锁才会释放。 增量迁移 增量迁移会将迁移过程进行数据变更同步到目标实例,如果迁移期间进行了 DDL 操作,那么这些结构变更不会迁移到目标实例。 迁移限制 将本地数据库迁移到 RDS 上有以下限制。 迁移过程中,不支持 DDL 操作 结构迁移不支持 event 的迁移 如果使用了对象名映射功能后,依赖这个对象的其他对象可能迁移失败 当选择增量迁移时,本地 MySQL 实例需要开启 binlog,且本地库的 binlog_format 要为 row。如果本地 MySQL 为5.6版本时,它的 binlog_row_image 还须设置为 full 前提条件 已完成 RDS 实例数据库的准备,可参见申请外网地址和 MySQL 5.7高可用版/5.5/5.6创建数据库和账号。 操作步骤 本例以有公网 IP 的本地数据库迁移到 RDS 上为例。 准备本地数据 在正式迁移之前,需要先在本地数据库和 RDS 实例中创建迁移账号,并在 RDS 实例中创建要迁移的数据库,并将要迁移的数据库的读写权限授权给迁移账号。不同的迁移类型需要不同的权限,如下表所示。 迁移类型 结构迁移 全量迁移 增量迁移 本地数据库 select select select replication slave replication client RDS 实例 读写权限 读写权限 读写权限 在本地数据库中创建迁移账号。CREATE USER 'username'@'host' IDENTIFIED BY 'password';参数说明: username:要创建的账号 host:指定该账号登录数据库的主机。如果是本地用户可以使用 localhost,如果想让该用户从任意主机登录,可以使用通配符 % password:该账号的登录密码 例:要创建账号为 William,密码为 Changme123 的账号从任意主机登录本地数据库,命令如下: CREATE USER 'William'@'%' IDENTIFIED BY 'Changme123'; 在本地数据库中给迁移账号授权,本地数据库中迁移账号的权限要求请参见上表。GRANT privileges ON databasename.tablename TO 'username'@'host' WITH GRANT OPTION;参数说明: privileges:该账号的操作权限,如 SELECT、INSERT、UPDATE 等。如果要授权该账号所有权限,则使用 ALL databasename:数据库名。如果要授权该账号所有的数据库权限,则使用通配符 * tablename:表名。如果要授权该账号所有的表权限,则使用通配符 * username:要授权的账号名 host:授权登录数据库的主机名。如果是本地用户可以使用 localhost,如果想让该用户从任意主机登录,可以使用通配符 % WITH GRANT OPTION:授权该账号能使用GRANT命令,该参数为可选 例:授权账号 William 对所有数据库和表的所有权限,并可以从任意主机登录本地数据库,命令如下: GRANT ALL ON *.* TO 'William'@'%'; 说明 如果需要进行增量迁移,那么需要确认本地数据库的 binlog 是否开启并正确设置,执行以下步骤。 开启本地数据库的 binlog。 使用如下命令查询是否开启了binlog。show global variables like "log_bin";如果查询结果为 log_bin=OFF,那么本地数据库没有开启 binlog。为了使迁移过程中产生的增量数据能同步迁移,需要修改配置文件 my.cnf 中的如下参数。 log_bin=mysql_bin binlog_format=row server_id=大于 1 的整数 binlog_row_image=full //当本地 MySQL 版本大于 5.6 时,则需设置该项 修改完成后,重启 MySQL 进程。$mysql_dir/bin/mysqladmin -u root -p shutdown $mysql_dir/bin/safe_mysqld &其中,“mysql_dir”为MySQL安装目录。 正式迁移操作 数据准备完毕后,即可进入正式的迁移操作。 在 RDS 管理控制台 上单击迁移数据库,进入 DTS,如下图所示。 单击 创建在线迁移任务,进入 创建迁移任务 页面,如下图所示。 输入任务名称、本地数据库信息和目标数据库信息,单击 授权白名单并进入下一步,如下图所示。 任务名称:自定义任务名称,可以保持默认值 源库信息 实例类型:本地数据库的实例类型,可以选择有公网IP的自建数据库、ECS上的自建数据库、RDS实例、云数据库MongoDB 数据库类型:本地数据库的类型,可以选择 Oracle、MySQL、SQLServer、PostgreSQL、MongoDB 主机名或 IP 地址:本地数据库的公网地址 端口:本地数据库的公网端口 账号:本地数据库的迁移账号 密码:本地数据库迁移账号对应的密码 目标库信息 实例类型:默认为 RDS 实例 RDS 实例 ID:目标 RDS 实例的 ID。点击下拉菜单将自动联想当前登录 RDS 管理控制台 的账号的 RDS 实例,点击选择所需要的实例 账号:目标 RDS 数据库的迁移账号 密码:目标 RDS 数据库迁移账号对应的密码 择迁移类型,并在 迁移对象 中选择要迁移的对象,单击 > 将要迁移的对象放入已选择中,单击 预检查并启动,如下图所示。 说明 数据迁移只会将本地数据库的数据(结构)复制一份到目标数据库,并不会对本地数据库数据(结构)造成影响。 如果要修改迁移对象在目标数据库上的名字,可以在 已选择 列表右侧单击 编辑,修改已选择的对象名称,如上图4所示。 说明 以下以预检查不通过为例进行描述,如果预检查通过,请直接参见步骤 8。 系统显示预检查结果,如下图所示。 单击检测结果 为失败的检测项后的 !,查看失败详细信息,根据失败详细信息完成错误排查。 错误排查完毕后,在 迁移任务列表页面,选择当前迁移任务,单击 启动,如下图所示。 系统预检查通过后,单击确定,自动进行迁移任务,如下图所示。 后续操作 因迁移账号拥有读写权限,为了保证本地数据库安全,请在数据迁移完成后,删除本地数据库和 RDS 实例中的迁移账号。
2019-12-01 22:57:10 0 浏览量 回答数 0

回答

直接恢复是使用备份文件做全量恢复,这是最常见的场景 2.1.mysqldump备份全量恢复 使用 mysqldump 文件恢复数据非常简单,直接解压了执行 gzip -d backup.sql.gz | mysql -u -h -P -p 2.2.xtrabackup备份全量恢复 恢复过程 步骤一:解压(如果没有压缩可以忽略这一步) innobackupex --decompress <备份文件所在目录> 步骤二:应用日志 innobackupex --apply-log <备份文件所在目录> 步骤三:复制备份文件到数据目录 innobackupex --datadir=<MySQL数据目录> --copy-back <备份文件所在目录> 2.3.基于时间点恢复 基于时间点的恢复依赖的是binlog日志,需要从 binlog 中找过从备份点到恢复点的所有日志,然后应用,我们测试一下 新建测试表 chengqm-3306>>show create table mytest.mytest \G; *************************** 1. row *************************** Table: mytest Create Table: CREATE TABLE mytest ( id int(11) NOT NULL AUTO_INCREMENT, ctime datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 每秒插入一条数据 [mysql@mysql-test ~]$ while true; do mysql -S /tmp/mysql.sock -e 'insert into mytest.mytest(ctime)values(now())';date;sleep 1;done 备份 [mysql@mysql-test ~]$ mysqldump --opt --single-transaction --master-data=2 --default-character-set=utf8 -S /tmp/mysql.sock -A > backup.sql 找出备份时的日志位置 [mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000032', MASTER_LOG_POS=39654; 假设要恢复到 2019-08-09 11:01:54 这个时间点,我们从 binlog 中查找从 39654 到 019-08-09 11:01:54 的日志 [mysql@mysql-test ~]$ mysqlbinlog --start-position=39654 --stop-datetime='2019-08-09 11:01:54' /data/mysql_log/mysql_test/mysql-bin.000032 > backup_inc.sql [mysql@mysql-test-83 ~]$ tail -n 20 backup_inc.sql ...... INSERT INTO mytest.mytest SET @1=161 /* INT meta=0 nullable=0 is_null=0 */ @2='2019-08-09 11:01:53' /* DATETIME(0) meta=0 nullable=1 is_null=0 */ ...... 当前数据条数 -- 2019-08-09 11:01:54之前的数据条数 chengqm-3306>>select count() from mytest.mytest where ctime < '2019-08-09 11:01:54'; +----------+ | count() | +----------+ | 161 | +----------+ 1 row in set (0.00 sec) -- 所有数据条数 chengqm-3306>>select count() from mytest.mytest; +----------+ | count() | +----------+ | 180 | +----------+ 1 row in set (0.00 sec) 然后执行恢复 全量恢复 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup.sql 应用增量日志 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc.sql 检查数据 chengqm-3306>>select count() from mytest.mytest; +----------+ | count() | +----------+ | 161 | +----------+ 1 row in set (0.00 sec) chengqm-3306>>select * from mytest.mytest order by id desc limit 5; +-----+---------------------+ | id | ctime | +-----+---------------------+ | 161 | 2019-08-09 11:01:53 | | 160 | 2019-08-09 11:01:52 | | 159 | 2019-08-09 11:01:51 | | 158 | 2019-08-09 11:01:50 | | 157 | 2019-08-09 11:01:49 | +-----+---------------------+ 5 rows in set (0.00 sec) 已经恢复到 2019-08-09 11:01:54 这个时间点 3.恢复一个表 3.1.从mysqldump备份恢复一个表 假设要恢复的表是 mytest.mytest 提取某个库的所有数据 sed -n '/^-- Current Database: mytest/,/^-- Current Database:/p' backup.sql > backup_mytest.sql 从库备份文件中提取建表语句 sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE mytest/!d;q' backup_mytest.sql > mytest_table_create.sql 从库备份文件中提取插入数据语句 grep -i 'INSERT INTO mytest' backup_mytest.sql > mytest_table_insert.sql 恢复表结构到 mytest 库 mysql -u -p mytest < mytest_table_create.sql 恢复表数据到 mytest.mytest 表 mysql -u -p mytest < mytest_table_insert.sql 3.2.从xtrabackup备份恢复一个表 假设 ./backup_xtra_full 目录为解压后应用过日志的备份文件 3.2.1 MyISAM 表 假设从备份文件中恢复表 mytest.t_myisam,从备份文件中找到 t_myisam.frm t_myisam.MYD t_myisam.MYI 这 3 个文件,复制到对应的数据目录中,并授权。 进入 MySQL,检查表情况 chengqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | mytest | | t_myisam | +------------------+ 2 rows in set (0.00 sec) chengqm-3306>>check table t_myisam; +-----------------+-------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-----------------+-------+----------+----------+ | mytest.t_myisam | check | status | OK | +-----------------+-------+----------+----------+ 1 row in set (0.00 sec) 3.2.2.Innodb 表 假设从备份文件中恢复表 mytest.t_innodb,恢复前提是设置了 innodb_file_per_table = on 起一个新实例 在实例上建一个和原来一模一样的表 执行 alter table t_innodb discard tablespace;,删除表空间,这个操作会把 t_innodb.ibd 删除 从备份文件中找到 t_innodb.ibd 这个文件,复制到对应的数据目录,并授权 执行 alter table t_innodb IMPORT tablespace; 加载表空间 执行 flush table t_innodb;check table t_innodb; 检查表 使用 mysqldump 导出数据,然后再导入到要恢复的数据库 注意: 在新实例上恢复再dump出来是为了避免风险,如果是测试,可以直接在原库上操作步骤 2-6 只在 8.0 以前的版本有效 4.跳过误操作SQL 跳过误操作 SQL 一般用于执行了无法闪回的操作比如 drop table\database 4.1.使用备份文件恢复跳过 4.1.1.不开启 GTID 使用备份文件恢复的步骤和基于时间点恢复的操作差不多,区别在于多一个查找 binlog 操作 举个例子,我这里建立了两个表 a 和 b,每分钟插入一条数据,然后做全量备份,再删除表 b,现在要跳过这条 SQL。 删除表 b 后的数据库状态 chgnqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | +------------------+ 1 row in set (0.00 sec) 1 找出备份时的日志位置 [mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000034', MASTER_LOG_POS=38414; 2 找出执行了 drop table 语句的 pos 位置 [mysql@mysql-test mysql_test]$ mysqlbinlog -vv /data/mysql_log/mysql_test/mysql-bin.000034 | grep -i -B 3 'drop table b'; at 120629 #190818 19:48:30 server id 83 end_log_pos 120747 CRC32 0x6dd6ab2a Query thread_id=29488 exec_time=0 error_code=0 SET TIMESTAMP=1566128910/!/; DROP TABLE b /* generated by server */ 从结果中我们可以看到 drop 所在语句的开始位置是 120629,结束位置是 120747 3 从 binglog 中提取跳过这条语句的其他记录 第一条的 start-position 为备份文件的 pos 位置,stop-position 为 drop 语句的开始位置 mysqlbinlog -vv --start-position=38414 --stop-position=120629 /data/mysql_log/mysql_test/mysql-bin.000034 > backup_inc_1.sql 第二条的 start-position 为 drop 语句的结束位置 mysqlbinlog -vv --start-position=120747 /data/mysql_log/mysql_test/mysql-bin.000034 > backup_inc_2.sql 4 恢复备份文件 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup.sql 全量恢复后状态 chgnqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 2 rows in set (0.00 sec) chgnqm-3306>>select count() from a; +----------+ | count() | +----------+ | 71 | +----------+ 1 row in set (0.00 sec) 5 恢复增量数据 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc_1.sql [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc_2.sql 恢复后状态,可以看到已经跳过了 drop 语句 chgnqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 2 rows in set (0.00 sec) chgnqm-3306>>select count() from a; +----------+ | count() | +----------+ | 274 | +----------+ 1 row in set (0.00 sec) 4.1.2 开启 GTID 使用 GTID 可以直接跳过错误的 SQL 1.找出备份时的日志位置 2.找出执行了 drop table 语句的 GTID 值 3.导出备份时日志位置到最新的 binglog 日志 4.恢复备份文件 5.跳过这个 GTID SET SESSION GTID_NEXT='对应的 GTID 值'; BEGIN; COMMIT; SET SESSION GTID_NEXT = AUTOMATIC; 6.应用步骤 3 得到的增量 binlog 日志 4.2 使用延迟库跳过 4.2.1 不开启 GTID 使用延迟库恢复的关键操作在于 start slave until 我在测试环境搭建了两个 MySQL 节点,节点二延迟600秒,新建 a,b 两个表,每秒插入一条数据模拟业务数据插入。 localhost:3306 -> localhost:3307(delay 600) 当前节点二状态 chengqm-3307>>show slave status \G; ... Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000039 Read_Master_Log_Pos: 15524 Relay_Log_File: mysql-relay-bin.000002 Relay_Log_Pos: 22845 Relay_Master_Log_File: mysql-bin.000038 Slave_IO_Running: Yes Slave_SQL_Running: Yes ... Seconds_Behind_Master: 600 ... 当前节点二表 chengqm-3307>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 在节点一删除表 b chengqm-3306>>drop table b; Query OK, 0 rows affected (0.00 sec) chengqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | +------------------+ 1 row in set (0.00 sec) 接下来就是跳过这条 SQL 的操作步骤 1 延迟库停止同步 stop slave; 2 找出执行了 drop table 语句的前一句的 pos 位置 [mysql@mysql-test ~]$ mysqlbinlog -vv /data/mysql_log/mysql_test/mysql-bin.000039 | grep -i -B 10 'drop table b'; ... at 35134 #190819 11:40:25 server id 83 end_log_pos 35199 CRC32 0x02771167 Anonymous_GTID last_committed=132 sequence_number=133 rbr_only=no SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/!/; at 35199 #190819 11:40:25 server id 83 end_log_pos 35317 CRC32 0x50a018aa Query thread_id=37155 exec_time=0 error_code=0 use mytest/!/; SET TIMESTAMP=1566186025/!/; DROP TABLE b /* generated by server */ 从结果中我们可以看到 drop 所在语句的前一句开始位置是 35134,所以我们同步到 35134 (这个可别选错了) 3 延迟库同步到要跳过的 SQL 前一条 change master to master_delay=0; start slave until master_log_file='mysql-bin.000039',master_log_pos=35134; 查看状态看到已经同步到对应节点 chengqm-3307>>show slave status \G; ... Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000039 Read_Master_Log_Pos: 65792 ... Slave_IO_Running: Yes Slave_SQL_Running: No Exec_Master_Log_Pos: 35134 ... Until_Log_File: mysql-bin.000039 Until_Log_Pos: 35134 4 跳过一条 SQL 后开始同步 set global sql_slave_skip_counter=1; start slave; 查看同步状态,删除表 b 的语句已经被跳过 chengqm-3307>>show slave status \G; ... Slave_IO_Running: Yes Slave_SQL_Running: Yes ... 1 row in set (0.00 sec) chengqm-3307>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 2 rows in set (0.00 sec) 4.2.2 开启 GTID 使用 GTID 跳过的步骤会简单很多,只要执行一条和要跳过的 SQL 的 GTID 相同的事务就可以跳过了 1.停止同步 2.找出执行了 drop table 语句的 GTID 3.执行这个 GTID 的事务 SET SESSION GTID_NEXT='对应的 GTID 值'; BEGIN; COMMIT; SET SESSION GTID_NEXT = AUTOMATIC; 4.继续同步 5.闪回 闪回操作就是反向操作,比如执行了 delete from a where id=1,闪回就会执行对应的插入操作 insert into a (id,…) values(1,…),用于误操作数据,只对 DML 语句有效,且要求 binlog 格式设为 ROW。本章介绍两个比较好用的开源工具 5.1.binlog2sql binlog2sql 是大众点评开源的一款用于解析 binlog 的工具,可以用于生成闪回语句,项目地址 binlog2sql 5.1.1.安装 wget https://github.com/danfengcao/binlog2sql/archive/master.zip -O binlog2sql.zip unzip binlog2sql.zip cd binlog2sql-master/ 安装依赖 pip install -r requirements.txt 5.1.2 生成回滚SQL python binlog2sql/binlog2sql.py --flashback -h -P -u -p' ' -d -t<table_name> --start-file='<binlog_file>' --start-datetime='<start_time>' --stop-datetime='<stop_time>' > ./flashback.sql python binlog2sql/binlog2sql.py --flashback -h -P -u -p' ' -d -t<table_name> --start-file='<binlog_file>' --start-position=<start_pos> --stop-position=<stop_pos> > ./flashback.sql 5.2 MyFlash MyFlash 是由美团点评公司技术工程部开发维护的一个回滚 DML 操作的工具,项目链接 MyFlash 限制: binlog格式必须为row,且 binlog_row_image=full 仅支持5.6与5.7 只能回滚DML(增、删、改) 5.2.1 安装 依赖(centos) yum install gcc* pkg-config glib2 libgnomeui-devel -y 下载文件 wget https://github.com/Meituan-Dianping/MyFlash/archive/master.zip -O MyFlash.zip unzip MyFlash.zip cd MyFlash-master 编译安装 gcc -w pkg-config --cflags --libs glib-2.0 source/binlogParseGlib.c -o binary/flashback mv binary /usr/local/MyFlash ln -s /usr/local/MyFlash/flashback /usr/bin/flashback 5.2.2 使用 生成回滚语句 flashback --databaseNames= --binlogFileNames=<binlog_file> --start-position=<start_pos> --stop-position=<stop_pos> 执行后会生成 binlog_output_base.flashback 文件,需要用 mysqlbinlog 解析出来再使用
游客2q7uranxketok 2021-02-24 11:16:00 0 浏览量 回答数 0

问题

MYSQL使用(三)

[backcolor=url("]RDS for MySQL 远程获取binlog日志记录[backcolor=url("]RDS for MySQL报错Out of resources when openi...
云栖大讲堂 2019-12-01 21:47:19 938 浏览量 回答数 0

问题

如何将数据备份/恢复

[backcolor=url("]恢复云数据库MySQL的备份文件到自建数据库[backcolor=url("]MySQL Binlog日志的生成和清理规则[backcolor=url("]怎...
云栖大讲堂 2019-12-01 21:47:01 1103 浏览量 回答数 0

回答

本回答引用自以下KB文档:https://help.aliyun.com/knowledge_detail/51682.html 更多帮助请访问以下站点: 阿里云文档中心:https://help.aliyun.com/智能在线:https://ia.aliyun.com/home 自助工具:https://help.aliyun.com/learn/tool.html 问题原因 造成MySQL实例空间满的主要原因有以下四种: 数据文件占用高。Binlog文件占用高。在没有正确设置本地日志设置或不希望Binlog日志被强制删除时,可能会由于大事务导致Binlog日志暴增。临时文件占用高。通常导致临时文件占用高的原因是由于查询语句的排序、分组、关联表产生的临时表文件,或者大事务未提交前产生的Binlog缓存文件。系统文件占用高。系统文件涉及到ibdata1系统表的空间文件和ib_logfile0、ib_logfile1日志文件。InnoDB引擎表由于支持多版本并发控制(MVCC),因此会将查询所需的Undo信息保存在ibdata1系统文件中。如果存在对一个InnoDB表长时间不结束的查询,而且在查询过程中表有大量的数据变化,则会生成大量的Undo信息,导致ibdata1文件体积增加。 说明:由于MySQL内部机制的限制,ibdata1文件目前是不支持收缩的。ib_logfile0和ib_logfile1日志文件保存InnoDB引擎表的事务日志信息,其文件大小体积固定,不可以改变。 有关解决方案的更多详细信息,请查阅https://help.aliyun.com/knowledge_detail/51682.html
阿里云内容团队 2020-12-14 15:42:54 0 浏览量 回答数 0

回答

如果你用不到mysql日志或者说你不会看日志,那么我建议你把mysql的日志功能关掉,因为日志久而久之也会占用很大空间的,以lnmp一键安装包搭建的环境为例,关闭方法如下: vim /etc/my.cnf 编辑mysql配置文件 找到 log-bin=mysql-bin 和 binlog_format=mixed 这两行并在行首分别加 # 以注释 保存并通过 /etc/init.d/mysql restart 命令重启 mysql 服务。 接下来可以把已有的mysql日志清一下,通过 cd /usr/local/mysql/var 命令进入mysql的日志目录 在这里插入图片描述 上图中,文件名称为mysql-bin.000001这样的都是日志文件了,统统删除,执行这个命令即可 rm -rf mysql-bin.*
游客2q7uranxketok 2021-02-19 22:12:47 0 浏览量 回答数 0

回答

在 ECS Linux 上自建 MySQL 服务器,经常遇到各种无法启动或启动后异常的问题,本文列举一些常见问题的解决办法。 注意:以下错误日志提示,都是查看 MySQL 错误日志得到,查看方法如下: 查看下 MySQL 配置文件 my.cnf 中有记录,日志记录在 /alidata/log/mysql/error.log 下 20150507184311.png MySQL 配置文件 my.cnf 权限问题导致无法启动,错误提示:World-writable config file '/etc/my.cnf' is ignored Binlog 丢失导致无法启动,错误日志: File './mysql-bin.000001' not found Binlog 无法读取导致无法启动,错误日志:Failed to open log (file './mysql-bin.000001', errno 13) 不能创建 PID 导致无法启动,错误日志:Can't start server: can't create PID file: No such file or directory 不能创建临时文件导致无法启动,错误日志:mysqld: Can't create/write to file '/tmp/ibfguTtC' (Errcode: 13) MySQL 服务无法识别导致无法启动,错误提示:mysqld: unrecognized service MySQL 配置了过大的内存导致无法启动,错误日志:InnoDB: Cannot allocate memory for the buffer pool MySQL 启动参数过多导致无法启动,错误提示:Too many arguments (first extra is 'start') MySQL 目录权限问题导致无法启动,错误日志:File './mysql-bin.index' not found (Errcode:13 - Permission denied) MySQL 未初始化导致无法启动,错误提示:can't open the mysql.plugin table MySQL 启动成功但未监听端口 MySQL ibdata1权限问题导致无法启动,错误日志:InnoDB Operating system error number 13 in a file operation 磁盘空间满导致 MySQL 无法启动 进程残留导致 MySQL 无法启动 MySQL 服务自动停止 MySQL 配置文件 my.cnf 权限问题导致无法启动,错误提示:World-writable config file '/etc/my.cnf' is ignored 问题描述 ECS Linux MySQL 无法启动,报如下错误: Snip20160218_7.png 问题分析 查看 MySQL 错误日志发现如下错误(提示 MySQL 库的 host 表无法打开): Snip20160218_8.png 查看 /etc/my.cnf 配置文件: Snip20160218_10.png 到 MySQL 数据库所在目录查看表是否存在: Snip20160218_16.png 发现 MySQL 库的 host 表是存在的,那为什么会提示不存在呢? 问题应该出在 /etc/my.cnf 文件上,从第一个截图也可以看到警告信息(/etc/my.cnf 被忽视) 查看文件权限: Snip20160218_13.png 原来文件权限被设置成 777,因安全问题导致被 MySQL 忽视,所以去查询默认的数据库存放路径,没有 MySQL 库的 host 表导致启动失败: Snip20160218_17.png 解决办法 将 /etc/my.cnf 权限修改成 644,然后启动 MySQL 即可: Snip20160218_18.png Binlog 丢失导致无法启动,错误日志: File './mysql-bin.000001' not found 问题描述 清理磁盘空间时删除了全部 binglog 日志,导致 MySQL 无法启动: 1.JPG MySQL 的 errorlog 里面可以看到错误信息: 1.JPG 解决办法 1、注释 Binlog 配置恢复方法: 编辑 /etc/my.cnf,找到 log-bin=mysql-bin,在前面加#将其注释暂时关闭 binlog,保存修改后启动 MySQL 服务 注意:my.cnf 配置文件路径以实际调用路径为准 2.JPG 2、清理 Binlog 索引恢复方法: 查看 Binlog 索引文件 test002.jpg 所以,需要清空 mysql-bin.index 索引文件后即可,清理方法可以通过 vi 或者 echo 命令清理,如下: echo “” > mysql-bin.index 去除 Binlog 日志索引文件中调用的内容后,测试启动成功。 [root@test var]# /etc/init.d/mysqld startStarting MySQL. SUCCESS! 3、文件还原恢复方法: 提交工单,由我们帮您挂载最近的快照,您从快照磁盘复制最新的 binlog 文件到 mysql 的数据目录下,再重启 MySQL 服务即可。 注意:提交工单时请说明需要挂载快照的磁盘和快照。 正确清理 MySQL Binlog 方法请参考如下命令: mysql -uroot -p 密码use mysql;purge binary logs to ‘mysql-bin.011113’; 注意:mysql-bin.011113 是 Binlog 文件名,mysql-bin.011113 不会被删除,而 mysql-bin.011113 之前的日志都会被删除。 3.JPG Binlog 无法读取导致无法启动,错误日志:Failed to open log (file './mysql-bin.000001', errno 13) 问题描述 MySQL 无法启动报错: Starting MySQL…The server quit without updating PID file [FAILED]a/server/mysql/data/test.pid). 查看 MySQL 的错误日志会提示如下信息: 110711 00:00:00 [ERROR] Failed to open log (file './mysql-bin.000001', errno 13) 这说明 Binlog 日志无法去读,一般由于磁盘空间满,或者权限不正确导致。 解决办法 首先查询磁盘空间: [root@test /]# df -hFilesystem Size Used Avail Use% Mounted on/dev/xvda1 20G 2.7G 17G 14% /tmpfs 498M 0 498M 0% /dev/shm/dev/xvdb1 30G 19G 9.7G 66% /alidata 查看磁盘空间没有满,则需要 ls 命令检查文件权限: -r———— 1 root root 601 Jul 28 2014 mysql-bin.000001 这说明文件属主和权限不正确,需要执行如下两条命令修复(mysql-bin.000001 这个日志文件需要换成具体文件名): chmod 660 mysql-bin.000001chown mysql.mysql mysql-bin.000001 修改正确后已经可以正常启动mysql 不能创建 PID 导致无法启动,错误日志:Can't start server: can't create PID file: No such file or directory 问题描述 MySQL 启动报错信息如下: Starting mysqld (via systemctl): Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details、 [FAILED] 根据提示,使用 systemctl status mysqld.service 和 journalctl -xe 查看服务启动失败的原因。 [root@ ~]# systemctl status mysqld.servicemysqld.service - SYSV: MySQL database server.Loaded: loaded (/etc/rc.d/init.d/mysqld)Active: failed (Result: exit-code) since Wed 2016-01-20 18:26:57 CST; 40s agoDocs: man:systemd-sysv-generator(8)Process: 2979 ExecStart=/etc/rc.d/init.d/mysqld start (code=exited, status=1/FAILURE)Jan 20 18:26:56 spark01 systemd[1]: Starting SYSV: MySQL database server….Jan 20 18:26:57 spark01 mysqld[2979]: MySQL Daemon failed to start.Jan 20 18:26:57 spark01 mysqld[2979]: Starting mysqld: [FAILED]Jan 20 18:26:57 spark01 systemd[1]: mysqld.service: control process exited, code=exited status=1Jan 20 18:26:57 spark01 systemd[1]: Failed to start SYSV: MySQL database server..Jan 20 18:26:57 spark01 systemd[1]: Unit mysqld.service entered failed state.Jan 20 18:26:57 spark01 systemd[1]: mysqld.service failed.[root@ ~]# journalctl -xeUnit session-2.scope has begun starting up.Jan 20 18:26:48 spark01 sshd[2916]: pam_unix(sshd:session): session opened for user spark by (uid=0)Jan 20 18:26:52 spark01 su[2944]: (to root) spark on pts/1Jan 20 18:26:52 spark01 su[2944]: pam_unix(su-l:session): session opened for user root by spark(uid=1000)Jan 20 18:26:56 spark01 polkitd[909]: Registered Authentication Agent for unix-process:2974:117137 (system bus name :1.25Jan 20 18:26:56 spark01 systemd[1]: Starting SYSV: MySQL database server….— Subject: Unit mysqld.service has begun start-up— Defined-By: systemd— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel—— Unit mysqld.service has begun starting up.Jan 20 18:26:57 spark01 mysqld[2979]: MySQL Daemon failed to start.Jan 20 18:26:57 spark01 mysqld[2979]: Starting mysqld: [FAILED]Jan 20 18:26:57 spark01 systemd[1]: mysqld.service: control process exited, code=exited status=1Jan 20 18:26:57 spark01 systemd[1]: Failed to start SYSV: MySQL database server..— Subject: Unit mysqld.service has failed— Defined-By: systemd— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel—— Unit mysqld.service has failed.—— The result is failed.Jan 20 18:26:57 spark01 systemd[1]: Unit mysqld.service entered failed state.Jan 20 18:26:57 spark01 systemd[1]: mysqld.service failed.Jan 20 18:26:57 spark01 polkitd[909]: Unregistered Authentication Agent for unix-process:2974:117137 (system bus name :1. 这些信息并不能提供服务启动失败的真正原因。 查看 MySQL 的告警日志: 2016-01-20T10:00:19.935771Z 0 [ERROR] /usr/sbin/mysqld: Can’t create/write to file ‘/var/run/mysqld/mysqld.pid’ (Errcode: 2 - No such file or directory)2016-01-20T10:00:19.935795Z 0 [ERROR] Can’t start server: can’t create PID file: No such file or directory160120 18:00:20 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 解决办法 MySQL 服务在启动的时候,不能创建 pid 文件。 在终端看一下该目录是否存在,如果不存在,手动创建: [root@ ~]# mkdir -p /var/run/mysqld/ 再次尝试启动 MySQL 服务,报错如下: Starting mysqld (via systemctl): Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details. [FAILED] 查看 MySQL 的告警日志: 2016-01-20T10:28:37.183387Z 0 [ERROR] /usr/sbin/mysqld: Can’t create/write to file ‘/var/run/mysqld/mysqld.pid’ (Errcode: 13 - Permission denied)2016-01-20T10:28:37.183431Z 0 [ERROR] Can’t start server: can’t create PID file: Permission denied160120 18:28:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended160120 18:32:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 权限不正确,/var/run/mysqld/ 的属主和属组还是 root,MySQL 并不能在其中创建文件后修改该目录的属主和属组, [root@ ~]# ls -ld /var/run/mysqld/drwxr-xr-x 2 root root 40 Jan 20 18:28 /var/run/mysqld/[root@ ~]# chown mysql.mysql /var/run/mysqld/[root@ ~]# /etc/init.d/mysqld startStarting mysqld (via systemctl): [ OK ] 不能创建临时文件导致无法启动,错误日志:mysqld: Can't create/write to file '/tmp/ibfguTtC' (Errcode: 13) 问题描述 MySQL 启动失败,错误日志:mysqld: Can't create/write to file '/tmp/ibfguTtC' (Errcode: 13) 说明/tmp目录无法写入 解决办法 1、使用命令 ll -d /tmp 命令检查目录权限 2、使用 chmod 1777 /tmp 设置为正确权限 再测试可以启动成功 test701.jpg MySQL 服务无法识别导致无法启动,错误提示:mysqld: unrecognized service 问题描述 执行 MySQL 启动命令 service mysqld start 时,提示 mysqld: unrecognized service(未识别的服务),现象如图: 1.png 问题分析 因为 service 命令是通过 /etc/init.d 启动服务目录来调用的,所以我们需要看一下 /etc/init.d 是否存在 mysqld 这个服务,使用 find /etc/init.d/ -name mysqld 命令来查找,发现没有 mysqld 这个文件了 2.png 这个就是导致通过 service 命令启动报错的原因了,这时候我们需要将源码包中的 mysql.server 拷贝复制到 /etc/init.d/ 下,先使用 find / -name mysql.server 命令来查找下 mysql.server 文件位置,发现是在 /alidata/server/mysql-5.6.21/support-files/mysql.server 中 3.png 解决办法 现在我们需要将这个文件复制到 /etc/init.d/ 目录下,改名为 mysqld,并且赋予这个文件可执行权限 4.png 最后通过命令 chkconfig —add mysqld 添加开机自动启动服务 5.png 使用 service mysqld start 启动成功 6.png MySQL 配置了过大的内存导致无法启动,错误提示:InnoDB: Cannot allocate memory for the buffer pool 问题描述 MySQL 启动时报错,查看错误日志有[ERROR] InnoDB: Cannot allocate memory for the buffer pool(不能从缓存池中分配给innodb引擎需要的内存) 解决办法 需要调整 MySQL 配置文件 my.cnf 中的 "innodb_buffer_pool_size"、"key_buffer_size" 的大小设置,适当的调大内存分配,一般调整为系统内存的一半 先使用 free -m 查看下系统内存大小,查看是 1G 内存 1.png 那么 vi /etc/my.cnf,调整 "innodb_buffer_pool_size"、"key_buffer_size" 各为 500M 注意:my.cnf 以实际配置文件路径为准。 2.png 重启 MySQL 服务使其生效 3.png MySQL 启动参数过多导致无法启动,错误提示:Too many arguments (first extra is 'start') 问题描述 ECS Linux 系统安装 MySQL,启动的方式有多种,如果输入 /路径/mysqld start —user=mysql 启动后,出现报错:Too many arguments (first extra is 'start'),则说明这是因为启动 MySQL 的时候参数过多导致。 解决办法 遇到该问题,通过直接输入 /路径/mysqld —user=mysql,的方式启动,如下图: MySQL 目录权限问题导致无法启动,错误提示:File './mysql-bin.index' not found (Errcode:13 - Permission denied) 问题描述 MySQL 启动报错,错误日志,如下图 提示的异常为权限异常,我们到 data 目录查看 mysql-bin.index 的权限 正常情况下 data 目录下文件的属主和属组都应该是 mysql,目前为 root 备注:不太熟悉权限的朋友可以找一台正常的 MySQL 主机对比下 解决办法 找到问题之后解决起来就比较好办了,授予正确的权限,然后启动 MySQL MySQL 未初始化导致无法启动,错误提示:can't open the mysql.plugin table 问题描述 MySQL 服务启动时提示: ERROR! MySQL manager or server PID file could not be found! Starting MySQL. ERROR! Manager of pid-file quit without updating file. 问题分析 查看错误日志提示:can't open the mysql.plugin table ,please run mysql_upgrade to create it 解决办法 使用如下命令指定 datadir 与 basedir 进行初始化启动: /alidata/server/mysql-5.1.73/scripts/mysql_install_db —user=mysql —datadir=/alidata/server/mysql/data —basedir=/alidata/server/mysql-5.1.73/ 注意:以实际 MySQL 安装路径为准 MySQL 启动成功但未监听端口 问题描述 MySQL 启动成功,使用 ps -ef |grep mysql 可以看到进程,如下图: 也可以在服务器登陆,如下图: 但是使用 netstat -antp| grep 3306 可以看到没有监听端口。 查看 MySQL 配置文件,端口也没有更改。 解决办法 检查发现是配置文件中使用了 skip-networking,可以看到这个选项的的作用是不监听端口,同主机的用户通过 sockets 进行链接。外部主机由于没有监听端口,将无法连接。 将 skip-networking 注释掉之后,重启 MySQL 可以看到端口监听了。 MySQL ibdata1权限问题导致无法启动,错误日志:InnoDB Operating system error number 13 in a file operation 问题描述 mysql启动提示 update pid 失败: Starting MySQL. ERROR! Manager of pid-file quit without updating file. 同时错误日志中记录: InnoDB Operating system error number 13 in a file operation,如图: 解决办法 从该报错看,是提示操作系统访问文件 /usr/local/mysql/var/idata1 无权限 查看权限如下: 调整为 MySQL 可以访问的权限后,比如 777,或者是调整属帐号为 mysql,可以正常启动 MySQL。 磁盘空间满导致 MySQL 无法启动 问题描述 启动 MySQL 报错:ERROR! MySQL manager or server PID file could not be found! Starting MySQL. ERROR! Manager of pid-file quit without updating file. 查看下 MySQL 错误日志提示: 没有记录有效的信息,磁盘空间不足会导致这种情况 解决办法 df -h 看下 find / -size +100M 查看下大于100M 的文件 MySQL 日志占用空间太大,无特殊需求可以删除掉。 进程残留导致 MySQL 无法启动 问题描述 MySQL 启动失败,错误提示:Starting MySQL. ERROR! Manager of pid-file quit without updating file. [root@iZ9410f0jqiZ bin]# Starting MySQL. ERROR! Manager of pid-file quit without updating file. 使用 ps -A | grep mysqld ,发现 mysqld 和 mysqld_safe 进程残留,进程 ID 994 和 1221 解决办法 kill两个进程之后重新启动 MySQL 成功启动 MySQL服务自动停止 问题描述 服务器上安装的 MySQL,会出现自动停止的情况。出现这种现象,通常是服务器的内存不足导致的。 具体可以通过服务器日志来进行分析排查: 查看服务器的系统日志 /var/log/messages tail /var/log/messages 看下在 MySQL 自动停止的时间段内,有什么异常的日志信息,如果日志有提示 “Out of memory” 就可以判定,是服务器的内存使用不足,导致系统自动杀死的 MySQL 的进程 解决办法 通过升级服务器的内存可以解决.
KB小秘书 2019-12-02 02:07:16 0 浏览量 回答数 0

回答

ECS Linux MySQL 常见无法启动或启动异常的解决方案 在 ECS Linux 上自建 MySQL 服务器,经常遇到各种无法启动或启动后异常的问题,本文列举一些常见问题的解决办法。 注意:以下错误日志提示,都是查看 MySQL 错误日志得到,查看方法如下: 查看下 MySQL 配置文件 my.cnf 中有记录,日志记录在 /alidata/log/mysql/error.log 下   MySQL 配置文件 my.cnf 权限问题导致无法启动,错误提示: World-writable config file '/etc/my.cnf' is ignored Binlog 丢失导致无法启动,错误日志: File './mysql-bin.000001' not found Binlog 无法读取导致无法启动,错误日志:Failed to open log (file './mysql-bin.000001', errno 13) 不能创建 PID 导致无法启动,错误日志:Can't start server: can't create PID file: No such file or directory 不能创建临时文件导致无法启动,错误日志:mysqld: Can't create/write to file '/tmp/ibfguTtC' (Errcode: 13) MySQL 服务无法识别导致无法启动,错误提示:mysqld: unrecognized service MySQL 配置了过大的内存导致无法启动,错误日志:InnoDB: Cannot allocate memory for the buffer pool MySQL 启动参数过多导致无法启动,错误提示:Too many arguments (first extra is 'start') MySQL 目录权限问题导致无法启动,错误日志:File './mysql-bin.index' not found (Errcode:13 - Permission denied) MySQL 未初始化导致无法启动,错误提示:can't open the mysql.plugin table MySQL 启动成功但未监听端口 MySQL ibdata1权限问题导致无法启动,错误日志:InnoDB Operating system error number 13 in a file operation 磁盘空间满导致 MySQL 无法启动 进程残留导致 MySQL 无法启动 MySQL 服务自动停止 MySQL 配置文件 my.cnf 权限问题导致无法启动,错误提示:World-writable config file '/etc/my.cnf' is ignored 问题描述 ECS Linux MySQL 无法启动,报如下错误: 问题分析 查看 MySQL 错误日志发现如下错误(提示 MySQL 库的 host 表无法打开): 查看 /etc/my.cnf 配置文件: 到 MySQL 数据库所在目录查看表是否存在: 发现 MySQL 库的 host 表是存在的,那为什么会提示不存在呢? 问题应该出在 /etc/my.cnf 文件上,从第一个截图也可以看到警告信息(/etc/my.cnf 被忽视) 查看文件权限: 原来文件权限被设置成 777,因安全问题导致被 MySQL 忽视,所以去查询默认的数据库存放路径,没有 MySQL 库的 host 表导致启动失败: 解决办法 将 /etc/my.cnf 权限修改成 644,然后启动 MySQL 即可:   Binlog 丢失导致无法启动,错误日志: File './mysql-bin.000001' not found 问题描述 清理磁盘空间时删除了全部 binglog 日志,导致 MySQL 无法启动: MySQL 的 errorlog 里面可以看到错误信息: 解决办法 1、注释 Binlog 配置恢复方法: 编辑 /etc/my.cnf,找到 log-bin=mysql-bin,在前面加#将其注释暂时关闭 binlog,保存修改后启动 MySQL 服务 注意:my.cnf 配置文件路径以实际调用路径为准 2、清理 Binlog 索引恢复方法: 查看 Binlog 索引文件 所以,需要清空 mysql-bin.index 索引文件后即可,清理方法可以通过 vi 或者 echo 命令清理,如下: echo “” > mysql-bin.index 去除 Binlog 日志索引文件中调用的内容后,测试启动成功。 [root@test var]# /etc/init.d/mysqld startStarting MySQL. SUCCESS! 3、文件还原恢复方法: 提交工单,由我们帮您挂载最近的快照,您从快照磁盘复制最新的 binlog 文件到 mysql 的数据目录下,再重启 MySQL 服务即可。 注意:提交工单时请说明需要挂载快照的磁盘和快照。 正确清理 MySQL Binlog 方法请参考如下命令: mysql -uroot -p 密码use mysql;purge binary logs to ‘mysql-bin.011113’; 注意:mysql-bin.011113 是 Binlog 文件名,mysql-bin.011113 不会被删除,而 mysql-bin.011113 之前的日志都会被删除。   Binlog 无法读取导致无法启动,错误日志:Failed to open log (file './mysql-bin.000001', errno 13) 问题描述 MySQL 无法启动报错: Starting MySQL…The server quit without updating PID file [FAILED]a/server/mysql/data/test.pid). 查看 MySQL 的错误日志会提示如下信息: 110711 00:00:00 [ERROR] Failed to open log (file './mysql-bin.000001', errno 13) 这说明 Binlog 日志无法去读,一般由于磁盘空间满,或者权限不正确导致。 解决办法 首先查询磁盘空间: [root@test /]# df -hFilesystem Size Used Avail Use% Mounted on/dev/xvda1 20G 2.7G 17G 14% /tmpfs 498M 0 498M 0% /dev/shm/dev/xvdb1 30G 19G 9.7G 66% /alidata 查看磁盘空间没有满,则需要 ls 命令检查文件权限: -r———— 1 root root      601 Jul 28  2014 mysql-bin.000001 这说明文件属主和权限不正确,需要执行如下两条命令修复(mysql-bin.000001 这个日志文件需要换成具体文件名): chmod 660 mysql-bin.000001chown mysql.mysql mysql-bin.000001 修改正确后已经可以正常启动mysql   不能创建 PID 导致无法启动,错误日志:Can't start server: can't create PID file: No such file or directory 问题描述 MySQL 启动报错信息如下:  Starting mysqld (via systemctl):  Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details、 [FAILED] 根据提示,使用 systemctl status mysqld.service 和 journalctl -xe 查看服务启动失败的原因。 [root@ ~]# systemctl status mysqld.servicemysqld.service - SYSV: MySQL database server.Loaded: loaded (/etc/rc.d/init.d/mysqld)Active: failed (Result: exit-code) since Wed 2016-01-20 18:26:57 CST; 40s agoDocs: man:systemd-sysv-generator(8)Process: 2979 ExecStart=/etc/rc.d/init.d/mysqld start (code=exited, status=1/FAILURE)Jan 20 18:26:56 spark01 systemd[1]: Starting SYSV: MySQL database server….Jan 20 18:26:57 spark01 mysqld[2979]: MySQL Daemon failed to start.Jan 20 18:26:57 spark01 mysqld[2979]: Starting mysqld: [FAILED]Jan 20 18:26:57 spark01 systemd[1]: mysqld.service: control process exited, code=exited status=1Jan 20 18:26:57 spark01 systemd[1]: Failed to start SYSV: MySQL database server..Jan 20 18:26:57 spark01 systemd[1]: Unit mysqld.service entered failed state.Jan 20 18:26:57 spark01 systemd[1]: mysqld.service failed.[root@ ~]# journalctl -xeUnit session-2.scope has begun starting up.Jan 20 18:26:48 spark01 sshd[2916]: pam_unix(sshd:session): session opened for user spark by (uid=0)Jan 20 18:26:52 spark01 su[2944]: (to root) spark on pts/1Jan 20 18:26:52 spark01 su[2944]: pam_unix(su-l:session): session opened for user root by spark(uid=1000)Jan 20 18:26:56 spark01 polkitd[909]: Registered Authentication Agent for unix-process:2974:117137 (system bus name :1.25Jan 20 18:26:56 spark01 systemd[1]: Starting SYSV: MySQL database server….— Subject: Unit mysqld.service has begun start-up— Defined-By: systemd— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel—— Unit mysqld.service has begun starting up.Jan 20 18:26:57 spark01 mysqld[2979]: MySQL Daemon failed to start.Jan 20 18:26:57 spark01 mysqld[2979]: Starting mysqld: [FAILED]Jan 20 18:26:57 spark01 systemd[1]: mysqld.service: control process exited, code=exited status=1Jan 20 18:26:57 spark01 systemd[1]: Failed to start SYSV: MySQL database server..— Subject: Unit mysqld.service has failed— Defined-By: systemd— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel—— Unit mysqld.service has failed.—— The result is failed.Jan 20 18:26:57 spark01 systemd[1]: Unit mysqld.service entered failed state.Jan 20 18:26:57 spark01 systemd[1]: mysqld.service failed.Jan 20 18:26:57 spark01 polkitd[909]: Unregistered Authentication Agent for unix-process:2974:117137 (system bus name :1. 这些信息并不能提供服务启动失败的真正原因。 查看 MySQL 的告警日志: 2016-01-20T10:00:19.935771Z 0 [ERROR] /usr/sbin/mysqld: Can’t create/write to file ‘/var/run/mysqld/mysqld.pid’ (Errcode: 2 - No such file or directory)2016-01-20T10:00:19.935795Z 0 [ERROR] Can’t start server: can’t create PID file: No such file or directory160120 18:00:20 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 解决办法 MySQL 服务在启动的时候,不能创建 pid 文件。 在终端看一下该目录是否存在,如果不存在,手动创建:  [root@ ~]# mkdir -p /var/run/mysqld/ 再次尝试启动 MySQL 服务,报错如下: Starting mysqld (via systemctl):  Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details. [FAILED] 查看 MySQL 的告警日志: 2016-01-20T10:28:37.183387Z 0 [ERROR] /usr/sbin/mysqld: Can’t create/write to file ‘/var/run/mysqld/mysqld.pid’ (Errcode: 13 - Permission denied)2016-01-20T10:28:37.183431Z 0 [ERROR] Can’t start server: can’t create PID file: Permission denied160120 18:28:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended160120 18:32:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 权限不正确,/var/run/mysqld/ 的属主和属组还是 root,MySQL 并不能在其中创建文件后修改该目录的属主和属组, [root@ ~]# ls -ld /var/run/mysqld/drwxr-xr-x 2 root root 40 Jan 20 18:28 /var/run/mysqld/[root@ ~]# chown mysql.mysql /var/run/mysqld/[root@ ~]# /etc/init.d/mysqld startStarting mysqld (via systemctl): [ OK ]   不能创建临时文件导致无法启动,错误日志:mysqld: Can't create/write to file '/tmp/ibfguTtC' (Errcode: 13) 问题描述 MySQL 启动失败,错误日志:mysqld: Can't create/write to file '/tmp/ibfguTtC' (Errcode: 13) 说明/tmp目录无法写入 解决办法 1、使用命令 ll -d /tmp 命令检查目录权限 2、使用 chmod 1777 /tmp 设置为正确权限 再测试可以启动成功   MySQL 服务无法识别导致无法启动,错误提示:mysqld: unrecognized service 问题描述 执行 MySQL 启动命令 service mysqld start 时,提示 mysqld: unrecognized service(未识别的服务),现象如图: 问题分析 因为 service 命令是通过 /etc/init.d 启动服务目录来调用的,所以我们需要看一下 /etc/init.d 是否存在 mysqld 这个服务,使用 find /etc/init.d/ -name mysqld 命令来查找,发现没有 mysqld 这个文件了 这个就是导致通过 service 命令启动报错的原因了,这时候我们需要将源码包中的 mysql.server 拷贝复制到 /etc/init.d/ 下,先使用 find / -name mysql.server 命令来查找下 mysql.server 文件位置,发现是在 /alidata/server/mysql-5.6.21/support-files/mysql.server 中 解决办法 现在我们需要将这个文件复制到 /etc/init.d/ 目录下,改名为 mysqld,并且赋予这个文件可执行权限 最后通过命令 chkconfig —add mysqld 添加开机自动启动服务 使用 service mysqld start 启动成功   MySQL 配置了过大的内存导致无法启动,错误提示:InnoDB: Cannot allocate memory for the buffer pool 问题描述 MySQL 启动时报错,查看错误日志有[ERROR] InnoDB: Cannot allocate memory for the buffer pool(不能从缓存池中分配给innodb引擎需要的内存) 解决办法 需要调整 MySQL 配置文件 my.cnf 中的 "innodb_buffer_pool_size"、"key_buffer_size" 的大小设置,适当的调大内存分配,一般调整为系统内存的一半 先使用 free -m 查看下系统内存大小,查看是 1G 内存 那么 vi /etc/my.cnf,调整 "innodb_buffer_pool_size"、"key_buffer_size" 各为 500M 注意:my.cnf 以实际配置文件路径为准。 重启 MySQL 服务使其生效   MySQL 启动参数过多导致无法启动,错误提示:Too many arguments (first extra is 'start') 问题描述 ECS Linux 系统安装 MySQL,启动的方式有多种,如果输入 /路径/mysqld start —user=mysql 启动后,出现报错:Too many arguments (first extra is 'start'),则说明这是因为启动 MySQL 的时候参数过多导致。 解决办法 遇到该问题,通过直接输入 /路径/mysqld —user=mysql,的方式启动,如下图:   MySQL 目录权限问题导致无法启动,错误提示:File './mysql-bin.index' not found (Errcode:13 - Permission denied) 问题描述 MySQL 启动报错,错误日志,如下图 提示的异常为权限异常,我们到 data 目录查看 mysql-bin.index 的权限 正常情况下 data 目录下文件的属主和属组都应该是 mysql,目前为 root 备注:不太熟悉权限的朋友可以找一台正常的 MySQL 主机对比下 解决办法 找到问题之后解决起来就比较好办了,授予正确的权限,然后启动 MySQL   MySQL 未初始化导致无法启动,错误提示:can't open the mysql.plugin table 问题描述 MySQL 服务启动时提示: ERROR! MySQL manager or server PID file could not be found! Starting MySQL. ERROR! Manager of pid-file quit without updating file. 问题分析 查看错误日志提示:can't open the mysql.plugin table ,please run mysql_upgrade to create it 解决办法 使用如下命令指定 datadir 与 basedir 进行初始化启动: /alidata/server/mysql-5.1.73/scripts/mysql_install_db —user=mysql —datadir=/alidata/server/mysql/data —basedir=/alidata/server/mysql-5.1.73/ 注意:以实际 MySQL 安装路径为准   MySQL 启动成功但未监听端口 问题描述 MySQL 启动成功,使用 ps -ef |grep mysql 可以看到进程,如下图: 也可以在服务器登陆,如下图: 但是使用 netstat -antp| grep 3306 可以看到没有监听端口。 查看 MySQL 配置文件,端口也没有更改。 解决办法 检查发现是配置文件中使用了 skip-networking,可以看到这个选项的的作用是不监听端口,同主机的用户通过 sockets 进行链接。外部主机由于没有监听端口,将无法连接。 将 skip-networking 注释掉之后,重启 MySQL 可以看到端口监听了。   MySQL ibdata1权限问题导致无法启动,错误日志:InnoDB Operating system error number 13 in a file operation 问题描述 mysql启动提示 update pid 失败: Starting MySQL. ERROR! Manager of pid-file quit without updating file. 同时错误日志中记录: InnoDB Operating system error number 13 in a file operation,如图: 解决办法 从该报错看,是提示操作系统访问文件 /usr/local/mysql/var/idata1 无权限 查看权限如下: 调整为 MySQL 可以访问的权限后,比如 777,或者是调整属帐号为 mysql,可以正常启动 MySQL。   磁盘空间满导致 MySQL 无法启动 问题描述 启动 MySQL 报错:ERROR! MySQL manager or server PID file could not be found! Starting MySQL. ERROR! Manager of pid-file quit without updating file. 查看下 MySQL 错误日志提示: 没有记录有效的信息,磁盘空间不足会导致这种情况 解决办法 df -h 看下 find / -size +100M 查看下大于100M 的文件 MySQL 日志占用空间太大,无特殊需求可以删除掉。   进程残留导致 MySQL 无法启动 问题描述 MySQL 启动失败,错误提示:Starting MySQL. ERROR! Manager of pid-file quit without updating file. [root@iZ9410f0jqiZ bin]# Starting MySQL. ERROR! Manager of pid-file quit without updating file. 使用 ps -A | grep mysqld ,发现 mysqld 和 mysqld_safe 进程残留,进程 ID 994 和 1221 解决办法 kill两个进程之后重新启动 MySQL 成功启动   MySQL 服务自动停止 问题描述 服务器上安装的 MySQL,会出现自动停止的情况。出现这种现象,通常是服务器的内存不足导致的。 具体可以通过服务器日志来进行分析排查: 查看服务器的系统日志 /var/log/messages tail /var/log/messages 看下在 MySQL 自动停止的时间段内,有什么异常的日志信息,如果日志有提示 “Out of memory” 就可以判定,是服务器的内存使用不足,导致系统自动杀死的 MySQL 的进程 解决办法 通过升级服务器的内存可以解决.
51干警网 2019-12-02 00:35:31 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT