log文件

Apache的主要目录和配置文件详解 来源于https://www.cnblogs.com/qianyuliang/p/6831942.html 一、Apache 主要配置文件注释 Apache的主配置文件：/etc/httpd/conf/httpd.conf 默认站点主目录：/var/www/html/ Apache服务器的配置信息全部存储在主配置文件/etc/httpd/conf/httpd.conf中，这个文件中的内容非常多，用wc命令统计一共有1009行，其中大部分是以#开头的注释行。 ServerTokens OS 在出现错误页的时候是否显示服务器操作系统的名称，ServerTokens Prod为不显示 ServerRoot "/etc/httpd" 用于指定Apache的运行目录，服务启动之后自动将目录改变为当前目录，在后面使用到的所有相对路径都是想对这个目录下 User daemon # apache的用户，默认为daemon Group daemon # apache的用户，默认为daemon PidFile run/httpd.pid 记录httpd守护进程的pid号码，这是系统识别一个进程的方法，系统中httpd进程可以有多个，但这个PID对应的进程是其他的父进程 Timeout 60 服务器与客户端断开的时间 KeepAlive Off 是否持续连接

本文引自公司技术文档，仅作为记录。 背景 有的时候需要进行数据库环境的隔离，以及节省服务器资源一台mysql安装多个数据库实例，一个实例下构建多个数据库​ 安装mysql yum -y install ncurses-devel cmake wget gcc gcc-c++ &&cd /usr/local/src && wget http://192.168.1.173:8000/mysql-5.6.23.tar.gz &&groupadd mysql && useradd mysql -g mysql ​在mysql解压包目录下，执行如下编译安装脚本：cd /usr/local/src &&rm -rf mysql-5.6.23 &&tar -zxvf mysql-5.6.23.tar.gz && cd mysql-5.6.23 &&rm -rf /etc/my.cnf /usr/local/mysql &&mkdir -p /usr/local/mysql /usr/local/mysql/mysql_data &&rm -rf CMakeCache.txt &&cmake . \-DCMAKE_INSTALL_PREFIX=/usr/local/mysql \-DMYSQL_DATADIR=/usr/local/mysql/mysql_data \-DDEFAULT

一、MHA 简介 MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案， 它由日本 DeNA 公司的 youshimaton 员工（现就职于 Facebook 公司）开发，是一套优秀的作 为 MySQL 高可用性环境下故障切换和主从角色提升的高可用软件。在 MySQL 故障切换过程 中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换 的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探 测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升 为新的 master，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应 用程序层面完全透明。 在 MHA 自动故障切换过程中，MHA 会试图从宕机的主服务器上保存二进制日志，最大 程度的保证数据不丢失

MHA 简介 MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案， 它由日本 DeNA 公司的 youshimaton 员工（现就职于 Facebook 公司）开发，是一套优秀的作 为 MySQL 高可用性环境下 故障切换 和 主从角色提升 的高可用软件。在 MySQL 故障切换过程 中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换 的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA 由两部分组成： MHA Manager（管理节点） 和 MHA Node（数据节点） 。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探 测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升 为新的 master，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应 用程序层面完全透明。 在 MHA 自动故障切换过程中，MHA 会试图从宕机的主服务器上保存二进制日志，最大

负载均衡 LVS+Keepalived https://www.cnblogs.com/jicki/p/5546862.html改天试试 一直没搞过. 系统 CentOS 5.6 X64 物理机 IP 10.10.10.104 Xen : 三台 CentOS 5.8 ip为: 10.10.10.106 10.10.10.107 10.10.10.108 ----------------------------------- IP 分配 ： LVS-vip 10.10.10.110 LVS-MASTER 10.10.10.104 是LVS 也是 WEB LVS-BACKUP 10.10.10.106 是LVS 也是 WEB WEB1-REALSERVER 10.10.10.107 WEB2-REALSERVER 10.10.10.108 WEB3-REALSERVER 10.10.10.106 是LVS 也是 WEB WEB4-REALSERVER 10.10.10.104 既是LVS 也是 WEB ------------------------------------ 安装开始: 首先在两台 LVS 上安装 LVS+Keppalived 下载 wget http://www.linuxvirtualserver.org/software/kernel-2.6/ipvsadm-1

