MySQL在整个网络环境中使用客户端/服务器(Client/Server)架构运行。换言之，其核心程序扮演着服务器角色，而各个客户端程序连接到服务器并提出请求。MySQL的安装涉及以下主要组件: MySQL Server, Client程序和MySQL非客户端工具。

2.2.1 MySQL Server

MySQL Server或者说mysqld，实际上是一个数据库服务器程序。它管理着对磁盘数据库和内存的访问。MySQL Server进行多线程操作，它支持多个客户端连接的同时访问。为了更好地管理数据库内容，MySQL Server的特色架构模型支持多种存储引擎以处理不同类型的表(例如，它同时支持事务和非事务表)。

由于MySQL Server此特性配置可能随时间变化而有所改动，因此当你下载新版本MySQL时候，请仔细阅读相关版本文档。

 

请您清楚了解我们的用词，server(服务器)和host(主机)的用词区别。在这里Server是指软件(MySQL server程序mysqld)。Server的特征中有它的版本号，指的是哪些特性包括，哪些不包括等。而host是指server程序运行所在的物理机。Host的特征中包括了硬件配置，所运行的操作系统，其网络地址等等。一个host可以有多个mysqld实例在上面同时运行。

 

2.2.2 Client程序

客户端程序被用于和server进行通信以修改服务器端server管理的数据库信息。MySQL提供了多种client端工具程序：

• MySQL Workbench, 一种作为访问Mysql Server的图形化的前端工具(具有MySQL Query Browser和MySQL Administrator相关功能，MySQL Query Browser和MySQL Administrator现已不再提供更新)。
• mysql，一种文本形式的命令行前端工具。
• 其他命令行客户端工具包括导入数据文件用的mysqlimport，生成备份的mysqldump, 作为服务器管理的mysqladmin,和用于检查数据库文件完整性的mysqlcheck。

 

MySQL客户端/服务器(Client/Server)模型：

MySQL可运行于Windows, Unix和Linux平台上，但客户端和服务器之间的沟通并不受限于所运行的操作系统。客户端程序和服务器之间的连接可以在同一台主机上进行，也可以是不同的主机间进行，且客户端主机和服务器主机不需要操作系统保持一致。例如，客户端程序可以运行于Windows上，而所连接的Server则运行在Linux host上。

 

大多在此讨论的概念都是指针对于MySQL运行的系统。除了一些特定的平台说明外，这里”Unix”一般都是指包括Linux和其他的Unix-like操作系统。

 

2.2.3 通信协议

以下详细描述了和MySQL server进行交互所使用各种不同通信协议：

• TCP/IP – 传输控制协议(Transmission Control Protocol)/互联网协议(Internet Protocol)，是一套被用于连接互联网上各主机的通信协议。TCP/IP一开始是用于UNIX操作系统建立互联网通信的。现在它已经成为了一种网络数据传输的事实标准。即便那些拥有自己通信协议的网络操作系统，如Netware也支持TCP/IP协议。
• Unix Socket – 在计算机世界，一个socket是一种内部进程通信形式，它被用于在相同主机上形成进程间的双向通信连接点(在本地系统上的一个物理文件)。
• 共享内存(Shared Memory) – 一个在程序间传送数据的有效方法。一个程序会建立一个内存区以提供其它受允许的进程进行访问。Windows显式”passive”连接模式仅可工作于(Windows系统)主机中。
• NT管道 – 这种命名管道设计更偏向于客户端-服务器通信，它们更像socket：除了用于通常的读写操作外，Windows命名管道也同时对server应用支持显式”passive”被动连接模式。仅在单独(Windows平台)主机中运行。

 

2.2.4 MySQL非客户端工具

有这么些程序运行时独立于server之外。它们首先在操作时并不会和server建立连接。如myisamchk。它执行表检查及修复操作。其它此类型程序有myisampack，它用于建立压缩的只读版本的MyISAM表。这两个工具都可以直接对MyISAM表文件进行访问，且独立于mysqld数据库server之外。

 

章节中会介绍MySQL所使用的客户/服务器模型。你会了解：

 

