挺多朋友问我宝塔面板的二进制日志怎么关闭,其实前面介绍过宝塔的二进制日志,因为最开始买的服务器硬盘不够,二进制日志文件生成的文件比较占空间,还导致mysql服务启动不了,最后因此关掉了宝塔的二进制日志,具体可以参见关闭二进制日志文件解决宝塔面板mysql服务无法启动。
有时慢查询日志可能会很大,这时我们可以清空慢日志查询文件,然后执行执行慢的sql,再用pt-query-digest或者其他工具分析该日志,我们可以通过下面的命令轻松清空慢查询日志文件:
初次接触二阶段提交,源于想以事务的方式实现对 MongoDB 中多个集合数据的修改,而 MongoDB 本身不支持事务,官方推荐的方案就是使用二阶段提交。
我发现很多人的服务器上都运行着一些诸如每天切分Nginx日志之类的CRON脚本,大家似乎遗忘了Logrotate,争相发明自己的轮子,这真是让人沮丧啊!就好比明明身边躺着现成的性感美女,大家却忙着自娱自乐,罪过!
出现这个问题感觉还是挺疑惑的,因为测试环境已经稳定运行了几个月的时间,一直没有出现过mysql事务锁的问题,于是开始着手查问题。
作者:操盛春,爱可生技术专家,公众号『一树一溪』作者,专注于研究 MySQL 和 OceanBase 源码。
binlog 就是binary log,二进制日志文件,这个文件记录了mysql所有的增、删、改语句。通过binlog日志我们可以做数据恢复,做主从复制等等。可以看到,只要有了这个binlog,我们就拥有了mysql的完整备份了。
今天查看两个月前上线的小项目,发现运行非常慢,而且增删改查失效了(吓我一大跳),急急忙忙的就开始了我的线上问题排查之路。
爱可生交付服务部团队 DBA 擅长日志分析、问题排查等;主要负责处理 MySQL 与我司自研数据库自动化管理平台 DMP 的日常运维问题,对数据库及周边技术有浓厚的学习兴趣。
上午同事反应MySQL连不上了,我到服务器上用"df -h"查一下磁盘,发现磁盘打满了。解决顺便记录一下流程:
修改/etc/my.cnf 添加一项代码 sql-mode=”STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER” 重启服务 systemctl restart mysqld
大家当年在学MySQL的时候,为了能够迅速就业,一般是学习一下MySQL的基本语法,差不多就出山找工作了。水平稍微好一点的童鞋呢还会懂一点存储过程的编写,又或者是懂一点索引的创建和使用。但是呢,基本上大家都忽略了对底层知识的学习。为什么呢?因为工作中很少用到嘛。然后呢,市面上流传的大部分这种底层的知识,又比较偏运维,研发懂这么多意义也不是太大,很多知识可能这辈子都不会用到。 因此,我整理了一部分相关的知识,希望大家有所收获。
一次意外让我有幸了解了binlog,我无意间将某个库的数据都清空了,当时差点没喘过气来,然后经过一晚上的抢救,把这个经验留下。
在任何一种数据库中,都会有各种各样的日志,记录着数据库工作的方方面面,以帮助数据库管理
近段时间一直在研究mysql的日志系统,在网上看了N多mysql日志操作的文章,但都过于零乱,为了让自己以后不再搞忘,特作出以下总结:
https://segmentfault.com/a/1190000041758784
MySQL备份一般采用全库备份加日志备份的方式,根据业务的需要,可以采用每周日凌晨1点进行完全备份以及每小时进行一次增量备份,这样在MySQL故障后可以使用完全备份和日志备份尽可能的去恢复最完整的数据。 一、binlog日志恢复 MySQL的二进制日志记录着该数据库所有增删改的操作日志(前提是需要自己开启binlog),还包括了这些操作的执行时间,binlog的使用场景无外乎就是主从同步以及恢复数据库。开启binlog功能,需要编辑MySQL的主配置文件,如下: 1、查看二进制功能是否开启(如下,值为OFF,则表示未开启):
本文主要是介绍在centos上搭建mysql的主从服务器。如果没有搭建过的,可以查看我以前的博客,里面有详细的安装centos和在centos上安装mysql的说明。
MySQL的二进制日志binlog可以说是MySQL最重要的日志,它记录了所有的DDL和DML语句(除了数据查询语句select),以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的。一般来说开启binlog日志大概会有1%的性能损耗。
max_connections:允许客户端并发连接的最大数量,默认值是151,一般将该参数设置为500-2000 max_connect_errors:如果客户端尝试连接的错误数量超过这个参数设置的值,则服务器不再接受新的客户端连接。可以通过清空主机的缓存来解除服务器的这种阻止新连接的状态,通过FLUSH HOSTS或MySQLadmin flush-hosts命令来清空缓存。这个参数的默认值是100,一般将该参数设置为100000。
MySQL 中的日志比较重要的有 binlog(归档日志)、redo log(重做日志)以及 undo log,那么跟我们本文相关的主要是 binlog,另外两个日志松哥将来有空了再和大家详细介绍。 1. binlog binlog 我们中文一般称作归档日志,如果大家看过松哥之前发的 MySQL 主从搭建,应该对这个日志有印象,当我们搭建 MySQL 主从的时候就离不开 binlog(传送门:MySQL8 主从复制踩坑指南)。 binlog 是 MySQL Server 层的日志,而不是存储引擎自带的日志,
binlog 就是binary log,二进制日志文件,这个文件记录了MySQL所有的DML操作。通过binlog日志我们可以做数据恢复,增量备份,主主复制和主从复制等等。对于开发者可能对binlog并不怎么关注,但是对于运维或者架构人员来讲是非常重要的。
Elasticsearch设计的理念就是分布式搜索引擎,底层其实还是基于lucene的。核心思想是在多台机器上启动多个ES进程实例,组成了一个ES集群。ES中存储数据的基本单位是索引,如要在ES中存储一些订单数据,就应该在ES中创建一个索引,order_idx,所有的订单数据就都写到这个索引里面去,一个索引差不多就是相当于是mysql里的一张表。ES的层级如下:index -> type -> mapping -> document -> field。
binlog中可以不记录执行的sql语句的上下文相关的信息,仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题
在上一篇文章中,我们从一个查询语句的执行流程知道了 MySQL 架构可分为 Server 层和存储引擎层,以及各个层级的具体部件。
Innodb存储引擎是以页为单位来管理存储空间的。在真正访问页面之前,需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据,然后缓冲池中的脏页会以一定的频率被刷入磁盘(Check Point机制),通过缓冲池来优化CPU和磁盘之间的鸿沟,这样就可以保证整体的性能不会下降太快。
ACSR(Auto Crash Safey Recovery)自动的故障安全恢复 更新操作 在一行数据被更新时: 1、在使用BEGIN开启事务时,会先给.ibd文件中分配一个TXID号和LSN号,假设为tx_01与lsn1001; 2、在UPDATE执行时,MySQL会找到需更新数据的数据页,并将其内容加载到data buffer pool中,由DBWR(double write)线程记录变更数据页的内容,并且记录好TXID和更新LSN号,此时将产生脏页与脏数据; 3、使用LOGBWR(log doubl
我们常常听人说,只要你愿意,MySQL 可以恢复至半个月甚至一个月以内的任何一个状态。网上也有很多删库跑路的段子。。。
请读者注意:本文基于 GreatSQL 8.0.25 & MySQL 5.7.7-RC版本,在 MySQL8.0.30 Redo 发生变化,详情见: MySQL 8.0.30动态redo log初探
在 MySQL 系统中,有着诸多不同类型的日志。各种日志都有着自己的用途,通过分析日志,我们可以优化数据库性能,排除故障,甚至能够还原数据。这些不同类型的日志有助于我们更清晰的了解数据库,在日常学习及运维过程中也会和这些日志打交道。本节内容将带你了解 MySQL 数据库中几种常用日志的作用及管理方法。
linux 里面,有一个log 文件,是一直在增加,现在需要写一个定时,清空这个文件里面的东西,紧紧是清空,每10秒进行清空
主从复制的原理: 分为同步复制和异步复制,实际复制架构中大部分为异步复制。 复制的基本过程如下: 1).Slave上面的IO进程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 2).Master接收到来自Slave的IO进程的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置; 3).
在[mysqld]节点下添加:然后重启服务:service mysql restart
1).Slave上面的IO进程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
比如你redis整个挂了,然后redis就不可用了,你要做的事情是让redis变得可用,尽快变得可用
Redo日志可以说是关系型数据库的精髓之一,GreatSQL技术社群的这篇文章《图文结合带你搞懂MySQL日志之Redo Log(重做日志)》,作了全面讲解。
这条命令是查询自"/"根目录下所有大小超过1G的文件,查询的大小可以根据需要改变,如下:
以社交平台的用户表为例,随着业务的快速增长,用户表user单表数据量越来越大,此时,如果我们想给user表添加索引,数据规模对添加过程的影响势必要考虑在内,但是,单表数据规模对添加索引会产生什么样的影响呢,我们在什么样的数据库请求状态下给大表添加索引比较好呢?
日志实在是太有用了,它记录了程序运行时各种信息。通过日志可以分析用户行为,记录运行轨迹,查找程序问题。可惜磁盘的空间是有限的,就像飞机里的黑匣子,记录的信息再重要也只能记录最后一段时间发生的事。为了节省空间和整理方便,日志文件经常需要按时间或大小等维度分成多份,删除时间久远的日志文件。这就是通常说的日志滚动(log rotation)。
MySQL是一个广泛使用的开源关系型数据库管理系统,它提供了许多强大的功能,如事务、存储过程、触发器、视图、全文索引等。但是,MySQL也有一些不足之处,比如数据的安全性和可靠性。如果数据库发生故障或损坏,如何恢复数据?如果数据库需要进行主从复制或读写分离,如何保证数据的一致性?这些问题都需要借助一个特殊的机制来解决,那就是binlog。
最近遇到mysql开启gtid做复制时,主从同步断开,从库出现1236错误,导致同步无法进行,本文就这问题记录下处理步骤
redis 的持久化有哪几种方式?不同的持久化机制都有什么优缺点?持久化机制具体底层是如何实现的?
MySQL主从介绍 MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后,在A上写数据,另外一台B也会跟着写数据,两者数据实时同步的 MySQL主从是基于binlog的,主上须开启binlog才能进行主从。 主从过程大致有3个步骤 1)主将更改操作记录到binlog里 2)从将主的binlog事件(sql语句)同步到从本机上并记录在relaylog里 3)从根据relaylog里面的sql语句按顺序执行 主上有一个log dump线程,用来和从的I/O线程传递b
1、 docker pull mysql:5.7 mkdir -p /mysql/data mkdir -p /mysql/conf mkdir -p /mysql/log chmod 777 -R /mysql/log chmod 777 -R /mysql/data
使用数据库的时候,我们每个操作都十分小心,尤其是不能直接在数据库上执行 update、delete 等操作,否则万一忘记加全 where 条件,可能就会造成无法挽回的结果。 有一句十分流行的调侃 — “从删库到跑路”就很形象的说明了误操作后的结果,那么如果你真的不小心执行了删库操作,真的就无法挽回了吗? 当然不会了,通常对于线上数据库,我们都会定时冷备,dump 导出数据库的全量备份,并且保留一段时间内的所有修改日志,进而实现在必要时回滚到这段时间内的任何一秒。 这里提到的“日志”指的就是 binlog,那么究竟什么是 binlog 呢?本文我们就来详细介绍一下。
领取专属 10元无门槛券
手把手带您无忧上云