手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2008年12月的文章

InnoDB数据表空间文件平滑迁移

为了保持作者原有的格式,和他的URL版本的邮箱,我就不做更改了。其实世界上很多事情都是那么巧的,php focus群里的朋友还在问我数据库是否能够直接拷了就能使用。我的解释是4.0以下的版本都可以拷的,从4.1开始尽量使用mysqldump,但是sundj说,对于MYISAM类型的数据库和表,是可以直接COPY的。对于INNODB则不行。然后打开日常订阅的一些RSS,就发现了这篇文章 。。。套用范伟老师的话:缘份呐

原文如下:

作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究。

前言

InnoDB存储引擎满足了MVCC和ACID特性,在需要支持事务的环境下必不可少。有些环境下,采用InnoDB可能效果比MyISAM还要来 的好。不过,在很多人眼中看来,InnoDB表空间文件由于无法实现跨服务器平滑迁移,因此不愿意使用。实际情况真是这样吗?本文就来探讨一下 InnoDB表空间文件的平滑迁移可能性。

如何迁移?

从MySQL文档中我们了解到,InnoDB的表空间可以是共享的或独立的。如果是共享表空间,则所有的表空间都放在一个文件 里:ibdata1,ibdata2..ibdataN,这种情况下,目前应该还没办法实现表空间的迁移,除非完全迁移,因此不在本次讨论之列;我们只讨 论独立表空间的情况。

不管是共享还是独立表空间,InnoDB每个数据表的元数据(metadata)总是保存在 ibdata1 这个共享表空间里,因此该文件必不可少,它还可以用来保存各种数据字典等信息。数据字典中,会保存每个数据表的ID号,每次发生数据表空间新增时,都会使 得该ID自增一个值(++1),例如:CREATE TABLE xx ENGINE = InnoDB / ALTER TABLE xx ENGINE = InnoDB 都会使得ID值增加。
有了上面的理解,想要实现InnoDB表空间文件的平滑迁移就很容易了,呵呵。下面是一些例子:
假定我们有2台DB主机,一个是A,一个B;现在想把A上的某个InnoDB表空间文件迁移到B上直接用。

一、迁移失败的例子

直接从A上把表空间文件 yejr.ibd 拷贝到 B 上后,导入表空间,报错,无法使用。这是由于A,B上创建该表时的顺序不一致,导致表的ID不一样,无法导入。
注意:,在这里,表空间文件直接拷贝的前提是该表空间处于"干净"状态下,也就是所有的数据均已经刷新到磁盘中,否则可能导致无法使用或部分数据丢失。
1. 在B上将旧的表空间废弃

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

2. 拷贝到目标机器

scp yejr.ibd B:/home/mysql/yejr/yejr.ibd
....

3. 启用该表空间

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

4. 查看错误

InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './test/b.ibd'!
InnoDB: Error: cannot reset lsn's in table `test/b`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

5. 很明显,是权限的问题,修正过来,然后重新导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

6. 怎么还是错误?继续看日志

InnoDB: Error: tablespace id in file './yejr/yejr.ibd' is 15, but in the InnoDB
InnoDB: data dictionary it is 13.
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html
InnoDB: for how to resolve the issue.
InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `yejr/yejr`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

从上面的日志得知,由于在A服务器上,yejr表的ID是15,而在B服务器上,yejr表的ID却是13,二者不一致,因此迁移失败。
既然只是因为ID不一样,而且有了上面的理论基础,我们完全可以人为的让它们的ID一致嘛,请看下面的第2次尝试。

二、人工干预下的成功迁移

1. 上面的例子中,B上面的yejr表ID为13,而A上面为15;因此只需要让B上的yejr表ID增加2就可以了。

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr RENAME TO yejr1;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为14
(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr1 RENAME TO yejr;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为15

2. 然后,我们再导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
Query OK, 0 rows affected (0.00 sec)
(root@imysql.cn/17:52:47)[yejr]>select count(*) from yejr;
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)

看到了吧,成功了,呵呵。想要让他ID增加的方式也可以重复创建表,根据实际情况或者个人喜好而定了。
以上测试均在mysql 5.0.67版本下通过,只不过显示数据稍作处理了。

原文URL:http://imysql.cn/2008_12_17_migrate_innodb_tablespace_smoothly

Tags: innodb, mysql, database, 数据迁移, 叶金荣

Cookie常识

在制作 网页的时候,不可避免的会用到Cookie,无论是登录也好,保存状态也好,或多或少,你都会在使用Cookie这个小甜饼。

然而甜饼并不是这么好吃的,吃的过多也会有问题的,如果你的网站COOKIE数量过多,或许你的浏览器就直接打不开这个网页(这点好象是和SERVER端有关,apache接受客户端的COOKIE数量和长度也有限制)

对于用户来说,如果没有做限制的话,那么COOKIE过多会导致后一个新的COOKIE会覆盖掉前面的COOKIE。。

那么,究竟应该有多少COOKIE呢?

以下内容来自DBA Notes网站:

Cookie 是个很有趣的话题。根据 RFC 2109 的描述,每个客户端最多保持 300 个 Cookie,针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多,比如 Firefox 是 50 个) ,每个 Cookie 最多 4K,注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了,对于 Cookie 最重要的就是,尽量控制 Cookie 的大小,不要塞入一些无用的信息。

所以,不要把你想知道的用户行为都采用COOKIE来保存,否则造成的后果恐怕是非常大。在一些大型网站,目前对于用户的行为已经开始逐步采用数据库来控制,这样可以记录用户的一些操作,对于用户的行为分析也能够达到的一定的效果,缺点是加大了数据库的压力。而且对于未登录网站的用户来说,他的行为将变得毫无意义

想象:将用户的一些普通行为采用Cookie保存,重要信息记录数据库。比如用户浏览过的网页记入cookie,而用户停留时间最长的网页则考虑记入数据库(当然,对于那种开着网页不关的人就无法对付了,但仍然可以通过客户端的document.scroll的高度来进行判断,再通过ajax提交 )意义不是特别大。对于一些象购物车之类的,确实可以考虑存入数据库,否则一旦网页误关闭了对于用户的体验可能并不是很好(给用户一个可选项:cookie或者数据库,但好象有点傻)。。。。。。

随便谈谈吧。。

Tags: php, web, cookie, rfc2109

Snoopy更新

snoopy是在系统不支持curl的情况下所采用的抓取网络信息最有用的工具之一,因为他可以模拟POST,GET等方法,而无须让你再向以前一样用fsockopen,写上一大堆代码。

这样的一个类库,在目前被PHP的使用者广泛应用着,本来以为他就这样的一直不再更新下去,不料最近还是有了一些改动,当然这些改动都是一些BUG fix,而且是安全方面的,建议下载后更新。

更新情况:

Posted By: mohrt
Date: 2008-10-22 22:54
Summary:
Snoopy 1.2.4 security fix

A security vulnerability was fixed in the latest 1.2.4 version of Snoopy. It was possible to send shell commands through https url fetches that are not properly sanitized by the PHP program using Snoopy.

下载页面为:

http://sourceforge.net/project/showfiles.php?group_id=2091

Tags: snoopy, fsocketopn

Google Picasa 3.1

在很早很早以前,我们的看图软件都是用的acdsee,直到现在机器里还保存着2.4和3.1这样的经典版本,随着时间的推长,acdsee的肚量也越来越大,启动速度也越来越慢。最后还出了一个pro版。不过这一切都和我无缘了。因为我不再使用它。

在不再使用的日子里,我尝试了一些其他的软件:xnview,光影魔术手(新版本里面有看图软件了)等。但效果确实不能让人满意。光影的看图功能还不是很强劲,但比xnview要好上很多。

picasa也是我很久前就用的软件。刚出测试版的时候就使用了。只是那时候的效果很不好,在用上一段时间后就放弃了。

由于我现在用的是2003的精简版,里面看图功能被拿掉了。所以我最初用xnview,但是不舒服,后来就换成了picasa。现在我很满意:速度和编辑功能都相对提高了很多,而且滚轮的无限级缩放也很人满意。空格全屏非常爽。当然还有他自带的picasa WEB功能,可以让你在看图的时候选择是否上传到picasa 网站。

贴上一些介绍:

一款可帮助您在计算机上立即找到、修改和共享所有图片的软件.每次打开 Picasa 时,它都会自动查找所有图片(甚至是那些您已经遗忘的图片),并将它们按日期顺序放在可见的相册中,同时以您易于识别的名称命名文件夹.您可以通过拖放操 作来排列相册,还可以添加标签来创建新组.Picasa保证您的图片从始至终都井井有条.Picasa还可以通过简单的单次点击式修正来进行高级修改,让您只需动动指尖即可获得震撼效果.而且,Picasa还可让您迅速实现图片共享–可以通过电子邮件发送图片、在家打印图片、制作礼品 CD,甚至将图片张贴到您自己的blog中.

下载:Google Picasa 3.1 Build 70.71

The new features include:

-Picasa in 38 languages
-Advanced sharing options
-New and improved scrolling
-New sharpen slider

Tags: picasa, google, 看图软件, acdsee, 光影魔术手

mysql处理UTC时间

上午莫莫找我,问我有没有办法处理UTC时间,我很得意的将前两天COPY过来的,淘宝DBA的文章发给他看。说道,很简单呀,str_to_date就行了。

然而实现下来,却不正常,莫莫的时间是:05/Dec/2008:12:10:59 +0800,处理了半天都没有处理下来。因为我用的是:

SELECT STR_TO_DATE('05/Dec/2008:12:10:59 +0800' , '%d/%m/%Y');在我想来,date,month,year就行了,结果,返回给我的是NULL,死活不知道是什么问题。。。。

后来莫莫和我说,陌陌解决了这个问题,他用的是:SELECT STR_TO_DATE('05/Dec/2008:12:10:59 +0800' , '%d/%b/%Y');整个参数里就一个b和我的不一样。

才知道,也才明白,用STR_TO_DATE的时候,后面的参数和格式要和前面的参数一模一样,包括位置,包括参数的格式;虽然返回的值是:2008-12-05,但格式不对或者顺序不对,返回的肯定是NULL

记录下来,提醒一下自己,这个东西和php的strtotime不一样啊。。。

Tags: mysql, database, utc, str_to_date