使用MYSQL 的DBER们都对大事务和关于BINLOG 的 expire_log_days 或者更新的Binlog_expire_logs_seconds(MYSQL8)
最近遇到一个问题，需要编写相应的Linux命令，增量同步/var/mysql里的所有文件到另外一个目录/opt/mysql，但是里面相关的日志文件xx.log是不同步的，这个场景，可以使用rsync来实现
在MySQL的日常维护中，我们总会遇到这样或那样的问题，对于那些经常发生且有处理经验的事故，不论是新手还是老司机都能在故障规定的容错时间内解决。而对于那些不常见、比较棘手的问题，新手上路可能就显得举足无措了，这个时候新手和老司机的差距就体现出来了。从知识储备还是工作经验，可能老司机比新手强一点，但如果一个新司机没有日志排错的意识，不具备日志排错的经验，那怎么能学会弯道超车、漂移的快感。我们知道数据库中有很多重要的日志，如错误日志error log、慢日志slow log、二进制日志binary log、查询日志general log等等其他日志，错误日志error log是我们分析问题参考的依据，它记录数据库的启动/运行/停止的过程，包含了info、warning、error三个级别，分析error log也有助于我们了解数据库的运行机制。
本文和封面来源：https://www.percona.com/blog，爱可生开源社区翻译。
前几天，一早起来，就发现 RDS 挂了，然后也无法重启，后面发现是 bin-log 日志过大，把 RDS 的空间塞满了。
MySQL中二进制日志功能默认是关闭的，查看各种开启方式后，确定在配置文件中加入如下配置来开启该功能：
该方法可以删除列于索引文件中的所有二进制日志，把二进制日志索引文件重新设置为空，并创建一个新的二进制日志文件mysql-bin.000001。该语法一般只用在主从环境下初次建立复制时。在主从复制进行过程中，该语句是无效的。
前一阵子工作项目上的事情忙的焦头烂额，最近要进行部门调整将要去做新的项目。又要学习很多新的知识了，还是很兴奋激动的。今天下班回来查看了一下VPS状态，发现VPS的空间只剩下了1G多！第一反应是被入侵了，但是看了一下log并没有发现什么异常的登录，加上平时基本都是用私钥免密码登录的VPS，别入侵的可能也不是很大。那我就很疑惑了，因为系统文件占用应该也就3G多，我平时并没有在VPS放过什么大文件，不应该一下子少那么多空间。于是开始一番du查找终于找到了罪魁祸首！原来是mysql的log文件导致的。
修改/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
很多人，这里说的是运维工程师们，一提到写某某方案，很是头疼。不是上某度一统搜索，就是同样一句话在N个群全部群发一遍：“有没有某某方案，可以共享一下的吗？？求助，各位大佬们”，估计十有八九，全部石沉大海，杳无音讯。
使用数据库的时候，我们每个操作都十分小心，尤其是不能直接在数据库上执行 update、delete 等操作，否则万一忘记加全 where 条件，可能就会造成无法挽回的结果。 有一句十分流行的调侃 — “从删库到跑路”就很形象的说明了误操作后的结果，那么如果你真的不小心执行了删库操作，真的就无法挽回了吗？ 当然不会了，通常对于线上数据库，我们都会定时冷备，dump 导出数据库的全量备份，并且保留一段时间内的所有修改日志，进而实现在必要时回滚到这段时间内的任何一秒。 这里提到的“日志”指的就是 binlog，那么究竟什么是 binlog 呢？本文我们就来详细介绍一下。
应用程序通常会使用多个异构数据库，每个数据库都用于服务于特定的需求，例如存储数据的规范形式或提供高级搜索功能。因此，对于应用程序而言，将多个数据库保持同步是非常重要的。我们发现了一系列尝试解决此问题的不同方式，例如双写和分布式事务。然而，这些方法在可行性、稳健性和维护性方面存在局限性。最近出现的一种替代方法是利用变更数据捕获（CDC）框架，从数据库的事务日志中捕获变更的行，并以低延迟将它们传递到下游系统。为了解决数据同步的问题，还需要复制数据库的完整状态，而事务日志通常不包含完整的变更历史记录。同时，某些应用场景要求事务日志事件的高可用性，以使数据库尽可能地保持同步。
主要是解决读数据从Redis缓存，一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
千呼万唤始出来的新版本MySQL 8.1及MySQL 8.0.34于2023年7月18日正式发行。从此，MySQL将开启创新版和稳定版同时发行的阶段。MySQL 8.1是MySQL的首个创新版，该版本主要增加了如下功能 :
filter 是整个mysql 日志处理的核心部分，就是通过它来抓取信息赋给各个filed
MySQL的二进制日志binlog可以说是MySQL最重要的日志，它记录了所有的DDL和DML语句（除了数据查询语句select），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。一般来说开启binlog日志大概会有1%的性能损耗。
类似于电脑,要在朋友的电脑上跑你写的Java程序,就得检查他电脑有没有安装Java环境.
注意事项：日志非准确跨天问题。（我们采用扫描最新一个日志文件没前一天的数据就开始计算）
爱可生南区交付服务部 DBA 团队成员，主要负责 MySQL 故障处理，MySQL 高可用架构改造，OceanBase 相关技术支持。爱好足球，羽毛球。
redo是引擎层的日志，而且是InnoDB特有的。InnoDB的redo log是有固定大小的，比如可以配置为 一组4个文件（logfile-1，logfile-2，logfile-3，logfile-4），每个文件的大小是1GB，那么它总共可以记录4GB的操作。一个环状循环结构，从头开始写，写到末尾又回到开始循环写。
作用： 记录mysql数据库的一般状态信息及报错信息，是我们对于数据库常规报错处理的常用日志。
MySQL 中最简单使用序列的方法就是使用 AUTO_INCREMENT 来定义序列。
导读：Elasticsearch是一个分布式的搜索和分析引擎，可以用于全文检索、结构化检索和分析，并能将这三者结合起来。Elasticsearch基于Lucene开发，现在是使用最广的开源搜索引擎之一。Elasticsearch可以应用于在/离线日志流水、用户标签画像、数据库二级缓存、安全风控行为数据、图数据库索引、监控数据、Wiki文档检索等应用场景。58同城有自己的主搜，而一些内部创新搜索业务和大规模的数据实时OLAP ( On-Line Analytical Processing，联机分析处理 ) 则是使用Elasticsearch。
在配置文件中加入 log-bin 配置，表示启用binlog，如果没有给定值，写成 log-bin=，则默认名称为主机名。（注：名称若带有小数点，则只取第一个小数点· 前的部分作为名称）
innobackupex --user=root --password /fullback
-- 每个表单独文件和单独表空间，而不是放在系统表空间，每个表的文件表空间允许操作系统在表被截断或删除时回收磁盘空间。每表文件表空间还支持动态和压缩行格式以及相关功能
现在MySQL 8和PostgreSQL 10已经发布，现在是重新审视两个主要的开源关系数据库如何相互竞争的好时机。
my.cnf中有两个参数设置： expire_logs_days = 7 #binlog保留时间7天 max_binlog_size = 1G #binlog大小 问题描述：
挺多朋友问我宝塔面板的二进制日志怎么关闭，其实前面介绍过宝塔的二进制日志，因为最开始买的服务器硬盘不够，二进制日志文件生成的文件比较占空间，还导致mysql服务启动不了，最后因此关掉了宝塔的二进制日志，具体可以参见关闭二进制日志文件解决宝塔面板mysql服务无法启动。
log_bin binlog的开关和binlog的前缀
首先会启动一个xtrabackup_log后台检测的进程，实时检测mysql redo的变化，一旦发现redo有新的日志写入，立刻将日志写入到日志文件xtrabackup_log中 复制innodb的数据文件和系统表空间文件idbdata1到对应的以默认时间戳为备份目录的地方 复制结束后，执行flush table with read lock操作 复制.frm .myd .myi文件 并且在这一时刻获得binary log 的位置 将表进行解锁unlock tables 停止xtrabackup_log进程
这篇文章是从Github ReadMe拷贝的，内容实践下载是没问题的，能够正常发送短信，而且也不需要服务器，本地也能跑起来
MySQL 8.0.19引入了无Binlog副本（保留事务提交顺序），这意味着用户可以在不启用二进制日志的情况下部署异步副本，并保留相同的顺序提交事务。用户可以禁用Binlog（skip-log-bin）和回放线程产生的日志（log-slave-updates = FALSE）进行的更改，同时保留相同提交顺序（slave-preserve-commit-order = TRUE）。
MySQL作为蓝鲸平台存取数据的主要数据库，其稳定性关系到蓝鲸平台的使用体验，而其数据安全性则可能关系到企业IT资产相关信息，在安装和维护蓝鲸平台的过程中应引起足够重视。本文将对如下几个出现过的问题进行分析和提供处理建议。这几个问题分别为：升级，配置日志自动清理，binlog手动清理维护，表清空，备份。
使用innobackupex工具进行备份（因本次涉及到的数据库实例较多，所以编写shell脚本，减少出错，单实例同样适用）：
快照（snapshot）是最简单的压缩方式。在快照中，全部的当前系统状态都被写入到快照中，存储到持久化的存储中，然后在那个时刻之前的全部日志都可以被丢弃。
WAL 机制 write ahead log ,在 PG 中是很重要的，关于数据库的安全和性能都会和 WAL 有牵扯。
0：日志每秒刷新，但是在事务提交时不做任何处理，1，每次提交都刷新，这是最安全的也是默认的。2，每次事务提交都把日志缓存写到日志文件，再由innodb每秒做一次刷新。
事情是从公司前段时间的需求说起，大家知道宜信是一家金融科技公司，我们的很多数据与标准互联网企业不同，大致来说就是：
提到事务，你肯定不陌生。在 MySQL中，InnoDB 是支持事务的，事务有4大特性，即 ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）。
之前在 [如何有效排查解决 MySQL 行锁等待超时问题] 文章中介绍了如何监控解决行锁超时报错，当时介绍的监控方案主要是以 shell 脚本 + general_log 来捕获行锁等待信息，后来感觉比较麻烦，因此优化后改成用 Event + Procedure 的方法定时在 MySQl 内执行，将行锁等待信息记录到日志表中，并且加入了 pfs 表中的事务上下文信息，这样可以省去登陆服务器执行脚本与分析 general_log 的过程，更加便捷。
FlinkX是一个基于Flink的批流统一的数据同步工具，既可以采集静态的数据，比如MySQL，HDFS等，也可以采集实时变化的数据，比如MySQL binlog，Kafka等，是全域、异构、批流一体的数据同步引擎，大家如果有兴趣，欢迎来github社区找我们玩~
Prometheus 监控服务（TMP） 1. TMP 和自建有什么区别吗 TMP 完全兼容开源生态，并与腾讯云监控数据打通，帮助用户快速搭建监控体系（自定义监控，组件监控，基础监控等），支持 Grafana 并预设了常用的监控 Dashboard，支持丰富的 Exporter 并预设了常见的告警模板；很好解决了开源社区 Prometheus 高可用搭建困难， Prometheus 性能可扩展性差，运维消耗人力等痛点。 2. TMP 的监控数据是怎么采集的？ 通过 Prometheus agent 拉取
我们都知道，binlog可以说是MySQL中比较重要的日志了，在日常学习及运维过程中，也经常会遇到。不清楚你对binlog了解多少呢？本篇文章将从binlog作用、binlog相关参数、解析binlog内容三个方面带你了解binlog。
前面说了innoDB表在mysql5.6.6之前存储在系统空间，5.6.6之后存储在独立的空间，表结构存储在.frm文件，里面记录着字符集，行规则等，表数据存储在.ibd里面，里面存储着数据和索引。
指定MySQL服务器监听的IP地址，默认为0.0.0.0，表示所有IP地址。可以设置为127.0.0.1来限制只有本地可以访问MySQL服务。
一直以来对于MySQL的binlog日志的统计和分析是工作中的重点内容，因为通过日志量这样一个维度能够反映出数据库的变化情况，但是显然MySQL官方没有好的工具来做这个分析。
在MySQL中，可以通过配置max_binlog_size和expire_logs_days参数来控制二进制日志（binlog）的大小和保留期。但是，要注意的是，max_binlog_size参数设置的是单个binlog文件的最大大小，而不是所有binlog文件的总容量。当binlog文件的大小达到max_binlog_size指定的值时，MySQL会自动创建一个新的binlog文件。
其实XtraBackup也是基于INNODB的 crash-recovery功能来实现的，他是对于数据文件的直接拷贝，为了保证数据内部的一致性，就需要使用到了crash-recovery来确保恢复的数据库是一致性的，而且是可用的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
