系统日志

一、Oracle体系结构 数据库的体系结构是指数据库的组成、工作过程、以及数据库中数据的组织与管理机制，要了解Oracle数据库的体系结构，必须理解Oracle系统的主要组件和重要概念。 1、Oracle体系结构概述 Oracle体系结构包含一系列组件，如下图所示，图中显示了Oracle体系结构中的主要组件，包括实例、用户进程、服务器进程、数据文件及其他文件，如参数文件、口令文件和归档日志文件等。从图中可以看出，实例和数据库是Oracle数据库体系结构的核心组成部分，也是最重要的两个概念；DBA一个很重要的工作就是维护实例和数据库本身的正常工作。 1）实例 Oracle实例是后台进程和内存结构的集合，必须启动实例才能访问数据库中的数据。Oracle实例启动时，将分配一个系统全局区（SGA）并启动一系列Oracle后台进程。Oracle实例有两种类型：单进程实例和多进程实例，单进程Oracle实例使用一个进程执行Oracle的全部操作，在单进程环境下的Oracle实例仅允许一个用户可存取；多进程Oracle实例（又称多用户Oracle）使用多个进程来执行Oracle的不同部分，对于每个连接的用户都有一个进程。 2）数据库 数据库是数据的集合，物理上指存储数据库信息的一组操作系统文件，每个数据库有一个逻辑结构和物理结构。物理结构是指构成数据库的一组操作系统文件，主要由三种类型文件组成

InnoDB 有两块非常重要的日志，一个是undo log，另外一个是redo log，前者用来保证事务的原子性以及InnoDB的MVCC，后者用来保证事务的持久性。和大多数关系型数据库一样，InnoDB记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL（Write Ahead Log），即在持久化数据文件前，保证之前的redo日志已经写到磁盘 一、概念 1、Innodb Crash Recovery 这是InnoDB引擎的一个特点，当故障发生，重新启服务后，会自动完成恢复操作，将数据库恢复到之前一个正常状态（不需要重做所有的日志，只需要执行上次刷入点之后的日志，这个点就叫做Checkpoint）恢复过程有两步 第一步：检查redo日志，将之前完成并提交的事务全部重做； 第二步：将undo日志中，未完成提交的事务，全部取消 2、LSN LSN(log sequence number) 用于记录日志序号，它是一个不断递增的 unsigned long long 类型整数。 在 InnoDB 的日志系统中，LSN 无处不在，它既用于表示修改脏页时的日志序号，也用于记录checkpoint，通过LSN，可以具体的定位到其在redo log文件中的位置。 LSN 用字节偏移量来表示。每个page有LSN，redo log也有LSN，Checkpoint也有LSN

最全列表： 80 多个 Linux 系统管理员必备的监控工具 https://linux.cn/article-6987-1.html 作者： Jonathan Sundqvist 译者： LCTT struggling | 2016-02-07 23:43 评论: 5 收藏: 26 随着互联网行业的不断发展，各种监控工具多得不可胜数。这里列出网上最全的监控工具。让你可以拥有超过80种方式来管理你的机器。在本文中，我们主要包括以下方面： 命令行工具 网络相关内容 系统相关的监控工具 日志监控工具 基础设施监控工具 监控和调试性能问题是一个艰巨的任务，但用对了正确的工具有时也是很容易的。下面是一些你可能听说过的工具，也有可能没有听说过——何不赶快开始试试？ 八大系统监控工具 1. top 这是一个被预装在许多 UNIX 系统中的小工具。当你想要查看在系统中运行的进程或线程时：top 是一个很好的工具。你可以对这些进程以不同的方式进行排序，默认是以 CPU 进行排序的。 2. htop htop 实质上是 top 的一个增强版本。它更容易对进程排序。它看起来上更容易理解，并且已经内建了许多通用操作。它也是完全交互式的。 3. atop atop 和 top，htop 非常相似，它也能监控所有进程，但不同于 top 和 htop 的是，它可以按日记录进程的日志供以后分析

