MySQL的日志和备份(第41天)

 MySQL日志分类：

查询日志：query log ，一般不开启

慢查询日志：slow query log 

错误日志：error log  

二进制日志：binary log

中继日志：reley log

事务日志：transaction log  


查询日志:

查询日志记录查询操作，这些日志可以保存在文件（file）和表（table）中，查询日志一般不开启

查询日志的相关的变量：  show global variables like '%log%';  

general_log      可以设置为ON或者OFF，表示开启或者关闭

general_log_file          c:\wamp64\bin\mysql\mysql5.7.24\data\hp8570p.log

log_output      可以设置为TABLE或者FILE或者NONE


慢查询日志：slow query log 

慢查询日志一般建议开启

查询时间超过指定时长的查询操作，long_query_time变量就是指定时长

show global variables like 'long_query_time';   查询该变量

set global long_query_time=12;      设置该变量


慢查询相关变量：

slow_query_log      可以设置为ON或者OFF

slow_query_log_file          c:\wamp64\bin\mysql\mysql5.7.24\data\hp8570p-slow.log


错误日志：

并不是只记录错误日志

该日志记录了mysqld启动和关闭过程中输出的事件信息，mysqld运行中产生的错误信息，event scheduler运行一个event时产生的日志信息，在主从复制架构中的从服务器上启动从服务器线程时产生的信息

错误日志的相关变量：

log_error        c:\wamp64\logs\mysql.log            

log_warnings       设置为0或1      表示是否记录警告信息到错误日志中


二进制日志：重要

记录导致数据改变或潜在导致数据改变的sql语句：

使用二进制格式保存；

二进制日志是滚动的，mysql-bin.000001 mysql-bin.000002  ....

二进制日志的功能：用于通过“重放”日志文件中的事件来生成数据副本的



SHOW BINARY LOGS;    查看mysql二进制日志文件

SHOW MASTER LOGS;  查看mysql二进制日志文件

SHOW MASTER STATUS;    查看当前正在使用的二进制日志文件及事件

SHOW BINLOG EVENTS in 'mysql-bin.000001'; 查看日志文件中记录的事件



二进制日志记录的格式：

基于语句记录：statement，相当于记录sql语句的

基于行记录：row，相当于记录数据的

缓和模式：mixed， 系统自行判定该基于哪种方式进行记录



二进制日志文件的构成：包括日志文件和索引文件

日志文件：mysql-bin.00001  mysql-bin.00002  .......   这些是二进制格式

索引文件：mysql-bin.indxe     文本格式


二进制日志相关的变量：show  global variables like '%log%'; 

sql_log_bin    设置为ON或者OFF  表示是否开启二进制日志

log_bin       日志文件的位置，可以在配置文件中配置

binlog_format      二进制日志的格式有ROW和STATEMENT和MIXED

max_binlog_size       单个二进制日志的最大体积，默认1G。达到最大自动滚动。

expire_logs_days  

sync_binlog=0 设定多久同步一次二进制日志文件；0表示不同步；任何正值都表示记录多少个语句后同步一次；



二进制日志格式的查看工具：mysqlbinlog  （客户端命令工具）

 mysqlbinlog --no-defaults  C:\wamp64\bin\mysql\mysql5.7.24\data\mysql-bin.000001


# at 19364

#140829 15:50:07 server id 1  end_log_pos 19486 Query thread_id=13 exec_time=0 error_code=0

SET TIMESTAMP=1409298607/*!*/;

GRANT SELECT ON tdb.* TO tuser@localhost

/*!*/;


事件发生的日期和时间；(140829 15:50:07)

事件发生在服务器的标识（server id）

事件的结束位置：（end_log_pos 19486）

事件的类型：(Query)

事件发生时所在的服务器执行此事件的线程的ID：（thread_id=13）

语句的时间戳与将其写入二进制文件中的时间差：（exec_time=0）

错误代码：（error_code=0)

事件内容：（SET TIMESTAMP=1409298607/*!*/; GRANT SELECT ON tdb.* TO tuser@localhost）             

GTID：事件所属的全局事务ID：（GTID 0-1-2）


mysqlbinlog命令的一些选项：

-j, --start-position=#：从指定的事件位置查看

--stop-position=#：只显示到指定的事件位置


--start-datetime=name

--stop-datetime=name

    YYYY-MM-DD hh:mm:ss


中继日志：

mysql复制架构中，从服务器哟娜与保存从主服务器的二进制日志中读取到的事件


事务日志：

