今天装修百科网给各位分享binlog在哪里的知识，其中也会对Windows下mysql的binlog 位置在哪(mysqlbinlog -v)进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在我们开始吧！

Windows下mysql的binlog 位置在哪,版本是5.1.5

二进制文件在data目录下，
可以再mysql命令行执行， show variables like '%datadir%';查看data路径

mysql日志全部都没有开启，怎么回事

MySQL有以下几种日志：
错误日志： -log-err
查询日志： -log
慢查询日志: -log-slow-queries
更新日志: -log-update
二进制日志： -log-bin
默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，出现日志刷新

1. 错误日志
用--log- error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名 host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。
如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。

2. 通用查询日志
用--log[=file_name]或-l [file_name]选项启动它。如果没有给定file_name的值，默认名是host_name.log。

3. 慢速查询日志
用--log-slow-queries[=file_name]选项启动时，mysqld 写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件.如果没有给出file_name值，默认未主机名，后缀为 -slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。

3. 更新日志
用--log-update[=file_name]选项启动,不推荐使用.

是否启用了日志
mysql>show variables like 'log_%';
怎样知道当前的日志
mysql> show master status;
显示二进制日志数目
mysql> show master logs;
看二进制日志文件用mysqlbinlog
shell>mysqlbinlog mail-bin.000001
或者shell>mysqlbinlog mail-bin.000001 | tail

在配置文件中指定log的输出位置.
Windows：Windows 的配置文件为 my.ini，一般在 MySQL 的安装目录下或者 c:\Windows 下。
Linux：Linux 的配置文件为 my***f ，一般在 /etc 下。
在linux下：
Sql代码
# 在[mysqld] 中输入
#log
log-error=/usr/local/mysql/log/error.log
log=/usr/local/mysql/log/mysql.log
long_query_time=2
log-slow-queries= /usr/local/mysql/log/slowquery.log
# 在[mysqld] 中输入 #log
log-error=/usr/local/mysql/log/error.log
log=/usr/local/mysql/log/mysql.log
long_query_time=2
log-slow-queries= /usr/local/mysql/log/slowquery.log

windows下:
Sql代码
# 在[mysqld] 中输入
#log
log-error="E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/error.log"
log="E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/mysql.log"
long_query_time=2
log-slow-queries= "E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/slowquery.log"
# 在[mysqld] 中输入 #log
log-error="E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/error.log"
log="E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/mysql.log"
long_query_time=2
log-slow-queries= "E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/slowquery.log"

开启慢查询
long_query_time =2 --是指执行超过多久的sql会被log下来，这里是2秒
log-slow-queries= /usr/local/mysql/log/slowquery.log --将查询返回较慢的语句进行记录
log-queries-not-using-indexes = nouseindex.log --就是字面意思，log下来没有使用索引的query
log=mylog.log --对所有执行语句进行记录
windows下开启mysql日志：
在[mysql]下加入这些（基本上等于加在最后面）：
log-error=
#Enter a name for the query log file. Otherwise a default name will be used.
#注:（写成txt文件editplus可以及时重载,不过有时要放在C盘下editplus才可以及时重载）
log= c:/mysql_query.log.txt
#Enter a name for the slow query log file. Otherwise a default name will be used.
log-slow-queries=
#Enter a name for the update log file. Otherwise a default name will be used.
log-update=
#Enter a name for the binary log. Otherwise a default name will be used.
log-bin=

怎么查看阿里云服务器下的MySQL错误日志

在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。

　　而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。

　　当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。

　　而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。

mysql binlog 事务怎么记录

用来判断binlog中每条记录是在哪个服务器上产生的，在主主复制架构中可以防止无限复制循环。
#Enter a name for the error log file. Otherwise a default name will be used. log-error=err.log#Enter a name for the query log file. Otherwise a default name will be used. #log=#Enter a name for the slow query log file. Otherwise a default name will be used. #log-slow-queries=#Enter a name for the update log file. Otherwise a default name will be used. #log-update=#Enter a name for the binary log. Otherwise a default name will be used. #log-bin=

求助mysql日志中的二进制字符串还原

1、开启mysql的二进制日志
　　在mysql的配置文件my.ini中添加：
　　log-bin=mysql-bin(这个名称可以随便取，英文，不知道中文可不可以，没试过)
2、重启mysql
　　重启后，假如在mysql的存储数据的目录中出现一下文件，则已经二进制日志已经开启
　　
　　mysql-bin.000001是mysql的二进制日志文件，不可以直接查看，可以通过导出数据查看，导出数据的语句为
　　
　　解释一下：红色下划线的是mysql二进制mysql-bin.000001文件所在的目录，要进入这里执行后面的语句，这是我的情况
　　mysqlbinlog的语法：
　　mysqlbinlog 二进制日志文件 > 目标文件
　　要导出到哪里自己决定，但一定先要有这个目录，导出的文件则mysql会自动生成，所以不必新建
3、查看二进制日志状态
　　show master status;
　　+------------------+----------+--------------+------------------+
　　| File | Position | Binlog_Do_DB | Binlog_Ignore_DB
　　+------------------+----------+--------------+------------------+
　　| mysql-bin.000001 | 349
　　+------------------+----------+--------------+------------------+
　　1 row in set (0.00 sec)

如何备份Mysql数据库？网上常用的备份方法的那个命令我运行后提示，不是内部或外部命令无法执行

首先选择盘符D:就行
然后输入下列命令
备份：mysqldump -uroot -p demo > demo.sql
因为你没有选择数据库，demo为数据库
恢复数据库时可用：mysql -uroot -p demo<demo.sql

一个region server维护一个hlog，这样做有什么弊端

　　Region Server 宕机总述
　　HBase一个很大的特色是扩展性极其友好，可以通过简单地加机器实现集群规模的线性扩展，而且机器的配置并不需要太好，通过大量廉价机器代替价格昂贵的高性能机器。但也正因为廉价机器，由于网络硬盘等各方面的原因，机器宕机的概率就会相对比较大。RegionServer作为HBase集群中实际的执行节点，不可避免地也会出现宕机。
　　宕机并不十分可怕，因为不会丢数据。HBase集群中一台RegionServer宕机(实指RegionServer进程挂掉，下文同)并不会导致已经写入的数据丢失，和mysql等数据库一样，HBase采用WAL机制保证这点：它会先写HLog，再写缓存，缓存写满后一起落盘。即使意外宕机导致很多缓存数据没有及时落盘，也可以通过HLog日志恢复出来。
　　可是没有数据丢失并不意味着宕机对业务方没有任何影响。众所周知，RegionServer宕机是由zookeeper首先感知到的，而zookeeper感知到RegionServer宕机事件是需要一定时间的，这段时间默认会有3min。也就是说，在RegionServer宕机之后的3min之内系统并不知晓它实际上已经宕机了，所有的读写路由还会正常落到它上面，可想而知，这些读写必然都会失败。(当然，并不是所有RegionServer宕机都需要3min中才能被Zookeeper感知。如果RegionServer在运行过程中产生自身难以解决的问题，它会自己abort自己，并且RegionServer会主动通知Zookeeper自己已经宕机的事实。这种场景下，影响用户读写的时间会极大的缩短到秒级)Zookeeper一旦感知到RegionServer宕机之后，就会第一时间通知集群的管理者Master，Master首先会将这台RegionServer上所有Region移到其他RegionServer上，再将HLog分发给其他RegionServer进行回放，这个过程通常会很快。完成之后再修改路由，业务方的读写才会恢复正常。
　　既然，在分布式领域RegionServer宕机无法避免，那我们就有必要研究一旦宕机应该如何应对，即RegionServer宕机应对之道。另外，RegionServer宕机一定程度上会影响业务方的读写请求，所以我们也有必要研究如何定位宕机原因并设法避免。
　　Region Server 宕机应对之道
　　理论基础
　　HBase底层数据存储依赖于HDFS组件，HDFS中数据是按照block块来存储，一个块默认是64M。为了实现数据不丢失，线上HDFS存储普遍为多副本存储，默认为3副本。因此一个大文件在HDFS中存储，首先会被切分成多个block块，然后每个block块会被存放到3台不同的机器上，实现3副本存储。考虑到读性能以及数据的高可用性，HDFS在实现3副本的时候采取了一定的算法策略。HDFS总是为第一份副本优先选择本地节点作为存储空间，对于第二份副本，则是优先选择另一个机架的节点。如果前两份副本位于不同机架，第三份副本偏向于选择与第一份副本相同机架的节点，否则选择不同机架。整个写的流程如下图所示：

　　整个集群有两个机架Rank1和Rank2，每个机架分别有三台机器作为存储节点，其中最左边的节点为Region Server进程所在节点，称为本地节点。整个写入过程可以描述为：
　　本地一个192M大小的文件首先被切分为3个64M大小的block块
　　以最上面的绿色块为例，HDFS首先会选择本地节点存储第一个副本，然后在Rank2上随机找个节点存储第二个副本，最后再在Rank1上找一个非本地节点存第三个副本
　　3个block块最终的存储位置如图所示，只有本地节点完整保存了整个文件，其他节点都只有整个文件的一部分
　　理解了HDFS写文件的流程之后，我们还需要引入HBase中和读性能息息相关的一个概念：本地性(Locality)。HBase系统中，一个Region Server由多个Region构成，每个Region可以认为是一个计算节点，它会写入大量数据，这些数据落在本地节点的比例称为Locality。如上图所示，假如上图192M文件全部由Region 1产生，那么Region 1如果身处本地节点，因为所有数据都在本地节点上存在，所以Locality就是100%。而Region 1如果身处节点2，因为只有两个block块在节点2，Locality就只有66%。同理，一旦Region 1落到节点3，Locality就只有33%。那么Locality如何影响读性能呢?很显然，如果Locality越高，说明计算所需数据块都在本地，不需要远程访问，必然性能最高。反正，性能也就会越差。
　　接下来根据节点1上RegionServer宕掉前后，分三阶段来理解HBase在各种情况下的Locality变化:
　　阶段一：正常情况下，节点1上RegionServer产生的所有文件都在本地有一个副本，Locality就是100%。
　　阶段二：一旦节点上的RegionServer进程宕机，Master会把宕机节点上的Region根据系统的负载均衡情况分配到其他节点，负载最低的节点被分配到的Region会越多。假如此时不幸，节点3上的负载最低，那分配到节点3上的Region就会越多，落到节点3上的读请求数就会越多。然而节点3上只有一份block块，即Locality只有33%，此时一旦读取请求要读另外两份block块的数据，就只能通过网络访问其他节点，读取性能必然不高。
　　阶段三：再假如第一时间我们发现RegionServer进程宕掉了，我们只是手动拉了起来，没有其他处理措施，Master会简单地根据当前系统负载情况执行balance操作将其他负载较高节点上的Region重新移到恢复后的节点1上。从文件块的角度看，系统整体表现越来越混乱，整体Locality也会越来越低(当然，HBase也在致力于重新设计balance算法，能够尽量保证每个Region被分配给拥有最多Block的Region Server，提高系统Locality)
　　通过上述理论分析，如果仅仅依赖HBase本身的balance操作，就会使得系统整体Locality越来越低，读性能越来越差。那不禁要问，能不能人工执行balance操作呢?当然，我们可以在手动拉起RegionServer之后，将宕掉RegionServer上的Region全部又手动移回来，实际上就恢复到了阶段一的情形，Locality基本接近100%。接下来具体介绍如何实际操作。
　　运维实践
　　根据上述理论分析，RegionServer宕机之后一方面需要马上将其拉起来，另一方面在拉起来之后需要将该RegionServer上原有的Regions全部迁移回来。其中第二步又可以分为两小步，先找到该RegionServer上所有Regions，再执行迁移命令将所有Regions迁回。具体运维操作如下：
　　拉起Region Server ： ./bin/hbase-daemon.sh start regionserver
　　找到该RegionServer上所有原有Regions：RegionServer宕机之后会由Master将所有Regions迁移到其他节点上，这些操作都记录在了Master日志中，所以可以通过查看Master日志(类似于hbase-hadoop-master-hbase10.log.2016-01-04 )找到所有迁移的Regions，下图是日志中的一个片段：