https://blog.51cto.com/xuegod/2304176 本节所讲内容： - 16.1 计划任务-at-cron-计划任务使用方法 - 16.2 日志的种类和记录的方式-自定义ssh服务日志类型和存储位置 - 16.3 实战-日志切割-搭建远程日志收集服务器 - 16.4 实战-配置公司内网服务器每天定时自动开关机 - 16.1 计划任务-at-cron-计划任务使用方法 大家平常都会有一些比如说：你每天固定几点起床？每天按时上班打卡、每月15号准时开工资、每年2月14你俩口子某某纪念日等这些诸如此类，这些都是定时发生的。或者说是通俗点说：例行公事；还比如说我们还会遇到一些突发事件，临时几点过来加个班？刚好晚上几点聚个餐？ 像上面这些情况，如果事少的话你大脑可以记住，如果事很多，像老板经理董事长每天的工作安排，通常都是记在一些本上，或者闹铃提醒等。 那么，咱们的LINUX系统和上面的情况也很类似，我们也可以通过一些设置。来让电脑定时提醒我们该做什么事了。或者我们提前设置好，告诉电脑你几点做什么几点做什么，这种我们就叫它定时任务。而遇到一些需要执行的事情或任务。我们也可以通过命令来告诉电脑一会临时把这个工作给做一下 总结：在我们LINUX中，我们可以通过crontab和at这两个东西来实现这些功能的 计划任务的作用：是做一些周期性的任务

本文概要 本文分两部分， 第一部分概念介绍，重在理解。 第二部分通过MySQL Innodb中的具体实现，加深相关知识的印象。 本文的原意是一篇个人学习笔记，为了避免成为草草记录一下的流水账，尝试从给人介绍的角度开写。但在整理的过程中，越来越感觉力不从心，一是细节太多了，原以为足够了解的一个小知识点下可能隐藏了很多细节；二是内容与范围的取舍，既想有点技术性避免空谈，又不想陷入枯燥冗长的小细节描述。几番折腾，目前的想法把坑填上，能写完就不错了，你读起来有不顺或错误的地方请见谅，欢迎反馈。 1. 概念与理解 Redo与undo并非是相互的逆操作，而是能配合起来使用的两种机制。 说是两种机制，其实都是日志记录，不同的是redo记录以顺序附加的形式记录新值，如某条记录<T,X,V>，表示事物T将新值V存储到 数据库 元素X，新值可以保证重做； 而Undo记录通常以随机操作的形式记录旧值，如某条记录<T1,Y,9>，表示事物T1对Y进行了修改，修改前Y的值是9，旧值能用于撤销，也能供其他事务读取。 Redo用来保证事务的原子性和持久性，Undo能保证事务的一致性，两者也是系统恢复的基础前提。 1.1 Redo 一个事务从开始到结束，要么提交完成，要么中止，具有原子性。而反映在redo日志中可能需要若干条记录来保证，如： <T0 start> <T0,A,500> <T0,B,500> <T0

历史上， Linux 的启动 一直采用 init 进程。 下面的命令用来启动服务。 $ sudo /etc/init.d/apache2 start # 或者 $ service apache2 start 这种方法有两个缺点。 一是启动时间长。 init 进程是串行启动，只有前一个进程启动完，才会启动下一个进程。 二是启动脚本复杂。 init 进程只是执行启动脚本，不管其他事情。脚本需要自己处理各种情况，这往往使得脚本变得很长。 二、Systemd 概述 Systemd 就是为了解决这些问题而诞生的。它的设计目标是，为系统的启动和管理提供一套完整的解决方案。 根据 Linux 惯例，字母 d 是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就是它要守护整个系统。 使用了 Systemd，就不需要再用 init 了。Systemd 取代了 initd ，成为系统的第一个进程（PID 等于 1），其他进程都是它的子进程。 $ systemctl --version 上面的命令查看 Systemd 的版本。 Systemd 的优点是功能强大，使用方便，缺点是体系庞大，非常复杂。事实上，现在还有很多人反对使用 Systemd，理由就是它过于复杂，与操作系统的其他部分强耦合，违反"keep simple, keep stupid"的 Unix 哲学 。 （上图为

Flume是一个分布式、可靠、和高可用的海量日志采集、聚和和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据。同时，Flume提供对数据进行简单处理，并写到各种数据接收方(比如文本、HDFS、Hbase等)的能力。 Flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source生成，当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。 Flume运行的核心是Agent。Flume以Agent为最小的独立运行单位。一个agent就是一个JVM。它是一个完整的数据采集工具，含有三个核心组件，分别是Source、Channel、Sink。 来源： CSDN 作者： DimplesDimples. 链接： https://blog.csdn.net/Betty_betty_betty/article/details/103799756

最近在考虑后端日志规范拟定，参考了一些别的同志的经验，加上自己的一些思考，初步整理如下。 一、日志规范 1. 日志严格分级 DEBUG：该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。可以将各类详细信息记录到DEBUG里，起到调试的作用，包括 参数信息、调试细节信息、返回值信息 等。 INFO：该种日志记录系统的正常运行状态，通过查看INFO级别的日志，可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。可以将 初始化系统配置、业务状态变化信息 ，或者 用户业务流程中的核心处理记录 到INFO日志中，方便日常运维工作以及错误回溯时上下文场景复现。 WARN：该日志表示 系统可能出现问题 ，也可能没有。 ERROR： 该级别的错误也需要马上被处理 ，但是紧急程度要低于FATAL级别。ERROR应该尽量详细记录。 FATAL： 需要立即被处理的系统级错误 。系统需要将错误相关痕迹以及错误细节记录FATAL日志中，方便后续人工回溯解决。 必须严格按照日志的级别给出日志。 2. 日志记录时机 a) 程序设计语言异常位置 ：C++提示异常的位置。结合实际业务使用 WARN及以上级别 日志。 b) 业务流程与预期不符 ：如外部参数不正确等问题，取决于开发人员的经验。结合实际业务，使用 WARN和ERROR级别 日志。 c) 系统核心角色，组件关键动作

来自：http://www.osyunwei.com/archives/7269.html,改版 mysql主从复制 本文采用的是 centos6.5+mysql-5.6.23版本 之前在 windows7安装过主从复制,现在在linux实现主从复制 mysql安装方法: http://www.cnblogs.com/lin3615/p/4376224.html 配置: 配置MySQL主服务器（192.168.179.142) 从服务器两台(192.168.179.146,192.168.179.147) 数据库就以 test为例, // 从这里开始配置第一台从服务器 #建立一个MySQL主从数据库同步用户 lin3615,密码123456,并授予给192.168.179.146 登陆数据库，进入控制台 insert into mysql.user(Host,User,Password,ssl_cipher,x509_issuer,x509_subject) values('%','lin3615',password('123456'),'','',''); #刷新系统授权表 flush privileges; #授权用户lin3615 只能从 192.168.179.146 这个IP访问主服务器192.168.179.142上面的数据库 grant replication

1. MySQL 优化 - 查看执行记录 MySQL 提供了一个 EXPLAIN 命令 , 它可以 对 SELECT 语句进行分析 , 并输出 SELECT 执行的详细信息 , 以供开发人员针对性优化。 使用 explain 这个命令来查看一个这些 SQL 语句的执行计划，查看该 SQL 语句有没有使用上了索引，有没有做全表扫描，这都可以通过 explain 命令来查看。 EXPLAIN 命令用法十分简单 , 在 SELECT 语句前加上 explain 就可以了 , 例如 : 1.1 SQL 语句优化 -explain 分析问题 expain 出来的信息有 10 列，分别是 id 、 select_type 、 table 、 type 、 possible_keys 、 key 、 key_len 、 ref 、 rows 、 Extra , 下面对这些字段进行解释： id: select 查询的标识符 . 每个 select 都会自动分配一个唯一的标识符 . select_type: 表示查询的类型。 table: 输出结果集的表 type: 表示表的连接类型 possible_keys: 表示查询时，可能使用的索引 key: 表示实际使用的索引 key_len: 索引字段的长度 ref: 哪个字段或常数与 key 一起被使用 rows: 扫描出的行数 ( 估算的行数 )