事务日志由事务型存储引擎自行管理和使用

相关变量：

innodb_log_buffer_size                   8388608                

innodb_log_checksums                   ON                     

innodb_log_compressed_pages      ON                     

innodb_log_file_size                        268435456              

innodb_log_files_in_group              2                      

innodb_log_group_home_dir          .\                     

innodb_log_write_ahead_size          8192


mysql的备份和恢复（recovery）


mysql备份

为什么要备份？

灾难恢复：硬件故障、软件故障、自然灾害、黑客攻击；误操作；

对数据做测试：


备份时候要注意的事项：

可容忍丢失多少数据；

恢复数据需要在多长时间内完成；

需要恢复什么数据；


备份类型：

完全备份，增量备份，差异备份

增量备份：仅备份从上次完全备份或增量备份之后变化的数据部分；

差异备份：仅备份最近一次完全备份以来变化的数据

一般的备份策略是完全备份+增量备份或者是完全备份+差异本备份


备份类型：

热备份、温备份和冷备份：

热备份：在线备份，读写操作不受影响；

温备份：在线备份，读操作可继续进行，但写操作不允许；

冷备份：离线备份，数据库服务器离线，备份期间不能为业务提供读写服务；

MyISAM: 支持温备

InnoDB: 支持热备


备份类型：

物理备份：直接复制数据文件进行的备份；

逻辑备份：从数据库中“导出”数据另存而进行的备份；（mysqldump），与存储引擎无关


规则备份时需要考虑的因素：

持锁的时长

备份数据过程时长

备份时增加的系统负载

恢复数据过程时长


具体备份哪些数据：

数据、额外的数据（二进制日志和InnoDB的事务日志）、代码（存储过程和存储函数、触发器、事件调度器等）、服务器配置文件


设计备份方案：

数据集：完全备份+增量备份

备份手段：物理备份，逻辑备份


备份工具：

mysqldump：逻辑备份工具，适用于所有存储引擎，支持温备，支持完全备份，部分备份；对InnoDB存储引擎支持热备；

cp, tar等文件系统工具：物理备份工具，适用于所有存储引擎；仅支持冷备；支持完全备份，部分备份；

lvm2的快照：可以实现几乎热备；借助于文件系统工具实现物理备份；

mysqlhotcopy: 几乎冷备；仅适用于MyISAM存储引擎；（此工具基本没用）


备份方案之备份工具的选择：

mysqldump+binlog: mysqldump做完全备份，通过备份二进制日志实现增量备份；

lvm2快照+binlog：lvm2配合cp，tar工具做物理备份，通过备份二进制日志实现增量备份

xtrabackup: Percona公司提供

对InnoDB：热备，支持完全备份和增量备份

对MyISAM引擎：温备，只支持完全备份


























评论

发表评论

此博客中的热门博文

OAuth 2教程

图片
原文： http://tutorials.jenkov.com/oauth2/index.html OAuth 2.0是一种开放式 授权 协议，该协议使得应用程序可以访问彼此的数据。例如：一个游戏应用可以访问Facebook中的用户数据，或者基于位置的应用程序可以访问Foursquare应用程序的用户数据（ user data ）等。 OAuth 2.0被用于通过应用程序共享数据的示例如上图。 首先用户进入游戏的web应用，该应用要求用户通过Facebook账户登录，并定向到Facebook的登录界面，用户登录Facebook后，会重定向到之前的游戏应用。此时该应用就访问到了用户在Facebook的用户数据以及授权信息，并代表用户在Facebook中调用功能（例如发布状态更新）。 OAuth 2.0 用例 OAuth 2.0既可以用于在某个应用内访问其它应用的用户信息（比如上例中的游戏应用），又可以提供用户授权服务供其它应用调用（比如上例中的Facebook）。 OAuth 2.0是OAuth 1.0的替代，因为OAuth 1.0太复杂了，比如OAuth 1.0要求使用证书等。OAuth 2.0更加简单，不要求使用证书，仅使用SSL/TLS。 OAuth 2.0 规范 这个教程的目的是提供一个OAuth 2.0协议的概览以帮助理解，而不是涵盖此协议的所有细节。 如果你计划实现一个OAuth 2.0协议，最好是去阅读规范的详细内容，规范的地址：http://tools.ietf.org/html/draft-ietf-oauth-v2-23 OAuth 2.0 概述 在之前的介绍中我们提到，OAuth 2.0是一个开放标准，其允许某个应用程序访问其它应用程序的用户授权的数据。现在我们来介绍这个协议是如何工作的，以及规范中提到的各种概念。 OAuth 2.0 提供了不同的方式使得客户端应用获得权限去访问存储在资源服务器中的资源。现在介绍其中最安全和最常用的使用方式： 一个web应用请求访问另一个web应用 的资源。 下面的示例图描述了整个认证过程： 首先，用户访问客户端Web应用程序，在这个应用程序里有“通过Facebook登录”（或谷歌或Twitter等其他系统）的按钮。 第二步，当用户点击这个按...
阅读全文