　　其中master.AssignmentManaager字段表示有多少个Region被移动到了哪个节点，上图表示有18个节点移动到hbase11节点。字段Transition表示具体的迁移Region信息，可以通过如下脚本解析这部分日志得到所有的Regions：
　　cat ‘hbase-hadoop-master-hbase10.log’ | grep ‘GeneralBulkAssigner-[0-9]] master.RegionStates: Transition’ | awk -F ‘{‘ ‘{print $2}’ | awk -F ‘ ‘ ‘{print $1}’ | uniq

　　迁移Regions回原RegionServer：使用HBase提供的move命令可以迁移Region到原RegionServer。Region比较多的话也可以使用脚本批量迁移。
　　RegionServer 宕机原因定位
　　紧急处理完宕机的RegionServer之后，就应该着手定位宕机原因，确定是否可以设法避免。所有系统Bug原因定位无非三大招，查日志、查监控、查代码。RegionServer宕机排查主要依赖前两点。下面以一个具体事例来简单说明排查RegionServer宕机的过程：线上有一个HBase集群，由4个RegionServer组成，这个集群每隔一段时间就会出现一个RegionServer宕掉的情况，首先想到排查日志，如下：
　　排查日志
　　HBase系统日志主要包括master日志(上文已提到)，regionserver日志以及gc日志。很显然，regionserver宕机主要查看regionserver日志，经过排查，在对应时间点找到如下日志片段：

　　从中我们明显可以看到，hbase8这台机器已经无法绑定到端口0，端口0表示内核自动会分配一个可用端口，这个端口是随机的。无法绑定到端口0实际上就表示内核已经无法分配出可用的端口，即端口被耗尽。这种情况就属于上文提到的Region Server遇到了自己无法解决的问题，然后它就默默地自己abort了自己，见下图：

　　排查监控
　　系统可用端口被耗尽，立马联想到HBase所有读写HDFS操作都会发起RPC请求，如果并发RPC请求太多，会不会导致端口耗尽?带着这样的疑问排查了监控系统中这台主机的网卡流量图，如下图：

　　确实发现hbase8上的流量高达100M字节每秒，网卡基本被打满，和业务方确认后得知是业务方配置问题导致一张表的查询流量太高导致，和业务方沟通之后修改配置，流量就掉到40M字节每秒，后续我们还进一步将这张表进行了split操作，并且移到了其他几个节点上。
　　到此为止，我们以为RegionServer再也不会频繁宕机了。直到有一天，又有另一台RegionServer宕机，查看日志发现是同样的端口耗尽错误，然而排查监控发现网卡流量却正常。偶然一次例行排查监控，却意外获得了rs宕机的规律性事实，见下图：

　　上图是节点上连接状态统计图，红线表示处于CLOSE_WAIT状态的socket数。很显然，系统中处于CLOSE_WAIT状态的socket数不断上升直至50k+，然后跳水式下跌，联想到RegionServer会每隔一段时间宕机以及端口被耗尽，这不就是规律么。显而易见，既然是周期性地宕机，我们就可以根据监控数据知道下一次宕机大约发生在什么时候，然后在发生之前平滑重启Region Server就可以保证不影响上层业务请求。
　　但是，这并没有说明宕机的真正原因，但是却给了我们足够多的提示信息。带着CLOSE_WAIT关键字，在HBase官方Jira上一搜就很容易得到很多这方面问题，具体详见：HBASE-13488 HDFS-1836 等等。基于当前的HDFS和HBase版本，针对这个问题暂时没有好的解决方案，只能通过定期重启来避免宕机，好在HBase也提供了平滑重启一个RegionServer的命令graceful_stop，执行这个重启命令不会对上层业务有任何影响，具体执行过程如下：

　　RegionServer宕机总结
　　RegionServer宕机是HBase系统不可完全避免的场景，本文分三个部分从运维角度介绍RegionServer宕机这一事件。首先介绍宕机对应用方会造成什么影响、数据会不会丢等，第二部分接着介绍一旦RegionServer宕机之后应该如何正确地处理，第三部分使用一个具体事例介绍如何通过排查日志以及监控定位RegionServer宕机原因并设法避免宕机发生。看官阅览之后如果能对HBase中RegionServer宕机有一个基础的了解，俺心甚慰!

LNMP模式下如何开启PHP错误日志

500错误首先就需要先开启php错误日志，通过php错误日志来排错。
LNMP下的错误需要编辑 /usr/local/php/etc/php-fpm***nf 加上
php_admin_value[error_log] = /usr/local/php/var/log/php_errors.log
php_admin_flag[log_errors] = on
或在/usr/local/php/etc/php-fpm***nf里设置，加上catch_workers_output
= yes，错误信息就会记录到php-fpm***nf里error_log设置的文件里。 上述两种方法都行，重启php-fpm生效
同理php.ini里的display_errors也是需要在php-fpm***nf里设置的，加上php_flag[display_errors]
= On就开启了。 有时可能错误日志文件不自动创建，可以执行：touch
/usr/local/php/var/log/php_errors.log

mysql有几种日志格式

mysql 5.5 有以下几种日志：
错误日志(error log)： log-err
查询日志(general query log)： log
慢查询日志: -log-slow-queries
二进制日志 (binary log)： log-bin
中继日志( relay log)
innodb 在线redo 日志
默认情况下，没有启动任何log，可以通过log 选项来启动相关的log