log文件

并发控制 锁粒度： 表级锁 行级锁 锁： 读锁：共享锁，只读不可写（包括 自己当前用户 和当前事务） ，多个读互不阻塞 写锁：独占锁，排它锁，写锁会阻塞其它事务（不包括当前事务）的读和它锁 实现 存储引擎：自行实现其锁策略和锁粒度 服务器级：实现了锁，表级锁，用户可显式请求 分类： 隐式锁：由存储引擎自动施加锁 显式锁：用户手动请求 锁策略：在锁粒度及数据安全性寻求的平衡机制 显式使用锁 LOCK TABLES 加锁 lock tables tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... lock_type: READ ,WRITE UNLOCK TABLES 解锁 FLUSH TABLES [tb_name[,...]] [WITH READ LOCK] 关闭所有正在打开的表，同时清除掉查询缓存以及准备好的语句缓存， 如果加上with read lock 选项的话，它代表关闭所有正在打开的表并加上全局锁（不清除缓存了）， 通常在备份前加全局读锁 SELECT clause [FOR UPDATE | LOCK IN SHARE MODE] 查询时加写或读锁 注意点1（加锁）： 注意，读锁加到表上之后，此表将只能读，不能进行其他任何操作。

一、使用LogStash 在项目中添加Gradle依赖，然后Sync项目： "net.logstash.logback:logstash-logback-encoder:4.11", 或者使用Maven： <!-- https://mvnrepository.com/artifact/net.logstash.logback/logstash-logback-encoder --> <dependency> <groupId>net.logstash.logback</groupId> <artifactId>logstash-logback-encoder</artifactId> <version>4.11</version> </dependency> 然后添加配置文件： <?xml version="1.0" encoding="UTF-8"?> <configuration> <contextName>${HOSTNAME}</contextName> <property name="LOG_PATH" value="/var/log" /> <springProperty scope="context" name="appName" source="spring.application.name" /> <springProperty scope="context"

一、说说前因后果 elasticsearch,kafka,zookeeper,kibana,elasticsearch-head,logstash，logstash是需要经常重启的，你上了点过滤规则或者修改点啥的，每次都尼玛杀进程，再nohup ，还看不到日志，这太不符合人性了，人性的优点之一就是懒惰。打开web 界面，点一下鼠标解决问题岂不是棒棒哒，还能通过web 界面看看后台日志，故而用supervisor托管 supervisor运行的系统：centos 7 supervisor version：3.3.4 二、安装 用easy_install 安装pip easy_install pip #之后通过pip 安装supervisor pip install supervisor #为supervisor创建工作目录与配置文件目录并且赋予该目录755 的权限； mkdir -m 755 -p /etc/supervisor/conf.d #通过supervisor 提供的 echo_supervisord_conf 命令生成默认配置文件 echo_supervisord_conf > /etc/supervisor/supervisord.conf #通过cat 命令查看配置文件是否生成； cat /etc/supervisor/supervisord.conf |grep

一、说说前因后果 elasticsearch,kafka,zookeeper,kibana,elasticsearch-head,logstash，logstash是需要经常重启的，你上了点过滤规则或者修改点啥的，每次都尼玛杀进程，再nohup ，还看不到日志，这太不符合人性了，人性的优点之一就是懒惰。打开web 界面，点一下鼠标解决问题岂不是棒棒哒，还能通过web 界面看看后台日志，故而用supervisor托管 supervisor运行的系统：centos 7 supervisor version：3.3.4 二、安装 用easy_install 安装pip easy_install pip #之后通过pip 安装supervisor pip install supervisor #为supervisor创建工作目录与配置文件目录并且赋予该目录755 的权限； mkdir -m 755 -p /etc/supervisor/conf.d #通过supervisor 提供的 echo_supervisord_conf 命令生成默认配置文件 echo_supervisord_conf > /etc/supervisor/supervisord.conf #通过cat 命令查看配置文件是否生成； cat /etc/supervisor/supervisord.conf |grep

1. httpd简介 httpd是Apache的超文本传输​​协议（HTTP）服务器的主程序。被设计为一个独立运行的后台进程，它会建立一个处理请求的子进程或线程的池。 通常，httpd的不应该被直接调用，而应该在类Unix的系统中由的apachectl调用，在Windows中作为服务运行。 2. httpd版本 本文主要介绍的httpd的两大版本，httpd-2.2和httpd-2.4。 CentOS6系列的版本默认提供的是的httpd-2.2版本的rpm包 CentOS7系列的版本默认提供的是的httpd-2.4版本的rpm包 2.1 httpd的特性 httpd的有很多特性，下面就分别来说说的httpd-2.2版本和的httpd-2.4版本各自的特性。 httpd-2.2的特性 事先创建进程 按需维持适当的进程 模块化设计，核心比较小，各种功能通过模块添加（包括PHP），支持运行时配置，支持单独编译模块 支持多种方式的虚拟主机配置，如基于ip的虚拟主机，基于端口的虚拟主机，基于域名的虚拟主机等 支持https协议（通过mod_ssl模块实现） 支持用户认证 支持基于IP或域名的ACL访问控制机制 支持每目录的访问控制（用户访问默认主页时不需要提供用户名和密码，但是用户访问某特定目录时 需要提供用户名和密码） 支持URL重写 支持MPM（Multi Path Modules

问题原因 想要了解这个问题的原因在于有一次面试的时候，面试官问我一个问题，就是MySQL的双主复制的时候是如何避免回环复制这个问题的，说老实话在基于GTID复制的时候我还是比较了解的，因为GTID复制是MySQL本身是不会执行已经执行过的GTID事务，即使MySQL本身并不会执行已经执行过的GTID事务，但是还是会形成一个回环复制。那么MySQL到底是如何解决回环复制的呢？ 猜想 在我们搭建主从的时候我们可以清楚的知道，要想成功的搭建主从，那么主从的server_id必须不能一模一样的，所以猜想可能是因为server_id的原因。 在MySQL 5.5以及一切，我们搭建一主多从的时候，假如slave使用了相同的server_id就会发现在master和slave上面发现slave会经常的断开重连，这个是因为slave在注册的时候会去比对server_id，假如server_id存在的话则会有一个删除操作，但是MySQL 5.6的版本以后引入了uuid，它会优先去比对uuid，假如不存在的话则会去比对server_id。所以在MySQL5.6以及以后是因为uuid的原因呢。 实验 A. 搭建双主。非gtid模式（具体过程不在描述） master 1 ........ ........ Connect_Retry: 60 Master_Log_File: mysql-bin

实践出真知——部署ELK日志分析系统（提供包） 前言 ​ 前一篇文章介绍了有关ELK日志分析系统的理论原理，本文将结合原理通过案例环境部署及配置ELK日志分析系统。 环境规划 使用集群方式，2个Elasticsearch节点，其中一台安装Kibana即可，另外安装Apache服务作为被监控的服务器，安装Logstash。 相关规划如下表所示： 主机 操作系统 主机名 IP地址 主要安装软件 服务器 Centos7.4 node1 20.0.0.140 Elasticsearch Kibana 服务器 Centos7.4 node2 20.0.0.139 Elasticsearch 服务器 Centos7.4 Apache 20.0.0.141 Logstash Apache 部署流程综述 1、检查服务器环境（推荐先进行时间同步），找到所需软件包 2、在两个elasticsearch节点上部署elasticsearch环境、elasticsearch软件、 3、检查服务是否开启并在浏览器中验证、检查健康状态与查看状态信息 4、在两个elasticsearch节点上安装elasticsearch-head插件（方便查看集群信息） 5、通过浏览器验证、检查健康状态，模拟创建索引来验证信息 6、安装Apache服务在20.0.0.141服务器上，并且安装Logstash软件 7

实验步骤 控制文件是一个二进制文件，为了查看其内容，我们可以通过oracle命令转储出来进行查看（以下命令来自oracle 19c）： SQL> alter session set events 'immediate trace name controlf level 8'; Session altered. SQL> select value from v$diag_info where name='Default Trace File'; VALUE -------------------------------------------------------------------------------- /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_13639.trc 解读 19c trace trc 文件头简介 文件头对文件来源做出了简介：包括文件信息、数据库信息、DB版本号、系统信息、实例信息和进程信息 # 文件名 Trace file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_13639.trc ​ # 数据库信息 Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 -

一、MySQL主从原理 1、概念 MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。 2、MySQL主从复制涉及的三个线程 主节点 binary log dump 线程 ：当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。 从节点I/O线程 ：当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。 从节点SQL线程 ：SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。 对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程

harbor特性 1、基于角色的访问控制：用户和存储库是通过“项目”组织的，用户可以对多个镜像仓库统一命名空间拥有不同的权限。 2、镜像复制：可以基于具有多个Registry实例之间复制（同步）图像和图表。如果出现任何错误，Harbor会自动重试复制。非常适合于负载平衡、高可用性、多数据中心、混合和多云场景。 3、LDAP/AD支持：Harbor与现有企业LDAP/AD集成，用于用户身份验证和管理，并支持将LDAP组导入Harbor并为其分配适当的项目角色。 镜像删除和垃圾收集：镜像可以删除，其空间可以回收。 4、国际化：对多国语言支持（已拥有中文、英文、德文、日语和俄文）； 5、图形化用户界面：用户可以轻松浏览、搜索存储库和管理项目。 6、审计管理：跟踪到存储库的所有操作。 7、RESTful API：用于大多数管理操作的RESTful API，易于与外部系统集成。一个嵌入式的Swagger用户界面可用于探索和测试API。 简单部署：提供在线和离线安装程序。此外，可以安装到vSphere平台的(OVA方式)虚拟设备。 Harbor 组件 1、proxy：Harbor的组件，如注册表、UI和令牌服务，都位于反向代理之后。代理将来自浏览器和Docker客户机的请求转发到各种后端服务。 2、Registry：负责存储Docker镜像和处理Docker推/拉命令