近日接到一个故障，主从异步方式，主 crash后，从不可用，检查发现从机Read_Master_Log_Pos与Exec_Master_Log_Pos不一致，似乎还有binlog在回放中，HA在等回放结束，一直保持这个状态。难道从机也出故障了？根本原因是什么？且看下文。 MySQL binlog简介 首先简单了解要下binlog日志，Binary Log是在MySQL3.23.14中引入的，记录MySQL数据修改记录的文件集合。 Binary Log有两个目的： 用于复制。master（主)上的binlog日志发送到slave（从）上，slave执行回放master上的修改动作，保持主从数据一致。 用于数据恢复。对binlog日志文件指定始末位置执行即恢复指定数据。 本文是针对复制流程中的一个改进，不涉及数据恢复。 基于binlog的复制简介 Master上对修改动作生成binlog，Slave机IO拉取对应的binlog到本地生成relay log,然后Slave机SQL线程回放执行。binlog的最小单位为event，master与slave之间以 event为单位 传输日志，一个或多个event组成一个事务，slave机上以 事务为单位 回放日志。事务是数据库的常见基本特性，不再介绍，这里主要介绍下binlog中的event。 事务event包含header 和data

基于 MHA 的 MySQL 高可用方案 一、 MHA 简介 MHA （ Master High Availability ） 目前在 MySQL 高可用方面是一个相对成熟的解决方案， 它由日本 DeNA 公司的 youshimaton 员工（ 现就职于 Facebook 公司）开发，是一套优秀的作 为 MySQL 高可用性环境下 故障切换和主从角色提升 的高可用软件。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 M HA 由两部分组成： M H A M a n a g e （ r 管理节点 ） 和 M H A N o d e （数据节点 ） 。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台MySQL 服务器及Manager 服务器上，MHA Manager 会定时探 测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升 为新的 master ，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应用程序层面完全透明。 在 MHA

HAProxy 7层 负载均衡 https://www.cnblogs.com/jicki/p/5546902.html HAProxy 系统 CentOS 5.8 x64 wget http://haproxy.1wt.eu/download/1.3/src/haproxy-1.3.26.tar.gz cd haproxy-1.3.26 make TARGET=linux26 PREFIX=/opt/local/haproxy make install PREFIX=/opt/local/haproxy mkdir /opt/local/haproxy/conf cd /opt/local/haproxy/conf/ vim haproxy.cfg 后台配置模式 ------------------------------------------------------------------------------------------------ global log 127.0.0.1 local0 maxconn 65535 chroot /opt/local/haproxy uid 502 gid 502 daemon nbproc 8 pidfile /opt/local/haproxy/haproxy.pid defaults log 127.0.0.1

在windows下配置的，后面会在Linux下配置进行测试，需要配置mysql数据库同步的朋友可以参考下。 1.在主数据库服务器为从服务器添加一个拥有权限访问主库的用户: GRANT REPLICATION SLAVE ON *.* TO ' test'@'%' IDENTIFIED BY 'test'; (%表示允许所有IP，可设置指定从服务器IP) 添加用户后: 可在从服务器上用mysql -h127.0.0.1 -utest -ptest; 来测试是否有权限访问主数据库 2.在主据库配置文件加上: #master config server-id = 1 log-bin = mysql-bin 3.在从服务器数据库配置文件： server-id = 2 master-host = 10.0.0.199 master-user = test master-password = test replicate-do-db = test master-port = 3306 log-bin = mysql-bin 如果你的一切配置顺利 你在从服务器上输入命令：show slave status\G 成功情况： Slave_IO_Running:yes Slave_SQL_Running:yes 在主服务器上输入show master status 那么，恭喜，主从数据库配置OK

一、主从原理 Replication 线程 　 　Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。 要实现 MySQL 的Replication ，首先必须打开 Master 端的 Binary Log(mysql-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项，或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。 复制的基本过程如下 ： 1. Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 2. Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO