MySQL作为蓝鲸平台存取数据的主要数据库，其稳定性关系到蓝鲸平台的使用体验，而其数据安全性则可能关系到企业IT资产相关信息，在安装和维护蓝鲸平台的过程中应引起足够重视。本文将对如下几个出现过的问题进行分析和提供处理建议。这几个问题分别为：升级，配置日志自动清理，binlog手动清理维护，表清空，备份。
该方法可以删除列于索引文件中的所有二进制日志，把二进制日志索引文件重新设置为空，并创建一个新的二进制日志文件mysql-bin.000001。该语法一般只用在主从环境下初次建立复制时。在主从复制进行过程中，该语句是无效的。
+------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 234592362 | | mysql-bin.000002 | 425234342 | | mysql-bin.000003 | 425345345 | | mysql-bin.000004 | 234234222 | | mysql-bin.000005 | 425994852 | +------------------+-----------+
出现这个问题感觉还是挺疑惑的，因为测试环境已经稳定运行了几个月的时间，一直没有出现过mysql事务锁的问题，于是开始着手查问题。
今天查看两个月前上线的小项目，发现运行非常慢，而且增删改查失效了（吓我一大跳），急急忙忙的就开始了我的线上问题排查之路。
当你某天把所有binlog日志全干掉，数据库没有产生新的日志的时候就可以用手动切换这个方式来产生了…
MySQL中的binlog日志记录了数据库中数据的变动，便于对数据的基于时间点和基于位置的恢复，但是binlog也会日渐增大，占用很大的磁盘空间，因此，要对binlog使用正确安全的方法清理掉一部分没用的日志。
前几天，一早起来，就发现 RDS 挂了，然后也无法重启，后面发现是 bin-log 日志过大，把 RDS 的空间塞满了。
mysql主从 # 主mysql启动 docker run --privileged=true -d -p 3307:3306 --name='mysql_master' \ -e MYSQL_ROOT_PASSWORD=123456 \ -v /opt/mysql_master/log:/var/log/mysql \ -v /opt/mysql_master/data:/var/lib/mysql \ -v /opt/mysql_master/conf:/etc/mysql/conf.d mysql
MySQL是目前最受欢迎和广泛使用的关系型数据库之一。在企业中，经常会遇到MySQL实例磁盘告警的情况，这对于保持数据库的稳定性和可用性非常重要。本文将详细介绍一次MySQL DB实例磁盘告警的处理过程，以及相关的操作和注意事项。
点击▲关注 腾讯云数据库 【迪B课堂】为腾讯云数据库产品经理迪B哥开设的面向数据库开发者、数据库运维人员、云端运维人员的系列培训课程，旨在帮助大家从入门到精通学习和使用数据库。《我说》为迪B课堂的答疑系列，3分钟帮您解决数据库日常运维过程中的小难题。搜索关注腾讯云数据库官方微信，立得10元云代金券，可移动端一键管理数据库。 本期主题是：MySQL中清理Binlog的正确方式 视频核心信息： 在使用MySQL数据库的过程当中，遇到磁盘空间满的时候，我们通常会使用drop、delete或者truncate命令
sudo docker run -p 3307:3306 --name main_mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql
新建主服务器容器实例3307 docker run -p 3307:3306 --name mysql-master \ -v /mydata/mysql-master/log:/var/log/mysql \ -v /mydata/mysql-master/data:/var/lib/mysql \ -v /mydata/mysql-master/conf:/etc/mysql \ -e MYSQL_ROOT_PASSWORD=root \ -d mysql:5.7 进入/mydat
ThinkPHP对系统的日志按照级别来分类，并且这个日志级别完全可以自己定义，系统内部使用的级别包括：
中文无法插入，详见docker mysql设置编码，修改编码后，一定要重新建库建表测试。
1. 背景 在使用MySQL时，如果有大表的存储引擎是InnoDB，并且系统参数innodb_file_per_table设置为1，即每个文件对应一个独立的表空间，当对这些大表进行DROP TABLE时，有时会发现整个数据库系统的性能会有显著下降，包括一些只涉及几行数据的简单SELECT查询和DML语句，而且这些语句和正在删除的大表没有关系。造成这种现象的原因是什么呢？通过什么方式能缓解和避免这个问题呢？ 2. 已知的瓶颈 Percona曾经在MySQL官方5.5.23之前的版本中遇到过这个问题，并且提供
慢查询日志主要用来记录在MySQL数据库中执行时间超过指定阈值时间的查询语句。通过慢查询日志查找出效率底下的SQL语句，并根据需要进行优化。慢查询日志是排查SQL语句性能问题的工具，如果非优化需求不建议开启，开启后会对数据库的性能带来一定影响。----1. 默认情况下慢查询日志关闭的，可以使用以下命令来查看慢查询日志的状态、位置及记录阈值。# 慢查询日志的状态和位置mysql> SHOW VARIABLES LIKE 'slow_query%';+---------------------+--------
在MySQL的日常维护中，我们总会遇到这样或那样的问题，对于那些经常发生且有处理经验的事故，不论是新手还是老司机都能在故障规定的容错时间内解决。而对于那些不常见、比较棘手的问题，新手上路可能就显得举足无措了，这个时候新手和老司机的差距就体现出来了。从知识储备还是工作经验，可能老司机比新手强一点，但如果一个新司机没有日志排错的意识，不具备日志排错的经验，那怎么能学会弯道超车、漂移的快感。我们知道数据库中有很多重要的日志，如错误日志error log、慢日志slow log、二进制日志binary log、查询日志general log等等其他日志，错误日志error log是我们分析问题参考的依据，它记录数据库的启动/运行/停止的过程，包含了info、warning、error三个级别，分析error log也有助于我们了解数据库的运行机制。
我们要使用docker搭建一个mysql的主从复制，那么就相当于要创建两个容器，一个是主的，一个是从的
主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。
原理：主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。1、新建主服务器示例3307docker run -p 3307:3306 --name mysql-master \-v /mydata/mysql-master/log:/var/log/mysql \-v /mydat
本文介绍了MySQL DROP TABLE操作可能存在的性能瓶颈，包括InnoDB引擎表、MyISAM引擎表、以及操作系统层面的限制。针对这些瓶颈，本文提出了相应的优化方案，包括增大InnoDB缓冲池、使用MyISAM存储引擎、以及调整操作系统相关参数。通过这些优化方案，可以有效地提升MySQL数据库的性能，减少DROP TABLE操作对数据库性能的影响。
当磁盘空间超过阈值时，这时需要人为去清理一些不需要的历史大日志文件，那能否做成自动化呢?
使用日志对MySQL进行监视是一种重要的方法，通过日志可以评估服务器的操作状态，服务器崩溃后可以帮助进行数据恢复，使用复制功能时，能够帮助用户判断慢查询，此外还可以帮助用户确认安全合规等问题。本篇将介绍MySQL的各种日志。
进入/mydata/mysql-master/conf目录下新建my.cnf(上面启动容器实例指定的路径)
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
大家好，咱们前面通过十篇的文章介绍了docker的基础篇，从本篇开始，咱们的《docker学习系列》将要进入到高级篇阶段(基础篇大家可以查看之前发布的文章)。
大概就是在几个月之前本人租了一台服务器用来搭建自己的博客(原来的博客是在阿里云香港服务器上面,在十一期间被和谐了),于是租用了1核1G内存的云服务器(三年800多元),可是在使用的过程中发现cpu和内存占用有点异常,查了下发现以下问题:
命令解读： docker run ：创建并运行一个容器 –name : 给容器起一个名字，比如叫做abc -p ：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口 -d：后台运行容器 -e：环境变量，如密码什么的 -v：挂载一个数据卷到某个容器内目录，上面分别配置了日志、数据、配置的数据卷
CentOS默认安装了MariaDB数据库,这是属于mysql的一个分支,安装之前需要将相应的依赖包进行删除干净,否者否出现各种异常
需求背景：有个 调用统计日志存储和统计需求 ，要求存储到mysql中；存储数据高峰能达到日均千万，瓶颈在于 直接入库并发太高，可能会把mysql干垮 。
使用数据库的时候，我们每个操作都十分小心，尤其是不能直接在数据库上执行 update、delete 等操作，否则万一忘记加全 where 条件，可能就会造成无法挽回的结果。 有一句十分流行的调侃 — “从删库到跑路”就很形象的说明了误操作后的结果，那么如果你真的不小心执行了删库操作，真的就无法挽回了吗？ 当然不会了，通常对于线上数据库，我们都会定时冷备，dump 导出数据库的全量备份，并且保留一段时间内的所有修改日志，进而实现在必要时回滚到这段时间内的任何一秒。 这里提到的“日志”指的就是 binlog，那么究竟什么是 binlog 呢？本文我们就来详细介绍一下。
今天对象在学习 Mybatis 时发现 org.apache.ibatis.session.SqlSession 对象的 clearCache() 方法并不能清理一级缓存, 同一 session 下相同查询条件返回的结果还是旧值。测试代码如下
对于节假日，难得的假期，尤其是外出的时候碰上几个数据库报警，那些报警又属于不得不处理的时候，真是让人上火，所以也想了一些办法来尽可能杜绝和避免这种情况。
最近开始写文章都是带两个主题，技术主题与生活主题，生活热点，还是老传统，技术在前，生活话题在后。
由于能力有限，系列文章难免会存在错误或者遗漏，如果您有任何建议，可以私信给“悦专栏”公众号，我们会第一时间进行反馈。
MySQL是一种流行的开源关系型数据库管理系统，在许多应用中被广泛使用。有时在启动MySQL服务时，可能会遇到服务无法启动的问题。这类问题通常会导致数据库无法正常工作，影响应用程序的运行。
上一篇文章中,我们了解了一条查询语句的执行过程,按理说这篇应该讲一条更新语句的执行过程,但这个过程比较复杂,涉及到了好几个日志与事物,所以先梳理一下3个重要的日志,bin log(归档日志)、redo log(重做日志)、undo log(回滚日志)
今天给大家分享MySQL中的三种核心日志——Redo Log、Undo Log和Binlog，涵盖它们的介绍、作用、存储位置、写入机制、记录格式、特点以及如何管理这些日志。
MySQL数据库主从复制在缺省情况下从库的relay logs会在SQL线程执行完毕后被自动删除，但是对于MHA场景下，对于某些滞后从库的恢复依赖于其他从库的relay log，因此采取禁用自动删除功能以及定期清理的办法。对于清理过多过大的relay log需要注意引起的复制延迟资源开销等。MHA可通过purge_relay_logs脚本及配合cronjob来完成此项任务，具体描述如下。
MySQL WAL（Write-Ahead Logging）技术：是 MySQL 数据库的一种重要机制，主要关于数据库系统中的事务处理和日志管理。
MySQL的事件调度器是一种在数据库中定义和执行周期性任务和定时器的机制。通过事件调度器，您可以在指定的时间间隔内自动执行某些任务，例如数据备份、数据清理等。MySQL的事件调度器基于时间触发，可以使用SQL语句定义和管理任务，并且具有高度灵活性和可配置性。
InnoDB存储引擎层产生，物理日志，记录的是对页的修改，innodb1.2版本后，最大512GB
在 mysql 上执行了一句 drop database 半天没有完成，详细的慢查询日志如下，那当时MySQL 在做什么呢？
在一个繁忙的master db server上，MySQL binlog日志文件增长速度很快，如果不定时清除，硬盘空间很快就会被充满。
今天访问网站出现数据库链接错误，然后想重启 lnmp 环境，发现无法正常关闭 mysql 服务，回想一下，服务器已经平稳运行 4 个多月了，配置方面应该没有什么问题，所以想到，可能是数据盘空间用完了，果然如此。就想到应该是日志文件导致的，最后检查到 mysql 的日志文件超过，而且居然好几个日志文件几个G。好吧，看来问题就是出在这里。百度到军哥的博客，删除了所有 mysql-bin.0000*日志文件，重启就OK了，顺手把 mysql 日志功能关闭了。
数据库运行久了, 日志就很多, 很占空间. 就需要定期清理, 人工清理一是麻烦, 二是容易出错
在 Linux 上自建 MySQL 服务器，经常遇到各种无法启动或启动后异常的问题，本文列举一些常见问题的解决办法。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