• 对MySQL C/S模式的描述
• 理解通信协议(Communication Protocols)
• 理解服务器如何支持存储引擎
• 关于MySQL如何使用内存和磁盘空间的基础知识

 

2.1 MySQL架构概览

 

MySQL架构实际上是一组为了完成数据库服务器任务而协同工作的相关功能组合。这些功能集包含超过50,0000行代码。下图中对其中的功能子系统进行了分层展示，层级之间通过相应API进行交互。多数情况下，每个子系统会对信息进行接收，处理然后再传送给下一个子系统以完成所分配的任务。子系统之间相对独立，这样就会有更大的自由度(如由于执行语句的存储引擎独立性，客户端不必知道哪个存储引擎执行其请求)。

 

2.1.1 核心共享子系统(Core Shared Subsystems)

在MySQL中的每个子系统都能自成一章。由于篇幅所限，这里仅对每个核心共享子系统进行简单描述，以给大家对其性能特点有一个概括性理解。

 

进程，线程和资源管理器(Process, Thread and Resource Management):

MySQL使用了一个基于线程的服务器架构，允许各种执行线程(或称为轻量级进程)访问核心共享资源。MySQL这种的多线程单进程架构能保证多个执行线程之间不会相互冲突或覆盖重要数据。使用基于线程的服务器架构最值得注意的优点是：

• 节约成本 – 和进程相比，线程的建立和销毁成本更低。新的线程可使用其父进程的地址空间而不需要额外的地址空间。
• 切换代价低 – 由于线程运行于相同的服务器进程空间中, 因此线程之间的切换代价很小。
• 极小的开销 – 由于线程可对父进程地址空间进行访问，因此在共享资源下开销也变得极小。

 

缓存(Cache/Buffer)管理:

此子系统专注于缓冲并取回服务器进程中所有线程执行所用的大量数据类型。由于已经将返回的数据进行内存缓存，因此数据缓存使得MySQL可以降低大量对于基于磁盘I/O代价昂贵的操作。

 

网络管理(Networking Management):

此子系统的职责是通过处理在多平台间发送和接收带有MySQL连接请求和命令的网络数据包这样的工作，使得各种通信协议(TCP/IP, 命名管道Named Pipes等)对连接线程变得透明。它也包括了处理安全套接字层(Secured Socket Layers: SSL)这样的工作。

 

日志管理:

这个子系统是为了将各种日志事件子类被维护在一个日志类下而建立的。这样能使得开发者能在不破坏系统核心功能的情况下增加日志和日志事件。通过对日志系统中子系统的区分。各种系统活动(启动，多语句事务，自动增量auto-increment值改变等)就可以通过子类事件进行记录。

 

访问及授权管理:

此子系统定义了所有为执行命令所需的GRANT权限并主要用于保证客户端和服务器间的安全。它会验证用户在登陆过程中的访问权限及查询权限。此子系统也包含了一些对授权表的内存版本修改功能及密码生成功能。

 

2.1.2 存储引擎接口(Storage Engine Abstraction)

此子系统使得MySQL可以在系统架构中使用不同的表数据handlers(处理子程序)。尽管不是所有存储引擎都完整实现了相关handler API，但大部分独立的handler API都被用于转换数据、schema和索引格式，以使其符合MySQL内部记录格式所需(内存记录格式)。

 

2.1.3 查询解析，优化和执行

由于这些子系统负责接收SQL语句，将语句解构为各种数据结构并以最佳路径进行执行，因此它们被称为MySQL服务器的大脑。

• 查询解析：

这是一个将SQL语句解析为一个抽象语法的过程。由于此过程非常复杂，因此解析时不能对任何用户变量进行改变。

• 优化：

此子系统负责找到查询的最优执行计划。

• 执行：

此子系统又被称为语句执行单元，负责按照通过SQL命令解析和优化后所得的最优执行路径进行执行。执行进程的基本功能是都有一个指针作为其第一参数以将结构数据包发回给客户端。

 

2.1.4 查询缓存(Query Cache)

不像其它MySQL子系统，此“子系统”组件由一系列类组成。它不仅负责缓存被执行的SQL命令，还存储命令执行后的结果。

【诗檀软件汪伟华】 MySQL Replication 复制高可用配置方案

 

MySQL Replication 复制高可用配置方案:

 

本文目的

对MySQL高可用架构原理进行学习总结。

 

相关参考

• MySQL Replication:

http://dev.mysql.com/doc/refman/5.6/en/replication.html

• MySQL Replication Pausing:

http://dev.mysql.com/doc/refman/5.6/en/replication-administration-pausing.html

 

架构原理

 

MySQL Replication

MySQL Replication可以使得数据从一个MySQL数据库服务器(主库)被复制到一个或其他更多MySQL数据库服务器(备库)上。复制默认是异步模式。

 

FAQ

问题1:

我该如何强制阻止主库更新，直到备库的同步作业赶上主库呢？

回答:

可使用以下步骤：

1. 在主库上，执行以下命令:

mysql> flush tables with read lock; mysql> show master status;

查看show命令输出，并记录下replication坐标(当前主库binary日志文件名和其位置)。

2. 在备库上，执行以下语句，其中master_pos_wait()函数参数值为之前所获取的replication坐标值。

mysql> select master_pos_wait(‘log_name’, log_pos)

此语句会一直处于运行状态直至备库同步到其指定的日志文件和位置时才结束。这时，语句返回且表明备库和主库同步完成。

3. 在主库中，执行以下命令重新允许主库开始处理更新操作。

mysql> unlock tables;

 

问题2:

我应该如何使用Replication来提升系统性能？

回答:

将一个服务器作为主库并使其负载有的写操作。同时按你的预算和机架空间配置尽可能多地的备库, 将读操作分布到主库和备库上。你也可以在备库上启用–low-priority-updates(仅对myISAM)和–delay-key-write=ALL等参数项来提升备库速度。在这种情况下，备库上使用非事务型MyISAM表以替代InnoDB表，减少了事务开销，从而获得更快的速度。

 

问题3:

如何量化MySQL replication对系统的性能提升？

回答:

MySQL replication对于那些需要处理频繁读和非频繁写的系统非常有益。理论上，通过在进行单主库多备库建设时，你可以增加更多备库来扩展你的系统，直到用完所有网络带宽，或直到你的更新负载已经达到主库所能达到的最大值时为止。

为了在建设前评估需备库数量和性能提高比率，你必须了解你的查询模式，并以主库和备库的读写关系为基准进行判断。下面用了一个简单计算模型来显示你从replication中可以获得的系统提升:

首先统计每秒相对的读(read)和写(write)次数。

假设当前系统负载中包含10%写和90%读，而我们已经确定读写基准关系为读的次数为1200减去写次数的两倍。换言之，系统可以在无写操作的情况下达到每秒1200次读，其平均写时间比平均读时间慢2倍, 两者的关系是线性的。假设主库和备库性能相同，且我们使用1主N备。那么，对每个服务器(主库或备库)，我们得出以下模型：

reads = 1200 – 2 * writes reads = 9 * writes / (N + 1) (读被分布在各个服务器上, 写则被replicate到多个备库上) 9 * writes / (N + 1) + 2 * writes = 1200 writes = 1200 / (2 + 9/(N + 1))

最后的等式表明在N个备库的情况下和写之间的关系，通过分析可得出以下结论：

• 如果N=0（意味着无replication），系统每秒可处理约1200/11=109次写。
• 如果N=1，可得到每秒为184次写。
• 如果N=8，每秒写提升至400次。
• 如果N=17，每秒写为480次。
• 最终N趋于无穷大，我们可获得约600次写每秒。系统性能提升约5倍。然而，仅8台备库的情况下，我们就能获得大约4倍的性能提升了。

以上这些计算都是在假设有无限带宽且没有其他巨大负面因素的基础下。在许多情况下，你可能并不能使用类似此模型来如此精确地预估增加N台replication备库后的性能效果。然而，通过回答以下问题应该能帮助你判断大致增加多少replication会对你的系统性能有一定的提高：

• 系统的读/写比率是多少？
• 如果你降低读负载，服务器可更多承贷多少写负载？
• 你的网络带宽足够多少台备库使用？

 

问题4:

如何分辨主库正使用statement-based还是row-based binary 日志格式。

回答:

mysql> show variable like ‘binlog_format’;

值显示模式为STATEMENT, ROW或 MIXED。对于MIXED模式，默认在replication时使用statement-based，在某些情况，如非安全语句，则会自动切换使用row-based日志模式。

 

问题5:

在replication复制到备库时，该如何避免GRANT和REVOKE语句也被备库复制？

回答:

启用备库时, 使用 –replicate-wild-ignore-table=mysql.%参数项以忽略从主库mysql数据库中复制表。

 

 

 

 

环境准备

 

软件准备

1. vbox虚拟软件:

https://www.virtualbox.org/

2. RedHat Enterprise Linux 6.6 64bit介质:

rhel-server-6.6-x86_64-dvd.iso

3. SecureCRT
4. FlashFXP或其他FTP软件

 

节点安装

MySQL Replication要求至少2个节点，用于主备(Master-Slave)。

这里我们先装1个节点，安装Linux系统和Mysql 5.6. 然后进行虚拟机clone，克隆出2节点。

 

 

建立时选桥接网卡即可。

 

Linux安装

使用vbox新建一个虚拟机，根据你的介质初步选择你的虚拟机系统。之后启动虚拟机，并将介质iso文件加载至虚拟机光驱, 之后的Linux安装设置大致都默认即可。

 

这里的主机名hostname按情况填写即可(ex1.dbdao)

 

 

 

密码如果偏弱，可能会有警告，Use Anyway即可。

勾选Review and modify partitioning layout, 这样就在后一页中提供磁盘分区的详细信息。

Format

Write Changes to disk.

这里选Customize now，将Desktop相关的组件都先装上，以便可以提供Window X桌面支持。

 

 

 

安装好后重启。

 

装好后第一次启动会进入设置界面：

 

选No.

因为这里虚拟机设置了1G内存，不足以开启此功能，但是我们这里仅是做实验，因此不必关心此警告。即便内存够，也不用开启。

 

使用root登陆成功

Username: root

Password: <passowrd>.

 

安装vbox guest additions:

 

检查网络

检查Yum

如果Yum不存在，使用rpm找到rhel6.6 iso中的yum安装包进行安装。

 

shell> rpm -qa|grep yum shell> cd /media shell> touch cdrom shell> mount /dev/cdrom ./cdrom shell> cd /etc/yum.repos.d shell> touch rhel6.6-self.repo shell> vi rhel6.6-self.repo

 

检查Firefox(可选)

shell> yum search firefox shell> yum install firefox

调整网卡IP，DNS设置，vbox虚拟机网卡使用Bridged桥接网卡模式。检查是否可上网(MySQL yum安装需要网络可访问)。

 

检查SSH

shell> rpm -qa|grep openssh shell> service sshd status

 

检查FTP

shell> rpm -qa|grep vsftp shell> yum search vsftp shell> yum install vsftpd shell> service vsftpd status

 

安装完后还未启动，需要设置。

shell> cd /etc/vsftpd shell> vi /etc/vsftpd/vsftpd.conf shell> vi user_list

以下为要更改的选项:

anonymous_enable=NO

ascii_upload_enable=YES

ascii_download_enable=YES

新增 userlist_deny 选项， user_list 文件中的用户才允许访问：

userlist_deny=NO

 

 

作为Oracle OpenWorld 2015年大会的一部分，Mysql Central @ OpenWorld将在10月25~29日的San Francisco举行。

我们鼓励并热切期待MySQL客户，合作商和社区成员提交建议并参与展现：

• 最佳实践
• 实例研究
• 使用世界上最流行的开源数据库进行工作所获得的价值
• 新特性讨论及使用
• 课题教程

MySQL Central @ OpenWorld将会围绕6个主题进行开展：

• 性能及可扩展性
• 高可用性
• NoSQL和大数据
• 云技术及操作开发
• 数据库管理
• 架构和应用开发

更多细节和请求提交指导可以在这里找到。相关会议建议及参与的提交截止日为2015年4月29日。

快来提交您的想法并积极参与吧！

关于MySQL认证
By Denis Truffaut

MySQL是一个数据库管理系统。其认证被用于测试考生对于所有MySQL相关的存储和查询技术的知识掌握情况。

当前可在Oracle官网中可查到MySQL认证有以下两种：

• Oracle Certified Professional, MySQL 5.6 Database Administrator
• Oracle Certified Professional, MySQL 5.6 Developer

相关认证需要通过的考试：

• MySQL 5.6数据库管理OCP：1Z0-883
• MySQL 5.6开发员OCP：1Z0-882

值得注意的是下列旧认证将在2014年3月15日后过期, 如果你已经拥有以下认证，那么你需要考虑是否参与认证升级：

• Oracle Certified Associate, MySQL 5
• Oracle Certified Expert, MySQL 5.1 Cluster Database Administrator
• Oracle Certified Professional, MySQL 5 Database Administrator
• Oracle Certified Professional, MySQL 5 Developer

对于MySQL认证考试的反馈

当写这篇文章时，我才通过MySQL5 开发员认证。然而，我认为获取这些认证需要对相关知识有比较高的掌握度。

考试的题目都不简单，建议大家看题，并在考试时按顺序回答问题。注意，你可以对没把握的题先标记起来(使用【Mark】)然后在之后回到标记的题目。在最后回顾时，考试会提供对所有未回答或被标记问题的总览，在得到你的最后确认后，考生再按下【Finish】按钮完成考试。

最后，为了合理控制你的考试时间，在屏幕右上角有一个计时器方便你查看所用时间。

考试资源准备

考试中所需文档资源可以从下面找到：

• MySQL 5.6 在线文档
• MySQL 5.6数据库管理员OCP考试详情及考点了解
• MySQL 5.6数据库开发员OCP考试详情及考点了解

OCP认证：请注意通过规则

每个考试需耗时90分钟，约包含70道题目，这意味着每题77秒的考虑时间。

你需要至少获得总考分的60%来通过考试。不过具体是否是此比例，你需要查看Oracle官网中的OCP相关考试说明来了解。

如果未能通过考试，你需要过14天后方能尝试申请重考。

MySQL OCP：总结 

为什么尝试此认证:

• 相关费用(约1077RMB)，性价比高
• 一个考验自己知识掌握度的好方法
• 一个高级别认证
• 一个证明你是否专业的证据
• 在求职市场上的一个快速认可
• 全球知名品牌: Oracle

この記事で

症状

原因

解决策

方法

 

適用範囲：

MySQLサーバのバージョン4.0以上
この資料の情報は、すべてのプラットフォームに適用されます。

 

症状

test.t1をアクセスしてみると，以下のエラが現れる：

150512 16:30:01 [ERROR] MySQL is trying to open a table handle but the .ibd

file for

table te st/t1 does not exist.

Have you deleted the .ibd fil e from the database directory under

the MySQL datadir, or have you used DISCARD TABLESPACE?

See http://dev.mysql.com/doc/refman/5.1/en/innodb‐troubl eshooting.html

how you can resolve the problem.

 

原因

このエラの原因はテーブルt1の.ibdファイルがないからである。これはどんな文でもテーブルT1に対して実行出来ない。

エラ自身でそしてそのファイルがまだ存在しているかを確認する：

shell> ls ‐lahR /var/lib/mysql/

/var/lib/mysql/test:

total 21G

drwx‐‐‐‐‐‐ 2 mysql mysql 32K may 12 03:55 .

drwxr‐xr‐x 7 mysql mysql 4,0K nov 10 2014 ..

…

‐rw‐rw‐‐‐‐ 1 mysql mysql 8,6K may 12 03:16 t.frm

‐rw‐rw‐‐‐‐ 1 mysql mysql 20M may 12 13:37 t.ibd

‐rw‐rw‐‐‐‐ 1 mysql mysql 8,5K ago 10 2014 t1.frm

‐rw‐rw‐‐‐‐ 1 mysql mysql 8,5K may 12 03:16 t2.frm

‐rw‐rw‐‐‐‐ 1 mysql mysql 128K may 12 03:16 t2.ibd

…

もう一度MySQLエラログを確認して、エラが現れるときに、つまり、truncate tableを実行しているときに見られる。その文は自身の.ibdファイルを再構造できないから、ファイルがなくした：

140810 5:05:03 InnoDB: TRUNCATE TABLE test/t1 failed to create a new

tablespace

 

解决策

テーブルを再構造する：

1. Drop table:

mysql> DROP TABLE test.t1;

The following error may be seen in the error log afterwards, but it’s basically saying the

tablespace was still present in InnoDB Data Dictionary and that eventually was removed:

150513 14:49:08 InnoDB: Error: table ‘test/t1’

InnoDB: in InnoDB data dictionary has tables pace id 607381,

InnoDB: but tablespace with that id or name does not exist. Have

InnoDB: you deleted or moved .ibd files?

InnoDB: This may also be a table created with CREATE TEMPORARY TABLE

InnoDB: whose .ibd and .frm files MySQL automatically removed, but t he

InnoDB: table still exists in the InnoDB internal data dictionary.

InnoDB: Please refer to

InnoDB: http://dev.mysql .com/doc/refman/5.1/en/innodb‐troubleshootingdatadict.

html

InnoDB: fo r how to resolve the issue.

InnoDB: We removed now the InnoDB int ernal data dictionary entry

InnoDB: of table `test`.`t1`.

 

2. 再びCreate table
3. テーブルのアクセスをテストして、実行できるかを確かめる。 (ex: optimize table)

mysql> OPTIMIZE TABLE test.t1;

 

適用範囲：
MySQLのエンタープライズバックアップバージョン3.5以上
MySQLサーバのバージョン4.0以上
この資料の情報は、すべてのプラットフォームに適用する。

 

症状

InnoDBエンジンはデータとログファイルのロジクール整合性に頼っている。

 

InnoDBには予想出来ない行為があるかも知れない。例えば、異なる環境から混ぜたファイル損害についてのシャットダウンとエラ。

 

エラの例：

2015‐03‐18 11:24:44 11904 [Note] InnoDB: Database was not shutdown normally!

2015‐03‐18 11:24:44 11904 [Note] InnoDB: Starting crash recovery.

2015‐03‐18 11:24:44 11904 [Note] InnoDB: Reading tablespace infor mation from the .ibd

files…

2015‐03‐ 18 11:24:44 11904 [ERROR] InnoDB: Attempted to open a previously opened

tablespace. Previous tablespace test/t uses space ID: 3695 at filepath: ./test/t.ibd.

Cannot open tablespace test/#sql2‐1ab0‐5 which uses space ID: 3695 at filepath:

./test/#sql2‐1ab0‐5.ibd

2015‐03‐18 11:24:44 7fe 914a04720 InnoDB: Operating system error number 2 in a file

operation.

InnoDB: Th e error means the system cannot find the path specified.

InnoDB: If you are installing InnoDB, remember that you must creat e

InnoDB: directories yourself, InnoDB does not create them.

InnoDB: Error: could not open single‐table tablespace file ./test/#sql2‐1ab0‐5.ibd

 

原因

バックアップが古いInnoDBデータあるいはログファイルのディレクトリにリカバリした。

 

解决策

InnoDBファイルを整合性を確保する方法はバックアップを空けたディレクトリにリカバリすることである。

 

MySQL Enterprise Backup (MEB) – リカバリする：

Important

• ある完全なリカバリを実行する時に（例えば、バックアップデータを新しいMySQLサーバに使われる時。あるいは今のMySQLサーバすべてのデータを交換するとき。）目標データは古いデータファイルあるいはいらないデータファイルを含んでいないことを確保してください。（これは人工的にファイル位置を削除する必要があるかも知れない。– datadir と –innodb_data_file_path二つのオプションを使ってください）；さもなければ、–forceオプションをrestoreコマンドで古いデータを上書きされる。コマンドは古いデータを上書きする。使用–use-ttsオプションで作成されたバックアップリカバリは同じクリンアップが必要としていない。リカバリする部分に対して、わざわざバックアップする必要がない。

この記事で

症状

変更

原因

解决策

REPAIR TABLE

人工的にデータファイルを編集する

リファレンス

 

このファイルはOracle Support’s Rapid Visibility (RaV) プロセスで発信するので、独立した技術テストに制約されていない。

 

適用範囲：
MySQLサーバのバージョン4.1以上
この資料の情報は、すべてのプラットフォームに適用されます。

 

症状

CSV表テーブルをアクセスしてみると、以下のエラが現れた。

ERROR 1194 (HY000): Table ‘t1’ is marked as crashed and should be repaired

 

テーブルの損害は以上のエラと示せないから。データに損害によって、SELECTも使えるが、こわれたデータが返される。

 

変更

一般的に、以下の状況が起こったら、現れる：

• MySQLのシャットダウン：これはオペレーションシステムシャットダウンを含んでいる、例えば電源が切れたなどの状況。
• データディレクトリのディスクが足りない。

 

原因

CSVテーブルがこわれた。前に言ったように、これは非常状態に起こる。

 

注：SELECT 文が損害で失敗した場合に、INSERT文は実行し続ける。CSVテーブルに対して、行をインサートする。

 

.CSVがそのテーブルの損害が及ぼす。例えば、テーブルcsvtest.t1の場合、そのファイルは${datadir}/csvtest/t1.CSに${datadir}はMySQLインディクスに使われるデータディレクトリである。損害は常に一行がクリンアップアップされたと見える。それに次の行に同一の列から始まる：

1,”2014-01-11 12:32:22″,”abc”

2,”2014-01-15 13:11:12″,”def”

3,”20144,”2014-01-28 18:00:19″,”jkl”

5,”2014-02-04 12:49:30″,”mno”

6,”2014-02-04 13:22:25″,”pqr”

 

前のインディクスで第三行がこわれた、そして二つの部分を含んでいる：

• 3,”2014

これはクリンアップされた行である

• 4,”2014-01-28 18:00:19″,”jkl”

これは次の行

 

解决策

解決策が二つの方法がある：

REPAIR TABLEを使ってください

人工的にデータファイルを編集する

 

REPAIR TABLE

REPAIR TABLEコマンドは一番簡単な方法だが、テーブルがシャットダウンと標識されたときだけにこのコマンドを実行できる。実行方法は損害が発生する前にデータファイルをクリンアップする：

REPAIR TABLE csvtest.t1;

 

アラーム： REPAIR TABLE for a CSV table は初めての行を見つけたら、テーブルをクリンアップするので、データがなくなる！

 

人工的にデータファイルを編集する

ファイルエディタで人工的にテーブルのこわれた部分を削除することで、データファイルを編集できる例えば以上のインディクスによって、ファイルを変更できる：

1,”2014-01-11 12:32:22″,”abc”

2,”2014-01-15 13:11:12″,”def”

4,”2014-01-28 18:00:19″,”jkl”

5,”2014-02-04 12:49:30″,”mno”

6,”2014-02-04 13:22:25″,”pqr”

 

データファイルのコピを実行することを勧めている。

 

この方法のメリットは这种方法的优点是，你必须改变更细粒度的控制，例如上述更改，仅行id=3将丢失，而不是id> =3的所有行。

 

データファイルをコピするには以下の通りステージを使ってください（LinuxあるいはUnix；似たようなステップWindowsに利用できる）csvtest と t1をテーブルのデータベースと名前を代わってもいい：

