log文件

11.25 事物隔离级别 事物日志redo undo 事物锁 begin; update 事物日志性能优化 innodb_flush_log_at_trx_commit=0|1|2|3 innodb事务日志相关配置； show variables like '%innodb_log%'; 通用日志 通用日志：记录对数据库的通用操作，包括错误的SQL语句 通用日志可以保存在：file（默认值）或 table 通用日志相关设置 general_log=ON|OFF general_log_file=HOSTNAME.log log_output=TABLE|FILE|NONE 慢查询（重点） slow_query_log=on|off show profile for query 2; long_query_time=N; set global log_queries_not_using_indexes=ON; 二进制日志（重点） 记录导致数据改变或潜在导致数据改变的SQL语句 记录已提交的日志 不依赖于存储引擎类型 功能：通过“重放”日志文件中的事件来生成数据副本 注意：建议二进制日志和数据文件分开存放 二进制日志记录三种格式； 基于“语句”记录：statement，记录语句，默认模式 基于“行”记录：row，记录数据，日志量较大 （可恢复数据） 混合模式：mixed,

[root@localhost ~]# rpm -qa|grep lsof lsof-4.82-4.el6.x86_64 在终端下输入lsof即可显示系统打开的文件，因为 lsof 需要访问核心内存和各种文件，所以必须以 root 用户的身份运行它才能够充分地发挥其功能。每行显示一个打开的文件，若不指定条件默认将显示所有进程打开的所有文件。 lsof - list open files Lsof revision 4.82 lists on its standard output file information about files opened by processes for the following UNIX dialects: AIX 5.3 Apple Darwin 9 (Mac OS X 10.5) FreeBSD 4.9 for x86-based systems FreeBSD 7.[012] and 8.0 for AMD64-based systems Linux 2.1.72 and above for x86-based systems Solaris 9 and 10 An open file may be a regular file, a directory, a block special file, a character special

1、首先登陆mysql并查看 mysql> show variables like '%log_bin%'; +---------------------------------+-------+ | Variable_name | Value | +---------------------------------+-------+ | log_bin | OFF | | log_bin_basename | | | log_bin_index | | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | sql_log_bin | ON | +---------------------------------+-------+ 6 rows in set (0.00 sec) log_bin状态未开启 2、退出MySql 修改mysql配置文件my.cnf 添加如下两行： server-id=1 log-bin=/var/lib/mysql/mysql-bin 保存并退出 3、重起mysql 服务 systemctl restart mysqld.service 4、登陆MySql并查看 mysql> show variables like '%log_bin%'; +--

MySQL 主主同步方案 l MySQL 主主 +Keepalived l MySQL+DRBD+Heartbeat 在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用 mysql 主 主 方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加 mysql 入口，增加高可用。 不过多主需要考虑自增长 ID 问题，这个需要特别设置配置文件，比如双主，可以使用奇偶 ，总之，主之间设置自增长 ID 相互不冲突就能完美解决自增长 ID 冲突问题。 主主方案实现思路 1、 两台 mysql 都可读写，互为主备 。 默认只使用一台 masterA 负责数据的写入，另一台 masterB 备用 处于备用状态 ； 2、 masterA 是 masterB 的主库， masterB 又是 masterA 的主库，它们互为主从； 3、 两台主库之间做高可用 , 可以采用 keepalived 等方案 ， 使用 VIP 对外提供服务； 4、 所有提供服务的从服务器与 masterB 进行主从同步（双主多从） ; 5、 建议采用高可用策略的时候， masterA 或 masterB 均不因宕机恢复后而抢占 VIP （非抢占模式）； 这样做可以在一定程度上保证主库的高可用 , 在一台主库 down 掉之后 ,

作者：antwang juejin.im/post/5aa09bb3f265da238f121b6c 前言 Nginx日志对于统计、系统服务排错很有用。 Nginx日志主要分为两种： access_log(访问日志)和error_log(错误日志)。通过访问日志我们可以得到用户的IP地址、浏览器的信息，请求的处理时间等信息。错误日志记录了访问出错的信息，可以帮助我们定位错误的原因。 本文将详细描述一下如何配置Nginx日志。 设置access_log 访问日志主要记录客户端的请求。客户端向Nginx服务器发起的每一次请求都记录在这里。客户端IP，浏览器信息，referer，请求处理时间，请求URL等都可以在访问日志中得到。当然具体要记录哪些信息，你可以通过log_format指令定义。 语法 access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]]; # 设置访问日志 access_log off; # 关闭访问日志 path 指定日志的存放位置。 format 指定日志的格式。默认使用预定义的combined。 buffer 用来指定日志写入时的缓存大小。默认是64k。 gzip 日志写入前先进行压缩。压缩率可以指定，从1到9数值越大压缩比越高，同时压缩的速度也越慢。默认是1

在看Mysql相关内容的时候经常听到两阶段提交，那以前都是云里雾里的，通过学习丁奇老师的这篇文章彻底明白了其流程和含义。 提到两阶段提交，必须先说一下两个日志: redo log 和 binlog 重要的日志模块：redo log 数据在磁盘中是按照主键顺序存储的，在对数据进行更新操作(insert、update、delete)的时候，既要写数据又可能对其他数据进行移动，如果每次都写进磁盘是很耗性能的。 redo log 这里就用到的WAL技术，WAL的全称是 Write-Ahead Logging ，它的关键点是先写日志再写磁盘，并且 写日志是顺序写 速度很快。 具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log ,并更新内存，这个时候更新就算是完成了。同时Innodb引擎会在适当的时候讲这个操作更新到磁盘里面。 Innodeb的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB,那么总共可以记录4GB的操作，从头开始写，写到末尾就又会到开始循环。当然当大小不够的时候会讲数据刷新到磁盘(数据文件内)。 有了 redo log Innodb 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe . 重要的日志模块：binlog 前面提到的 redo log

Harbor 是什么 Harbor是VMware公司开源的企业级DockerRegistry项目，其目标是帮助用户迅速搭建一个企业级的Dockerregistry服务。 它以Docker公司开源的registry为基础，提供了管理UI，基于角色的访问控制(Role Based Access Control)，AD/LDAP集成、以及审计日志(Auditlogging) 等企业用户需求的功能，同时还原生支持中文。 简单说来，Harbor封装了Docker的registry v2，帮用户提供了许多便捷管理的特性，方便用户操作。 Harbor提供的特性 基于角色控制 用户和仓库都是基于项目进行组织的， 而用户基于项目可以拥有不同的权限。 基于镜像的复制策略 镜像可以在多个Harbor实例之间进行复制。 支持LDAP Harbor的用户授权可以使用已经存在LDAP用户。 镜像删除 & 垃圾回收 Image可以被删除并且回收Image占用的空间。 友好UI 用户可以轻松的浏览、搜索镜像仓库以及对项目进行管理。 便于扩展 绝大部分的用户操作API， 方便用户对系统进行扩展。 轻松部署 Harbor提供了online、offline安装，除此之外还提供了virtualappliance安装。 Harbor的安装与配置 Harbor的 github主页 上已经讲得很详细了，在此不再赘述。

一、背景： 由于阿里云RDS生产库每天都需要备份且拷贝到自建读库，而如果使用阿里云的自动拷贝到只读实例， 费用太高， 故采用自编写同步脚本方法实现。 二、前提： 1). 已开通阿里云RDS， 且开启定期备份功能。（备份功能生成备份文件供下载） 2). 已在备份的目标服务器上安装mysql数据库。 3). 备份目标服务器已安装数据恢复工具Percona XtraBackup，您可以从Percona XtraBackup官网下载安装。 MySQL 5.6及之前的版本需要安装 Percona XtraBackup 2.3，安装指导请参见官方文档 Percona XtraBackup 2.3 。 MySQL 5.7版本需要安装 Percona XtraBackup 2.4，安装指导请参见官方文档 Percona XtraBackup 2.4 。 MySQL 8.0版本需要安装 Percona XtraBackup 8.0，安装指导请参见官方文档 Percona XtraBackup 8.0 。 三、脚本编写和测试 1. 编写SHELL脚本 #!/usr/bin/env bash #########数据库基础信息############# #输入参数 URL_PATH=$1 #定义时间格式 DATE=`date +%Y%m%d%H%M%S` #日志记录文件地址 LOG_PATH=/data

方法1： SET GLOBAL general_log = 'OFF'; RENAME TABLE mysql.general_log TO mysql.general_log2; DELETE FROM mysql.general_log2; 注意：当DELETE FROM mysql.general_log2执行删除表数据时，发现操作系统的数据文件还是存在的，需要手动删除该数据文件，再继续下面数据操作步骤 OPTIMIZE TABLE general_log2; RENAME TABLE mysql.general_log2 TO mysql.general_log; SET GLOBAL general_log = 'ON'; 这种方法需要的时间比较长 方法2： SET GLOBAL general_log = 'OFF'; 找到general_log的文件 执行 cat /dev/null > general_log.csv 发现也将大小释放了，比上一个快很多 方法3： 可以在配置文件my.conf 中添加： general_log=1 general_log_file='/data/mysql/general_log.CSV' 将文件放到更大的磁盘 来源： https://www.cnblogs.com/lixiaobao/p/11691172.html

在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用 mysql 主 主 方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加 mysql 入口，增加高可用。 不过多主需要考虑自增长 ID 问题，这个需要特别设置配置文件，比如双主，可以使用奇偶 ， 总之，主之间设置自增长 ID 相互不冲突就能完美解决自增长 ID 冲突问题 主主方案实现思路 1、 两台 mysql 都可读写，互为主备 。 默认只使用一台 masterA 负责数据的写入，另一台 masterB 备用 处于备用状态 ； 2、 masterA 是 masterB 的主库， masterB 又是 masterA 的主库，它们互为主从； 3、 两台主库之间做高可用 , 可以采用 keepalived 等方案 ， 使用 VIP 对外提供服务； 4 、 所有提供服务的从服务器与 masterB 进行主从同步（双主多从） ; 5 、 建议采用高可用策略的时候， masterA 或 masterB 均不因宕机恢复后而抢占 VIP （非抢占模式）； 这样做可以在一定程度上保证主库的高可用 , 在一台主库 down 掉之后 , 可以在极短的时间内切换到另一台主库上 ， 尽可能减少主库宕机对业务造成的影响，减少了主从同步给 生产 主库带来的压力； 实验步骤：