网格策略

图片
波段策略网格之一：写在前面，体系以及策略 壹：写在前面 踏踏实实的踏踏实实 在这个有些寒意又充满希望的春天，我决定将我使用了7年的一个波段策略——网格策略，与大家分享与交流。这次分享，会把目前已经升级到3.0的网格策略事无巨细说的非常清楚。这应该是你能见到最详细最有价值的网格策略文章，因为这几篇文章凝结了整整7年的思考和实践。 在此之前，我不是不想与大家分享。有三个原因导致我迟迟没有做这件事。 第一个原因很简单，对于这样一个凝聚心血的东西，我是有些私心的。这个各位也应该能够理解。 第二个原因，在于这件事是一件需要耗费极大精力，又有很大风险的事情。对于做事的信条，我的理念是要么不做，要做就做到极致。所以我如果讨论这个策略，就一定要把方方面面的东西全部说到。这个工作量非常大。 同时，风险很大。风险点在于无论我如何强调需要注意的问题，看这篇文章的几万十几万读者，也一定有人学习能力强，有人接受能力差一些。只要有一个关键点你没有融会贯通，就可能出现不好的结果。 第三个原因，我自己也需要对这个策略进行不断的实践，不断将细节升级。我不可能将一个自己没有做过3轮以上的策略与大家分享，这是对你负责。我必须深刻理解它的优点缺点，才能跟你交流。我会用我自己的钱去做实证，而不是用你的。 基于以上原因，我一直没有公开讨论过这个策略。但现在，我认为时机差不多成熟了。再加上一些外部因素刺激，我决定与你分享。 这一个系列的文章会分为3-4篇。第一篇很重要，会讨论投资体系的构建，各种投资策略互相搭配的重要性以及应该注意的问题。这一篇虽然还未涉及网格策略，但真的很重要，希望你能认真看一看。 第二篇会介绍网格策略的基本操作方式。即1.0版本。 第三篇会介绍网格策略2.0。这次升级意义非常重大，将网格1.0的一些固有缺陷在一定程度上弥补掉。到时候看情况，也有可能将3.0也放在第三篇里，有可能将3.0单独开一篇。 这就是全部这次的交流计划。也许这个策略不适合你，也许你不喜欢这种波段策略，但无论如何，希望你能感受到我的责任感与诚意。 贰：投资体系 踏踏实实的踏踏实实 每个人做投资，都应该有一套完整的投资体系。整套体系包括大致两个方面： 第一个方面，是观察金融世界的体系。 ...
阅读全文

apt-get详细使用

NAME apt-get - APT包处理程序--基于命令行 SYNOPSIS apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file] [-t=target_release] [-a=architecture] {update | upgrade | dselect-upgrade | dist-upgrade | install pkg [{=pkg_version_number | /target_release}]...  | remove pkg...  | purge pkg...  | source pkg [{=pkg_version_number | /target_release}]...  | build-dep pkg [{=pkg_version_number | /target_release}]...  | download pkg [{=pkg_version_number | /target_release}]...  | check | clean | autoclean | autoremove | {-v | --version} | {-h | --help}} DESCRIPTION apt-get是一种基于命令行的包处理工具，被认为是相对于其它apt库的“后端”（指在命令行下）工具，同样也有一些“前端”（基于图形模式）下工具，如aptitude(8),synaptic(8)和wajig(1). 除了-h,或是--help这两个参数，下面的子命令之一必须使用。 update update是被用来与它们的源中的包索引文件进行同步的。 可用的软件包的索引是从/etc/apt/sources.list文件中指定的路径获取的。举个例子，当我们使用Debian时，这个命令就取出并扫描Packages.gz的文件，因为这样就能得到升级了的包和新的包的信息了。更新(update)应该在使用upgrade或是dist-upgrade这2个子命令之前使用。请注意：因爲无法预知包文件的大小，所以整體更新進度表將不正確。 （译者注：所以請注意，update並不真正升級安裝在系統上的軟件包，只是查...
阅读全文