1. mysql> LOCK TABLES csvtest.t1 WRITE;
2. mysql> FLUSH TABLES csvtest.t1;
3. shell$ ls ‐l /var/lib/msyql/csvtest/t1.CSV
4. shell$ cp /tmp/t1.CSV /var/lib/msyql/csvtest/t1.CSV
5. Make sure the /var/lib/msyql/csvtest/t1.CSV has the same owner and access permissions as found

in step 3.

6. mysql> UNLOCK TABLES;
7. mysql> SELECT * FROM csvtest.t1 WHERE id = 6;

 

ステップ7.のクエリでCSVファイルを最後の行を見つけ出せるを確認する。

 

適用範囲：
MySQLサーバのバージョン5.5以上
この資料の情報は、すべてのプラットフォームに適用する。

症状

GUIクライアントから関数文法を作成する：

CREATE FUNCTION `mydb`.`f_seq_gen` (`applicationid` text) RETURNS INT

BEGIN

DECLA RE nextval bigint(20);

select seqno into nextval from mydb.seqgen where application_id =

applicationid;

update mydb.se qgen SET seqno = seqno + 1 where application_id = applicationid;

RETURN nextval;

END

 

けど失敗した：

ERROR 1548 (HY000): Cannot load from mysql.proc. The table is probably

corrupted

 

原因

テーブルmysql.procがこわれたあるいはテーブル構造が違っている。

一般的に、これは違ったバーションのアップグレードやダンプ/リカバリによるものである。

 

解决策

まずは：

CHECK TABLE `mysql`.`proc` EXTENDED;

REPAIR TABLE `mysql`.`proc`;

 

そして格納した関数を再構造する。

 

失敗した場合は、テーブル構造が違っている可能性が大きいである。

 

解決策は以下の通りを実行して

mysql_upgrade ‐uroot ‐‐force ‐p

システムテーブルを正確な構造に戻る。

 

もしすべてのデータテーブルを検索したくなければ（時間をかかりすぎ），オプションupgradesystemtablesを指定してください。

 

適用範囲：

MySQLサーバのバージョン5.15.1[リリース5.1]

MySQLサーバのバージョン4.0以上

この資料の情報は、すべてのプラットフォームに適用する。

 

症状

電源が切れたからシャットダウンした後、MySQLを起動するときに，以下のエラになった：

130227 11:54:17InnoDB: Assertion failure in thread 4096 in file fil0fil.c line 3959

InnoDB: We intentionally generate a memory trap.

InnoDB: Submit a detailed bug report to http://b ugs.mysql.com.

InnoDB: If you get repeated assertion failures or crashes, eve n

InnoDB: immediately after the mysqld startup, there may be

InnoDB: corruption in the InnoDB tablespace. Please refer t o

InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing‐recov ery.html

InnoDB: about forcing recovery.

130227 11:54:17 ‐ mysqld got si gnal 11 ;

 

原因

これはInnoDBがファイルシステムレベルのデータファイルがこわれたからである。

 

注意事項

オペレーションシステムあるいは一部のディスクハードウェアが誤ったことをflushtodiskオペレーションに報告するかもしれない。mysqld flushが起こったと報告した、実際には起こっていない。それでディスクに書き込むときによく変化があるので、最悪の場合、電源が切れたから、InnoDBデータベースがこわれる。SCSIディスクコントローラーあるいはもともとディスクにあるバック電池が持っているディスク高速メモリーでファイルフラシュを加速する。

 

解决策

以下のステップでリカバリできる：

1. MySQLが閉められて、すべてのデータベースファイルをコピすることでバックアップを作成する。これは大事なことなんだから、innodb_force_recoveryを使ったら、また損害がひどくなる。
2. innodb_force_recoveryを実行した状態でMySQLを起動する。大きいな数値が必要になるかもしれない、リカバリモードで、できるだけ多くのデータをダンプしてください。そのあとInnoDBを初期化することを確保してください。このプロセスはこのガイドブックに記されている：Starting

InnoDB on a Corrupted Database.

3. バックアップからリカバリする。一般的に、これは唯一成功できる方法である。もしこの方法を選んでいれば、まずはこわれたファイルのバックアップを作成して、それからデータをリカバリする。