月度归档:2017年08月

Protocol Buffers

RPC(Remote Procedure Call,远程过程调用)框架是分布式服务的基石,实现RPC框架需要考虑方方面面。其对业务隐藏了底层通信过程(TCP/UDP、打包/解包、序列化/反序列化),使上层专注于功能实现;框架层面,提供各类可选架构(多进程/多线程/协程);应对设备故障(高负载/死机)、网络故障(拥塞/网络分化),提供相应容灾措施。

 

RPC节点间为了协同工作、实现信息交换,需要协商一定的规则和约定,例如字节序、压缩或加密算法、各字段类型。通信协议的应用随处可见,例如我们对可选信息或字段经常使用TLV进行编码,HTTP、FTP等协议基于可读文本的 "Field: Value" 格式,各种系统也经常使用json、XML格式完成相互间通信。

 

不同的通信协议适用于不同的应用场景,比如内部系统的交互我们选择json,一来可读性较好,二来各种语言都提供了解析json的库、方便编码。Google Protocol Buffers是生成环境中常用的通信协议,除了可以设定Client/Server间通信格式,Protocol Buffers还对数据进行压缩,节省传输流量、加快传输速度。下面我们来了解Google Protocol Buffers。

 

Protocol Buffers

我们看如何使用Protocol Buffers(以下简称PB),首先在.proto文件中定义数据格式,下面以Person.proto为例:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}
message类型内,可以定义int、string、bool、string等类型的字段,也可以嵌套定义messages类型。每个字段可以是required、optional或repeated类型,分别表示必须每次通信必须填充该字段、可选或可重复。每个message类型内的每个字段被赋值唯一的数字值,PB以二进制格式进行数据传输,数字值在二进制中作为该字段的标识。关于PB数据格式的更多内容可参考Protocol Buffers Language Guide

 

完成数据定义后,接下来可以使用protoc工具解析Person.proto文件,生成Person类:

protoc --cpp_out=/home/bangerlee/PB ./Person.proto

执行以上命令后,可以看到 /home/bangerlee/PB 目录下生成了两个文件:

person.pb.cc  person.pb.h

其中定义了操作(get/set)Person类各个字段的函数。

 

有了接口,我们就可以在代码中这样使用Person类,写入操作如下:

Person person;
person.set_name("bangerlee");
person.set_id(1234);
person.set_email("bangerlee@gmail.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);
读取操作如下:
fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

以上我们初步了解了如何使用PB,PB运用了一些编码规则,使得需要传输的数据(二进制格式)更小,下面我们就来了解PB如何对不同数据类型的编码规则。

 

编码(Encoding)

对整形int、字符串类型string等,PB有不同的编码方式。对整型int,PB使用了Varints编码方式,Varints编码的优势是使用了更少的bytes来表示很小的int类型值。

 

Varints编码方式中,每个byte的最高位bit有特殊含义,如果为1,表示后续的byte也是这个数字的一部分;如果为0,则表示结束。剩余的7个bit用于表示数据。数字300用Varints编码方式表示为:

1010 1100 0000 0010

由Varints编码规则,去掉第一个byte的最高位1,去掉第二个byte的最高位0,则有:

1010 1100 0000 0010
→ 010 1100  000 0010

Varints字节序使用little-endian,以上数字用big-endian并转换成10进制有:

000 0010  010 1100
→  000 0010 ++ 010 1100
→  100101100
→  256 + 32 + 8 + 4 = 300

以上了解了Varints对int整型的编码方式,我们再来看PB如何编码更多数据类型:

PB编码中,数据以key-value的形式表示,第一个byte即为key。以上表格中不同数据类型对应指定type值,假设message中各字段的数字标识为tag,则key、type和tag有以下对应关系:

key = tag << 3 | type

即key的最后3个bit用于存储type,有了这层关系,我们试着演算PB中对int和string的编码。

 

假设我们截获到以下PB数据:

08 96 01

这段数据具体表示什么?我们用以上对应关系演算一下,首先该数据key是08,二进制表示即:

0000 1000

最后3个bit表示type,即type为0(Varint格式数据),左移3位得到tag值为1。有了这些信息,我们可以知道这个数据应该是这样定义的:

message Test1 {
  xxx int32 a = 1;
}

继续地,我们用Varint格式来解析 96 01,有以下演算过程:

96 01 = 1001 0110  0000 0001
       → 000 0001  ++  001 0110 (丢弃最高位的bit并转为big-endian)
       → 10010110
       → 2 + 4 + 16 + 128 = 150

因此我们可以知道这段数据表示150这个数。

 

又假设我们截获到以下一段PB编码:

12 07 74 65 73 74 69 6e 67

同样套用以上关系,key是12,二进制表示即:

0001 0010

最后3个bit表示type,即type为2(Length-delimited),左移3位得到tag值为2。有了这些信息,我们知道这个数据可能是这样定义的:

message Test2 {
  xxx string b = 2;
}

数据类型具体是string、bytes或其他,这并不影响我们解析这段数据,对于Length-delimited格式数据,第2个byte表示数据长度(Len),对应以上编码即Len为7,这实质是TLV编码格式。

后续的7个bytes表示有效的传输数据,为UTF-8编码下的"testing"字符串。

 

小结

以上介绍了通信协议 - Google Protocol Buffers,了解了其基本使用方法和编码方式。PB支持前向兼容,可以在不修改Client/Server程序的情况下修改其中一端的数据格式,在各种RPC框架中经常可以看到它的身影。

Reference: Protocol Buffers Developer Guide

Protocol Buffers Encoding

Apache Thrift

Thrift源于大名鼎鼎的facebook之手,在2007年facebook提交Apache基金会将Thrift作为一个开源项目,对于当时的facebook来说创造thrift是为了解决facebook系统中各系统间大数据量的传 输通信以及系统之间语言环境不同需要跨平台的特性。所以thrift可以支持多种程序语言,例如:  C++, C#, Cocoa, Erlang, Haskell, Java, Ocami, Perl, PHP, Python, Ruby, Smalltalk. 在多种不同的语言之间通信thrift可以作为二进制的高性能的通讯中间件,支持数据(对象)序列化和多种类型的RPC服务。Thrift适用于程序对程 序静态的数据交换,需要先确定好他的数据结构,他是完全静态化的,当数据结构发生变化时,必须重新编辑IDL文件,代码生成,再编译载入的流程,跟其他IDL工具相比较可以视为是Thrift的弱项,Thrift适用于搭建大型数据交换及存储的通用工具,对于大型系统中的内部数据传输相对于JSON和xml无论在性能、传输大小上有明显的优势。

Thrift是IDL(interface definition language)描述性语言的一个具体实现,关于IDL的话题我们可以追溯到CORBA盛行1999-2001年(Common Object Request Broker Architecture/公用对象请求代理体系结构),在 IDL 中我们似乎不会忘记到这几个关键字:module、interface、string、long 和 int,我还记得IDL利用module来创建名称空间,并且准确地映射为 Java 的 package,这些特性几乎和现在thrift的特性完全相同,所以thrift的设计思想和理念绝不是什么从火星来的new idea,看看在那个CORBA盛行的年代人们提出的概念,如图所示CORBA 请求的各个部分,回头我们再与thrift进行对比一下:

 

Thrift 基础架构
Thrift是一个服务端和客户端的架构体系,从我个人的感官上来看Thrift是一个类似XML-RPC+Java-to- IDL+Serialization Tools=Thrift 的东东,Thrift 具有自己内部定义的传输协议规范(TProtocol)和传输数据标准(TTransports),通过IDL脚本对传输数据的数据结构(struct) 和传输数据的业务逻辑(service)根据不同的运行环境快速的构建相应的代码,并且通过自己内部的序列化机制对传输的数据进行简化和压缩提高高并发、 大型系统中数据交互的成本,下图描绘了Thrift的整体架构,分为6个部分:1.你的业务逻辑实现(You Code) 2.客户端和服务端对应的Service 3.执行读写操作的计算结果4.TProtocol 5.TTransports  6.底层I/O通信

 

 

图 中前面3个部分是1.你通过Thrift脚本文件生成的代码,2.图中的褐色框部分是你根据生成代码构建的客户端和处理器的代码,3.图中红色的部分是2 端产生的计算结果。从TProtocol下面3个部分是Thrift的传输体系和传输协议以及底层I/O通信,Thrift并且提供 堵塞、非阻塞,单线程、多线程的模式运行在服务器上,还可以配合服务器/容器一起运行,可以和现有JEE服务器/Web容器无缝的结合。

数据类型
* Base Types:基本类型
* Struct:结构体类型
* Container:容器类型,即List、Set、Map
* Exception:异常类型
* Service: 定义对象的接口,和一系列方法

协议
Thrift可以让你选择客户端与服务端之间传输通信协议的类别,在传输协议上总体上划分为文本(text)和二进制(binary)传输协议, 为节约带宽,提供传输效率,一般情况下使用二进制类型的传输协议为多数,但有时会还是会使用基于文本类型的协议,这需要根据项目/产品中的实际需求:
* TBinaryProtocol – 二进制编码格式进行数据传输。
* TCompactProtocol – 这种协议非常有效的,使用Variable-Length Quantity (VLQ) 编码对数据进行压缩。
* TJSONProtocol – 使用JSON的数据编码协议进行数据传输。
* TSimpleJSONProtocol – 这种节约只提供JSON只写的协议,适用于通过脚本语言解析
* TDebugProtocol – 在开发的过程中帮助开发人员调试用的,以文本的形式展现方便阅读。

传输层
* TSocket- 使用堵塞式I/O进行传输,也是最常见的模式。
* TFramedTransport- 使用非阻塞方式,按块的大小,进行传输,类似于Java中的NIO。
* TFileTransport- 顾名思义按照文件的方式进程传输,虽然这种方式不提供Java的实现,但是实现起来非常简单。
* TMemoryTransport- 使用内存I/O,就好比Java中的ByteArrayOutputStream实现。
* TZlibTransport- 使用执行zlib压缩,不提供Java的实现。

服务端类型
* TSimpleServer -  单线程服务器端使用标准的堵塞式I/O。
* TThreadPoolServer -  多线程服务器端使用标准的堵塞式I/O。
* TNonblockingServer – 多线程服务器端使用非堵塞式I/O,并且实现了Java中的NIO通道。

 

 

 

 

大数据量存储见解

百万级的数据,无论侧重OLTP还是OLAP,当然就是MySql了。
过亿级的数据,侧重OLTP可以继续Mysql,侧重OLAP,就要分场景考虑了

实时计算场景:强调实时性,常用于实时性要求较高的地方,可以选择Storm;
批处理计算场景:强调批处理,常用于数据挖掘、分析,可以选择Hadoop;
实时查询场景:强调查询实时响应,常用于把DB里的数据转化索引文件,通过搜索引擎来查询,可以选择solr/elasticsearch;
企业级ODS/EDW/数据集市场景:强调基于关系性数据库的大数据实时分析,常用于业务数据集成,可以选择Greenplum;

数据库系统一般分为两种类型:
一种是面向前台应用的,应用比较简单,但是重吞吐和高并发的OLTP类型;
一种是重计算的,对大数据集进行统计分析的OLAP类型。

传统数据库侧重交易处理,即OLTP,关注的是多用户的同时的双向操作,在保障即时性的要求下,系统通过内存来处理数据的分配、读写等操作,存在IO瓶颈。
OLTP(On-Line Transaction Processing,联机事务处理)系统也称为生产系统,它是事件驱动的、面向应用的,比如电子商务网站的交易系统就是一个典型的OLTP系统。OLTP的基本特点是:
数据在系统中产生;
基于交易的处理系统(Transaction-Based);
每次交易牵涉的数据量很小;
对响应时间要求非常高;
用户数量非常庞大,主要是操作人员;
数据库的各种操作主要基于索引进行。

分析型数据库是以实时多维分析技术作为基础,即侧重OLAP,对数据进行多角度的模拟和归纳,从而得出数据中所包含的信息和知识。
OLAP(On-Line Analytical Processing,联机分析处理)是基于数据仓库的信息分析处理过程,是数据仓库的用户接口部分。OLAP系统是跨部门的、面向主题的,其基本特点是:
本身不产生数据,其基础数据来源于生产系统中的操作数据(OperationalData);
基于查询的分析系统;
复杂查询经常使用多表联结、全表扫描等,牵涉的数据量往往十分庞大;
响应时间与具体查询有很大关系;
用户数量相对较小,其用户主要是业务人员与管理人员;

.NET Core 2.0


点击查看原图

  下载 Visual Studio 2017 version 15.3

  下载 .NET Core 2.0

  下载 Visual Studio for Mac

点击查看原图

  微软今天发布了.NET Core 2.0 版本,属于一次非常大的版本迭代。

  .NET Core 2.0 主要包括一些让 .NET Core 更容易使用的改进,并增强其平台能力。亮点如下:

  Runtime

  SDK

  Visual Studio

  • Live Unit Testing supports .NET Core

  • Code navigation improvements

  • C# Azure Functions support in the box

  • CI/CD support for containers

点击查看原图

  主要更新方面,包括对两个关键组成部分 Runtime(CoreCLR)和 Framework Libraries(CoreFX,框架库)进行了完整的性能优化,由此可见,进程管理、JIT 编译器以及服务器系统的体验将会更好。

  同时,引入 .NET Standard 2.0,使得开发人员可利用的 API 数量翻了不止两倍。另外,微软还强调,.NET Core 2.0 已经可以用于部署 Azure Web 应用。

  更多细节可查阅发行说明


  .NET Standard 2.0 发布,增大 API 范围

  .NET Standard 2.0 规范现已完成,支持以下平台:

  • .NET Framework 4.6.1

  • .NET Core 2.0

  • Mono 5.4

  • Xamarin.iOS 10.14

  • Xamarin.Mac 3.8

  • Xamarin.Android 7.5

  • 即将推出 UWP 版本 (预计今年晚些时候)

  .NET Standard 2.0 自 .NET Standard 1.X 的基础上大大增加了 API 范围,这意味着将现有代码从
.NET Framework 移植到 .NET Standard 变得更加容易。它还添加了一种兼容性模式,用于引用 .NET Standard
中现有的 .NET Framework 二进制文件。

点击查看原图

  更多细节和内容请查阅发行说明


  ASP.NET Core 2.0 发布,引进 Razor Pages 编码范例

  ASP.NET 团队宣布 ASP.NET Core 2.0 发布,此版本与 .NET Core 2.0 兼容,支持 Visual Studio 2017 15.3 版本,并引进了新的 Razor Pages 用户界面设计范例。

  有关更新的完整列表,可以阅读更新日志

  最新的 SDK 和工具可从 https://dot.net/core 下载。

  ASP.NET Core 2.0 添加了许多新功能,使 Web 应用的构建和监控更加轻松,并提高性能。

  将项目更新至 ASP.NET Core 2.0

  ASP.NET Core 2.0 在 .NET Framework 4.6.1 和 .NET Core 2.0 上运行,因此 1.x 版本的 .NET Core 需要将项目中的目标框架更新为 netcoreapp2.0 。详情

点击查看原图

  Razor Pages

  这个新的编码范例,旨在让编写基于页面的场景比目前的模型 - 视图 - 控制器架构更容易。Razor Pages 是一个页面优先(page-first)的结构,可让你专注于用户界面,并通过编写 PageModel 对象来简化服务器端的体验。详情

  模板更新

点击查看原图

点击查看原图

  此外还包括 Razor 引擎支持 C#7.1 、简化应用主机配置、提供性能分析、错误报告和诊断集成等改进,详情查阅发行说明


  Entity Framework Core 2.0 正式版发布

  Entity Framework Core 2.0 正式版本已发布,它是 Entity Framework 的轻量级、可扩展和跨平台版本,是 .NET 的对象/关系映射(O / RM)框架。

  更新亮点:

  • .NET Standard 2.0

  • Improved LINQ translation

  • Like query operator

  • Owned entities and Table Splitting

  • Global query filters

  • DbContext Pooling

  • String interpolation in raw SQL methods

  各项具体细节和使用方式请查阅发行说明


  值得一提的是,今天,微软还发放了 Visual Studio 2017 v15.3 和 Visual Studio for Mac v7.1。

点击查看原图

点击查看原图

  Visual Studio 2017 version 15.3

  该版本包含 1700 多项改进,主要专注于可用性的改进,尤其是在 low-vision 和 no-vision 模式下使用 Visual Studio 2017 感觉会尤为明显。

  主要包括:

  • 调试更易于使用

  • VS 编辑器的文字修饰会让开发者了解一系列代码上特定的功能

  • 修复可靠性问题来提高性能

  • Azure Functions 支持

  • Broad Azure 登录支持

  • 容器支持改进

  • 内置持续交付工具

  完整的改进清单,请查看 Visual Studio 2017 15.3 的更新日志发行说明

  Visual Studio for Mac version 7.1

  Visual Studio for Mac 7.1 增加了对 .NET Core 2.0 的支持,它还可以在项目中创建 .NET Standard 2.0 ,以跨项目共享更多代码。此外,也包括许多可靠性改进,减少内存占用,改进性能,减少崩溃。详情

CPU/GPU

CPU和GPU之所以大不相同,是由于其设计目标的不同,它们分别针对了两种不同的应用场景。CPU需要很强的通用性来处理各种不同的数据类型,同时又要逻辑判断又会引入大量的分支跳转和中断的处理。这些都使得CPU的内部结构异常复杂。而GPU面对的则是类型高度统一的、相互无依赖的大规模数据和不需要被打断的纯净的计算环境。

  于是CPU和GPU就呈现出非常不同的架构(示意图):

点击查看原图

  图片来自nVidia CUDA文档。其中绿色的是计算单元,橙红色的是存储单元,橙黄色的是控制单元。

GPU采用了数量众多的计算单元和超长的流水线,但只有非常简单的控制逻辑并省去了Cache。而CPU不仅被Cache占据了大量空间,而且还有有复杂的控制逻辑和诸多优化电路,相比之下计算能力只是CPU很小的一部分

点击查看原图

  从上图可以看出:

Cache, local memory: CPU > GPU

Threads(线程数): GPU > CPU

Registers: GPU > CPU  多寄存器可以支持非常多的Thread,thread需要用到register,thread数目大,register也必须得跟着很大才行。

SIMD Unit(单指令多数据流,以同步方式,在同一时间内执行同一条指令): GPU > CPU。

 

CPU 基于低延时的设计:

点击查看原图

CPU有强大的ALU(算术运算单元),它可以在很少的时钟周期内完成算术计算。

当今的CPU可以达到64bit 双精度。执行双精度浮点源算的加法和乘法只需要1~3个时钟周期。

CPU的时钟周期的频率是非常高的,达到1.532~3gigahertz(千兆HZ, 10的9次方).

 

大的缓存也可以降低延时。保存很多的数据放在缓存里面,当需要访问的这些数据,只要在之前访问过的,如今直接在缓存里面取即可。

 

复杂的逻辑控制单元。当程序含有多个分支的时候,它通过提供分支预测的能力来降低延时。

数据转发。 当一些指令依赖前面的指令结果时,数据转发的逻辑控制单元决定这些指令在pipeline中的位置并且尽可能快的转发一个指令的结果给后续的指令。这些动作需要很多的对比电路单元和转发电路单元。

点击查看原图

GPU是基于大的吞吐量设计。

GPU的特点是有很多的ALU和很少的cache. 缓存的目的不是保存后面需要访问的数据的,这点和CPU不同,而是为thread提高服务的。如果有很多线程需要访问同一个相同的数据,缓存会合并这些访问,然后再去访问dram(因为需要访问的数据保存在dram中而不是cache里面),获取数据后cache会转发这个数据给对应的线程,这个时候是数据转发的角色。但是由于需要访问dram,自然会带来延时的问题。

GPU的控制单元(左边黄色区域块)可以把多个的访问合并成少的访问。

GPU的虽然有dram延时,却有非常多的ALU和非常多的thread. 为啦平衡内存延时的问题,我们可以中充分利用多的ALU的特性达到一个非常大的吞吐量的效果。尽可能多的分配多的Threads.通常来看GPU ALU会有非常重的pipeline就是因为这样。

 

所以与CPU擅长逻辑控制,串行的运算。和通用类型数据运算不同,GPU擅长的是大规模并发计算,这也正是密码破解等所需要的。所以GPU除了图像处理,也越来越多的参与到计算当中来。

GPU的工作大部分就是这样,计算量大,但没什么技术含量,而且要重复很多很多次。就像你有个工作需要算几亿次一百以内加减乘除一样,最好的办法就是雇上几十个小学生一起算,一人算一部分,反正这些计算也没什么技术含量,纯粹体力活而已。而CPU就像老教授,积分微分都会算,就是工资高,一个老教授资顶二十个小学生,你要是富士康你雇哪个?GPU就是这样,用很多简单的计算单元去完成大量的计算任务,纯粹的人海战术。这种策略基于一个前提,就是小学生A和小学生B的工作没有什么依赖性,是互相独立的。很多涉及到大量计算的问题基本都有这种特性,比如你说的破解密码,挖矿和很多图形学的计算。这些计算可以分解为多个相同的简单小任务,每个任务就可以分给一个小学生去做。但还有一些任务涉及到“流”的问题。比如你去相亲,双方看着顺眼才能继续发展。总不能你这边还没见面呢,那边找人把证都给领了。这种比较复杂的问题都是CPU来做的。

  总而言之,CPU和GPU因为最初用来处理的任务就不同,所以设计上有不小的区别。而某些任务和GPU最初用来解决的问题比较相似,所以用GPU来算了。GPU的运算速度取决于雇了多少小学生,CPU的运算速度取决于请了多么厉害的教授。教授处理复杂任务的能力是碾压小学生的,但是对于没那么复杂的任务,还是顶不住人多。当然现在的GPU也能做一些稍微复杂的工作了,相当于升级成初中生高中生的水平。但还需要CPU来把数据喂到嘴边才能开始干活,究竟还是靠CPU来管的。

 

什么类型的程序适合在GPU上运行?

  (1)计算密集型的程序。所谓计算密集型(Compute-intensive)的程序,就是其大部分运行时间花在了寄存器运算上,寄存器的速度和处理器的速度相当,从寄存器读写数据几乎没有延时。可以做一下对比,读内存的延迟大概是几百个时钟周期;读硬盘的速度就不说了,即便是SSD, 也实在是太慢了。

  (2)易于并行的程序。GPU其实是一种SIMD(Single Instruction Multiple Data)架构, 他有成百上千个核,每一个核在同一时间最好能做同样的事情。

摘自:

http://www.cnblogs.com/biglucky/p/4223565.html

mysqldump

mysqldump 用来转储数据库或搜集数据库进行备份或将数据转存为文件
如在服务器上进行备份并且表均为MyISAM表,应考虑使用mysqlhotcopy,因为可以更快地进行备份和恢复。

1.mysqldump的几种常用方法:

(1)导出整个数据库(包括数据库中的数据)

mysqldump -u username -p dbname > dbname.sql

(2)导出数据库结构(不含数据)

mysqldump -u username -p -d dbname > dbname.sql

(3)导出数据库中的某张数据表(包含数据)

mysqldump -u username -p dbname tablename > tablename.sql

(4)导出数据库中的某张数据表的表结构(不含数据)

mysqldump -u username -p -d dbname tablename > tablename.sql

(5)转储几个数据库
mysqldump ---database db_name1 [db_name2 ...] > my_databases.sql

(6)转储全库
mysqldump --all-databases > all_databases.sql

(7)Master/Slave 数据转移
mysqldump -uroot -ppassword --opt --default-character-set=utf8 --extended-insert=true --single-transaction -R --flush-logs --master-data=1 --all-databases > 20170809.sql

注:查询file和position的值 grep -i "change master to" 20170809.sql
windows find "CHANGE MASTER TO " d:\\20170809.sql

2. 还原数据到库

mysql> source /home/dba/dbname.sql
shell> mysql db_name < backup-file.sql
shell> mysqldump --opt db_name > backup-file.sql

库内具有函数时考虑:
SET GLOBAL log_bin_trust_function_creators = 1;
source /home/dba/dbname.sql
SET GLOBAL log_bin_trust_function_creators = 0;

3. mysqldump支持的选项
如果运行mysqldump没有--quick或--opt选项,mysqldump在转储结果前将整个结果集装入内存。如果转储大数据库可能会出现问题。该选项默认启用,但可以用--skip-opt禁用。

如果使用最新版本的mysqldump程序生成一个转储重装到很旧版本的MySQL服务器中,不应使用--opt或-e选项。

mysqldump支持下面的选项:

· ---help,-?

显示帮助消息并退出。

· --add-drop--database

在每个CREATE DATABASE语句前添加DROP DATABASE语句。

· --add-drop-tables

在每个CREATE TABLE语句前添加DROP TABLE语句。

· --add-locking

用LOCK TABLES和UNLOCK TABLES语句引用每个表转储。重载转储文件时插入得更快。

· --all--database,-A

转储所有数据库中的所有表。与使用---database选项相同,在命令行中命名所有数据库。

· --allow-keywords

允许创建关键字列名。应在每个列名前面加上表名前缀。

· ---comments[={0|1}]

如果设置为 0,禁止转储文件中的其它信息,例如程序版本、服务器版本和主机。--skip—comments与---comments=0的结果相同。 默认值为1,即包括额外信息。

· --compact

产生少量输出。该选项禁用注释并启用--skip-add-drop-tables、--no-set-names、--skip-disable-keys和--skip-add-locking选项。

· --compatible=name

产生与其它数据库系统或旧的MySQL服务器更兼容的输出。值可以为ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options或者no_field_options。要使用几个值,用逗号将它们隔开。这些值与设置服务器SQL模式的相应选项有相同的含义。

该选项不能保证同其它服务器之间的兼容性。它只启用那些目前能够使转储输出更兼容的SQL模式值。例如,--compatible=oracle 不映射Oracle类型或使用Oracle注释语法的数据类型。

· --complete-insert,-c

使用包括列名的完整的INSERT语句。

· --compress,-C

压缩在客户端和服务器之间发送的所有信息(如果二者均支持压缩)。

· --create-option

在CREATE TABLE语句中包括所有MySQL表选项。

· ---database,-B

转储几个数据库。通常情况,mysqldump将命令行中的第1个名字参量看作数据库名,后面的名看作表名。使用该选项,它将所有名字参量看作数据库名。CREATE DATABASE IF NOT EXISTS db_name和USE db_name语句包含在每个新数据库前的输出中。

· ---debug[=debug_options],-# [debug_options]

写调试日志。debug_options字符串通常为'd:t:o,file_name'。

· --default-character-set=charset

使用charsetas默认字符集。如果没有指定,mysqldump使用utf8。

· --delayed-insert

使用INSERT DELAYED语句插入行。

· --delete-master-logs

在主复制服务器上,完成转储操作后删除二进制日志。该选项自动启用--master-data。

· --disable-keys,-K

对于每个表,用/*!40000 ALTER TABLE tbl_name DISABLE KEYS */;和/*!40000 ALTER TABLE tbl_name ENABLE KEYS */;语句引用INSERT语句。这样可以更快地装载转储文件,因为在插入所有行后创建索引。该选项只适合MyISAM表。

· --extended-insert,-e

使用包括几个VALUES列表的多行INSERT语法。这样使转储文件更小,重载文件时可以加速插入。

· --fields-terminated-by=...,--fields-enclosed-by=...,--fields-optionally-enclosed-by=...,--fields-escaped-by=...,--行-terminated-by=...

这些选项结合-T选项使用,与LOAD DATA INFILE的相应子句有相同的含义。

· --first-slave,-x

不赞成使用,现在重新命名为--lock-all-tables。

· --flush-logs,-F

开始转储前刷新MySQL服务器日志文件。该选项要求RELOAD权限。请注意如果结合--all--database(或-A)选项使用该选项,根据每个转储的数据库刷新日志。例外情况是当使用--lock-all-tables或--master-data的时候:在这种情况下,日志只刷新一次,在所有 表被锁定后刷新。如果你想要同时转储和刷新日志,应使用--flush-logs连同--lock-all-tables或--master-data。

· --force,-f

在表转储过程中,即使出现SQL错误也继续。

· --host=host_name,-h host_name

从给定主机的MySQL服务器转储数据。默认主机是localhost。

· --hex-blob

使用十六进制符号转储二进制字符串列(例如,'abc' 变为0x616263)。影响到的列有BINARY、VARBINARY、BLOB。

· --lock-all-tables,-x

所有数据库中的所有表加锁。在整体转储过程中通过全局读锁定来实现。该选项自动关闭--single-transaction和--lock-tables。

· --lock-tables,-l

开始转储前锁定所有表。用READ LOCAL锁定表以允许并行插入MyISAM表。对于事务表例如InnoDB和BDB,--single-transaction是一个更好的选项,因为它不根本需要锁定表。

请注意当转储多个数据库时,--lock-tables分别为每个数据库锁定表。因此,该选项不能保证转储文件中的表在数据库之间的逻辑一致性。不同数据库表的转储状态可以完全不同。

· --master-data[=value]

该选项将二进制日志的位置和文件名写入到输出中。该选项要求有RELOAD权限,并且必须启用二进制日志。如果该选项值等于1,位置和文件名被写入CHANGE MASTER语句形式的转储输出,如果你使用该SQL转储主服务器以设置从服务器,从服务器从主服务器二进制日志的正确位置开始。如果选项值等于2,CHANGE MASTER语句被写成SQL注释。如果value被省略,这是默认动作。

--master-data选项启用--lock-all-tables,除非还指定--single-transaction(在这种情况下,只在刚开始转储时短时间获得全局读锁定。又见--single-transaction。在任何一种情况下,日志相关动作发生在转储时。该选项自动关闭--lock-tables。

· --no-create-db,-n

该选项禁用CREATE DATABASE /*!32312 IF NOT EXISTS*/ db_name语句,如果给出---database或--all--database选项,则包含到输出中。

· --no-create-info,-t

不写重新创建每个转储表的CREATE TABLE语句。

· --no-data,-d

不写表的任何行信息。如果你只想转储表的结构这很有用。

· --opt

该选项是速记;等同于指定 --add-drop-tables--add-locking --create-option --disable-keys--extended-insert --lock-tables --quick --set-charset。它可以给出很快的转储操作并产生一个可以很快装入MySQL服务器的转储文件。该选项默认开启,但可以用--skip-opt禁用。要想只禁用确信用-opt启用的选项,使用--skip形式;例如,--skip-add-drop-tables或--skip-quick。

· --password[=password],-p[password]

连接服务器时使用的密码。如果你使用短选项形式(-p),不能在选项和密码之间有一个空格。如果在命令行中,忽略了--password或-p选项后面的 密码值,将提示你输入一个。

· --port=port_num,-P port_num

用于连接的TCP/IP端口号。

· --protocol={TCP | SOCKET | PIPE | MEMORY}

使用的连接协议。

· --quick,-q

该选项用于转储大的表。它强制mysqldump从服务器一次一行地检索表中的行而不是检索所有行并在输出前将它缓存到内存中。

· --quote-names,-Q

用‘`’字符引用数据库、表和列名。如果服务器SQL模式包括ANSI_QUOTES选项,用‘"’字符引用名。默认启用该选项。可以用--skip-quote-names禁用,但该选项应跟在其它选项后面,例如可以启用--quote-names的--compatible。

· --result-file=file,-r file

将输出转向给定的文件。该选项应用在Windows中,因为它禁止将新行‘\n’字符转换为‘\r\n’回车、返回/新行序列。

· --routines,-R

在转储的数据库中转储存储程序(函数和程序)。使用---routines产生的输出包含CREATE PROCEDURE和CREATE FUNCTION语句以重新创建子程序。但是,这些语句不包括属性,例如子程序定义者或创建和修改时间戳。这说明当重载子程序时,对它们进行创建时定义者应设置为重载用户,时间戳等于重载时间。

如果你需要创建的子程序使用原来的定义者和时间戳属性,不使用--routines。相反,使用一个具有mysql数据库相应权限的MySQL账户直接转储和重载mysql.proc表的内容。

该选项在MySQL 5.1.2中添加进来。在此之前,存储程序不转储。

· --set-charset

将SET NAMES default_character_set加到输出中。该选项默认启用。要想禁用SET NAMES语句,使用--skip-set-charset。

· --single-transaction

该选项从服务器转储数据之前发出一个BEGIN SQL语句。它只适用于事务表,例如InnoDB和BDB,因为然后它将在发出BEGIN而没有阻塞任何应用程序时转储一致的数据库状态。

当使用该选项时,应记住只有InnoDB表能以一致的状态被转储。例如,使用该选项时任何转储的MyISAM或HEAP表仍然可以更改状态。

--single-transaction选项和--lock-tables选项是互斥的,因为LOCK TABLES会使任何挂起的事务隐含提交。

要想转储大的表,应结合--quick使用该选项。

· --socket=path,-S path

当连接localhost(为默认主机)时使用的套接字文件。

· --skip--comments

参见---comments选项的描述。

· --tab=path,-T path

产生tab分割的数据文件。对于每个转储的表,mysqldump创建一个包含创建表的CREATE TABLE语句的tbl_name.sql文件,和一个包含其数据的tbl_name.txt文件。选项值为写入文件的目录。

默认情况,.txt数据文件的格式是在列值和每行后面的新行之间使用tab字符。可以使用--fields-xxx和--行--xxx选项明显指定格式。

注释:该选项只适用于mysqldump与mysqld服务器在同一台机器上运行时。你必须具有FILE权限,并且服务器必须有在你指定的目录中有写文件的许可。

· --tables

覆盖---database或-B选项。选项后面的所有参量被看作表名。

· --triggers

为每个转储的表转储触发器。该选项默认启用;用--skip-triggers禁用它。

· --tz-utc

在转储文件中加入SET TIME_ZONE='+00:00'以便TIMESTAMP列可以在具有不同时区的服务器之间转储和重载。(不使用该选项,TIMESTAMP列在具有本地时区的源服务器和目的服务器之间转储和重载)。--tz-utc也可以保护由于夏令时带来的更改。--tz-utc默认启用。要想禁用它,使用--skip-tz-utc。该选项在MySQL 5.1.2中加入。

· --user=user_name,-u user_name

连接服务器时使用的MySQL用户名。

· --verbose,-v

冗长模式。打印出程序操作的详细信息。

· --version,-V

显示版本信息并退出。

· --where='where-condition', -w 'where-condition'

只转储给定的WHERE条件选择的记录。请注意如果条件包含命令解释符专用空格或字符,一定要将条件引用起来。

例如:

"--where=user='jimf'" "-wuserid>1" "-wuserid<1" · --xml,-X

将转储输出写成XML。

还可以使用--var_name=value选项设置下面的变量:

· max_allowed_packet

客户端/服务器之间通信的缓存区的最大大小。最大为1GB。

· net_buffer_length

客户端/服务器之间通信的缓存区的初始大小。当创建多行插入语句时(如同使用选项--extended-insert或--opt),mysqldump创建长度达net_buffer_length的行。如果增加该变量,还应确保在MySQL服务器中的net_buffer_length变量至少这么大

5. 基于时间点的恢复

例:
(1)上午10点发生误操作,可以用如下语句备份和BINLOG将数据恢复到故障前
#mysqlbinlog --stop-date="2010-10-31 9:59:59" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

(2)跳过故障时间点,继续执行后面的BINLOG,完成恢复
#mysqlbinlog --start-date="2010-10-31 10:01:00" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

基于位置恢复(不完全恢复)
和基于时间点恢复类是,但是更加精确.因为同一时间点可能有多条SQL语句执行;
例:
#mysqlbinlog --start-date="2010-10-31 9:55:00" --stop-date="2010-10-31 10:05:00" /usr/local/mysql/var/mysql-bin.000013 > /tmp/mysql_restore.sql

该命令将在/tmp/目录下创建小的文件,编辑它找到错误语句前后的位置号,例如前后位置号分别是368312 和 368315
(2)恢复了以前的备份文件后,输入
#mysqlbinlog --stop-position="368312" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

#mysqlbinlog --start-position="368315" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p


7. 参考

mysqldump error

mysqldump error

mysqldump备份有时报错了,内容如下:

mysql@localhost mysql]$ mysqldump --single-transaction -A -uroot -proot123 --master-data=2 > /u01/backup/testbk.sql
Warning: Using a password on the command line interface can be insecure.
Error: Couldn't read status information for table slave_master_info ()
mysqldump: Couldn't execute 'show create table `slave_master_info`': Table 'mysql.slave_master_info' doesn't exist (1146)

错误提示有innodb_index_stats,innodb_table_stats,slave_master_info,slave_relay_log_info,slave_worker_info等几个
使用select语句进行查询时,也会提示这些表不存在

最终解决方法是:删除错误的表后重建

1.查询不可使用的表
show create table mysql.innodb_index_stats;
show create table mysql.innodb_table_stats;
show create table mysql.slave_master_info;
show create table mysql.slave_relay_log_info;
show create table mysql.slave_worker_info;

2.删除上述5张表或有错误的表
drop table mysql.innodb_index_stats;
drop table mysql.innodb_table_stats;
drop table mysql.slave_master_info;
drop table mysql.slave_relay_log_info;
drop table mysql.slave_worker_info;

3.进入data/mysql相应文件夹找到关于5张表的数据文件(.frm,.ibd)并删除
rm -rf innodb_index_stats.*
rm -rf innodb_table_stats.*
rm -rf slave_master_info.*
rm -rf slave_relay_log_info.*
rm -rf slave_worker_info.*

4. 查找表结构
去找$MYSQL_HOME/share/mysql_system_tables.sql,分别search到每一表的建表语句,然后重建设;

mysql innodb_table_stats does not exist

InnoDB: Error: table `mysql`.`innodb_table_stats` does not exist in the InnoDB internal

这个原因很明显 ,是mysql库的innodb_table_stats表损坏了。

再点击 mysql的innodb_index_stats 表,同样损坏。

 

解决方法:

损坏了,当然就是删除重补回来。

1,删除表,进入mysql库,把innodb前缀的表文件删除。

[root@AY140311174146476cc0Z mysql]# pwd
/usr/local/mysql/data/mysql
[root@AY140311174146476cc0Z mysql]# rm -f innodb_*

2,重新执行sql文件语句。当然语句来自安装包。

具体路径,如5.6为例:mysql-5.6.19/scripts/mysql_system_tables.sql

语句贴出来吧

CREATE TABLE IF NOT EXISTS innodb_index_stats (
    database_name           VARCHAR(64) NOT NULL,
    table_name          VARCHAR(64) NOT NULL,
    index_name          VARCHAR(64) NOT NULL,
    last_update         TIMESTAMP NOT NULL NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    /* there are at least:
    stat_name='size'
    stat_name='n_leaf_pages'
    stat_name='n_diff_pfx%' */
    stat_name           VARCHAR(64) NOT NULL,
    stat_value          BIGINT UNSIGNED NOT NULL,
    sample_size         BIGINT UNSIGNED,
    stat_description        VARCHAR(1024) NOT NULL,
    PRIMARY KEY (database_name, table_name, index_name, stat_name)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0
 
 
 
CREATE TABLE IF NOT EXISTS innodb_table_stats (
    database_name           VARCHAR(64) NOT NULL,
    table_name          VARCHAR(64) NOT NULL,
    last_update         TIMESTAMP NOT NULL NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    n_rows              BIGINT UNSIGNED NOT NULL,
    clustered_index_size        BIGINT UNSIGNED NOT NULL,
    sum_of_other_index_sizes    BIGINT UNSIGNED NOT NULL,
    PRIMARY KEY (database_name, table_name)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0

 

然后,再查询相关的innodb表。看下是否还有错误 。

这个错误到此解决了。

mysql reset slave / reset master

RESET SLAVE

官方的解释如下

1)RESET SLAVE makes the slave forget its replication position in the
master's binary log. This statement is meant to be used for a clean
start: It clears the master info and relay log info repositories,
deletes all the relay log files, and starts a new relay log file. It
also resets to 0 the replication delay specified with the MASTER_DELAY
option to CHANGE MASTER TO. To use RESET SLAVE, the slave replication
threads must be stopped (use STOP SLAVE if necessary).

2)RESET SLAVE does not change any replication connection parameters
such as master host, master port, master user, or master password, which
are retained in memory. This means that START SLAVE can be issued
without requiring a CHANGE MASTER TO statement following

reset slave

其实,它是直接删除master.info和relay-log.info文件,并删除所有的relay log,然后重新生成一个新的relay log,即使relay log中还有SQL没有被SQL线程apply完。

但是RESET SLAVE有个问题,它虽然删除了上述文件,但内存中的change master信息并没有删除,此时,可直接执行start
slave,但因为删除了master.info和relay-log.info,它会从头开始接受主的binlog并应用。(注意:这里所说的从头是说:reset的时候,正在接受的主的binlog,从新接受这个binlog).如果SQL
thread 正在复制临时表的过程中,执行了stop slave ,并且执行了reset slave,这些被复制的临时表将被删除。

reset master 做了什么?

1. reset master 将删除日志索引文件中记录的所有binlog文件,创建一个新的日志文件 起始值从000001 开始,

2. reset master 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master
命令不被支持,reset master 将master 的binlog从000001 开始记录,slave 记录的master log
则是reset master 时主库的最新的binlog,从库会报错无法找的指定的binlog文件。

Mysql Replicate Relay log read failure

一、描述

Mysql主从复制模式中,slave上报错 “relay log read failure”,导致主从同步停止。

mysql> show slave status\G
...
Master_Log_File: dd-bin.002542
Relay_Master_Log_File: dd-bin.002540
Exec_Master_Log_Pos: 950583017
Last_Error: Relay log read failure:...
...

二、分析

      报错信息为从库“无法读取relay log 里的条目”,可能原因为master库的binglog错误,或slave库的中继日志错误。或者为网络问题及bug原因。

      一般是由于网络故障或slave库压力过大,导致relay-log格式错误造成的。找到当前已经同步的时间点,重新设置主从同步,就会产生新的中继日志,恢复正常。

三、问题处理

从"show  slave  status\G"的输出中,找到如下信息:

Relay_Master_Log_File: dd-bin.002540     //slave库已读取的master的binlog

Exec_Master_Log_Pos: 950583017           //在slave上已经执行的position位置点



    停掉slave,以slave已经读取的binlog文件,和已经执行的position为起点,重新设置同步。会产生新的中继日志,问题解决。

(不需要指定host,user,password等,默认使用当前已经设置好的)

mysql>stop slave;

mysql>change master to master_log_file='dd-bin.002540' , master_log_pos=950583017;

mysql>start slave;



四、验证结果

再次查看,错误已经解决,slave 开始追 master 的日志

mysql>show  slave status\G

Exec_Master_Log_Pos: 225927489        //slave上已经执行的position已经变化

Seconds_Behind_Master: 58527            //slave  落后主库的时间,单位秒



过几秒钟,再次查看。离与master同步更近了

mysql>show  slave status\G

Exec_Master_Log_Pos: 307469867

Seconds_Behind_Master: 29570