分类目录归档:MySQL

mysql复制将slave转化为master

更改my.cnf配置后出现下面的错误提示:
[bash]
[root@zt_script ~]# service mysqld restart
Shutting down MySQL. [ OK ]
Starting MySQL..The server quit without updating PID file ([FAILED]sql/zt_script.pid).
[/bash]

查看错误日志
[bash]
121224 11:01:44 [Warning] Neither –relay-log nor –relay-log-index were used; so replication may break when this MySQL server acts as a slav
e and has his hostname changed!! Please use ‘–relay-log=zt_script-relay-bin’ to avoid this problem.
121224 11:01:44 [ERROR] Failed to open the relay log ‘./mysql-relay-bin.000004′ (relay_log_pos 504)
121224 11:01:44 [ERROR] Could not find target log during relay log initialization
121224 11:01:44 [ERROR] Failed to initialize the master info structure
[/bash]
解决方法:
1.停止slave:
[bash]
slave stop;
reset slave;
[/bash]
2.停止mysqld
[bash]
service mysqld stop
[/bash]
3.然后备份现有的mysql-bin.index和mysql-relay-bin.*日志文件;
4.再删除上面备份前的日志文件;
5.重启即可。

提高mysql插入数据的速度[转]

需要在mysql中插入2000万条记录,用insert语句插入速度很有限,每秒钟几百条,放在hadoop集群上跑也是这个速度,可能是数据库的问题了,网上看到sql server和oracle的insert速度也不是很快。比较简单的优化方法如下:

1、在一条insert语句中插入多条记录

[sql][/sql]
INSERT INTO tablename (field0, field1, …) VALUES
(value0, value1, …),
(value0, value1, …),
(value0, value1, …),

(value0, value1, …)

这样插入速度可以提高很多倍,但还是不够块,对于2000万条记录,每秒钟一两千条的插入速度还是太慢。
2、从文本文件导入数据

mysql可以从文本文件直接导入记录,不过需要文本文件是行记录,并且每个字段之间用相同的字符隔开、每行之间也用相同的字符隔开。

写了个程序把文本文件的格式处理一下,就可以在mysql客户端使用如下语句导入数据了:

[sql][/sql]
mysql> LOAD DATA LOCAL INFILE ‘fileName’ INTO TABLE ‘tableName’ FIELDS TERMINATED BY ‘\t’ LINES TERMINATED BY ‘\n’;
其中’\t’和’\n’分别是字段和行的分隔符,在不同的情况下可能不一样。

用这种方式,感觉导入的速度主要和文件的大小有关,和记录的条数关系不太(可能是2000万的记录还不够多吧。。)
导入一个800MB的文本文件(2000万行),在单机上预处理用了3分钟,导入数据库用了7分钟(机器配置是i5-2400CPU、8GB内存、硬盘读取速度大约90MB/S)

下面还要处理一个11GB的文本文件,这回估计要用集群跑了。

解决mysql数据连接超时断开的问题

如果mysql的连接的空闲时间超过wait_timeout设置的时间,就会出现mysql server has gone away的错误,解决方法如下
建立一检测函数,如果mysql_ping不成功则关闭旧连接,然后重新建立一个新的连接。
function check_db_link($conn, $type = ‘center_server’) {
if (! mysql_ping ( $conn )) {
global $config;

mysql_close($conn);
//var_dump($config);

$conn = mysql_connect ( $config [$type] ['db_host'], $config [$type] ['db_user'], $config [$type] ['db_password'] );
mysql_select_db ( $config [$type] ['db_name'], $conn );
mysql_query ( “set names utf8″, $conn );
}
return $conn;
}
注:在新建连接之前必须先使用mysql_close($conn);关闭旧的连接,否则返回的连接依然不能用。

MySQL与NoSQL——SQL与NoSQL的融合[转]

写这一篇内容的原因是MySQL5.6.2突然推出了memcached的功能。NoSQL to InnoDB with Memcached的出现,可以看出NoSQL对关系数据库的确产生了巨大的影响,个人觉得这是一个非常大的进步,可以让开发人员更加方便的使用NoSQL和关系数据库。NoSQL一般被认为性能高于关系数据库,那么直接在InnoDB之上提供NoSQL功能并和MySQL共存是否是一个更好的选择呢?

MySQL with HandlerSocket

去年在twitter上看到HandlerSocket的出现,并宣称性能是Memcached的两倍时,非常令人吃惊,居然可以达到750000qps。接着HandlerSocket成为NoSQL领域谈论的焦点之一, 大量的人开始想要尝试,并做过一些自己的性能测试。 下图是HandlerSocket的结构图:

图1 HandlerSocket结构图(来源于官方)

HandlerSocket的出现,给我们眼前一亮的感觉。原来InnoDB的性能已经足够好,并可以直接提供NoSQL的功能。最大的好处就是可以共享MySQL的功能,DBA以前的经验一样可以用。但是有些小小的风险:

  • HandlerSocket没有与MySQL一起发布版本,因此对于使用MyISAM引擎的用户是无缘的。不过现在Percona-Server已经集成了HandlerSocket,可以非常方便的使用。
  • 目前大规模的成功案例并不多,国内也只有少部分公司在尝试,我知道的有飞信开放平台,据说还不错。
  • 官方给出的测试数据在应用场景上其实并不充分,至少测试的场景跟我们实际使用的场景相差很大。但是毫无疑问, HandlerSocket的性能比直接使用MySQL肯定要高效得多。

InnoDB with Memcached

也许是因为HandlerSocket的火爆的冲击,也许是受HandlerSocket的启发,MySQL开始关注NoSQL领域的应用,并在MySQL5.6.2版本增加了通过Memcached协议直接访问原生Innodb API的功能。

InnoDB with Memcached是在提供MySQL服务的同一进程中提供Memcached服务 ,这与HandlerSocket的架构模式几乎是一样的。虽然目前InnoDB with Memcached还是预览版本,但是我个人更看好它,因为:

  • 它使用Memcached协议,并同时支持文本和二进制协议,在client的选择和成熟度上就要胜出许多;
  • 其支持的三种cache模式,不但可以省去开发中使用Memcached来缓存数据的麻烦,并且具有更好的可靠性和数据一致性;
  • 在应用程序中,可以使用高效的memcached协议来操作数据,同时也可以使用sql进行复杂的查询操作;

注意:目前通过memcached的更新操作不会记录到binlog中,未来的版本会支持。

图二 InnoDB with Memcached

Memcached and MySQL Cluster

显而易见,我们会想到MySQL Cluster结合Memcached是一个更好的组合,MySQL Cluster提供了99.999%高可用性,并真正提供了去中心化的无缝高可扩展性。还有什么比这更人兴奋的呢。

MySQL已经提供了这样的功能,源代码在这里。这里有一个O’Reilly MySql Conference大会的PPT演示 ,你也可以看下这个功能开发者的一篇博客

图三 NDB with Memcached

MySQL Cluster虽然具有高可靠性和无缝扩展的优势,但是对于复杂SQL查询的效率却不能令人满意。不过对于仅仅依赖于key-value查询和写入的海量数据存储需求,MySQL Cluster with Memcached应该是个很好的选择。

总结

Memcached协议由于其简单、协议轻量、存在大量的client,所以提供兼容Memcached协议的产品比较占据先天的优势。

MySQL提供NoSQL的功能,个人觉得并不是MySQL耐不住寂寞,而是的确在响应用户的需求。我前面的文章也说过,“NoSQL只是一个概念,并不是一个数据库 产品,MySQL也可以是NoSQL”,现在也正应了这句话。NoSQL从架构上就约束了开发者的架构和开发方式,从而提高扩展性和性能,而NoSQL和MySQL的融合,也同时提供了复杂查询功能。

虽然MySQL提供了NoSQL功能,如果你要尝试的话,你的数据库设计必须从NoSQL从发,然后再考虑SQL查询功能。

SQL与NoSQL的融合的确会给开发者带来方便,比如最近很流行的Mongodb,它吸引开发最大的点就是支持简单的关系查询。SQL与NoSQL的融合可能是未来很多数据库产品的一个趋势。但是纯NoSQL数据库的优势也是显著的,就是他的简单、高效、易扩展。

参考链接:

关于作者

孙立,目前为去哪儿网(qunar.com)高级系统架构师。曾就职于凤凰网、ku6和搜狐。多年互联网从业经验和程序开发,对分布式搜索引擎的开发,高并发,大数据量网站系统架构优化,高可用性,可伸缩性,分布式系统缓存,数据库分表分库(sharding)等有丰富的经验,并且对运维监控和自动化运维控制有经验。是开源项目phplock,phpbuffer的作者。近期开发了一个NOSQL数据库存储INetDB,是NoSQL数据库爱好者。

本文已经首发于InfoQ中文站,版权所有,原文为《MySQL与NoSQL——SQL与NoSQL的融合》,如需转载,请务必附带本声明,谢谢。

InfoQ中文站是一个面向中高端技术人员的在线独立社区,为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon 、线下技术交流活动QClub、免费迷你书下载如《架构师》等。​

恢复mysql数据库的几种方法

1.如果数据量超大,直接拷贝数据库文件,以拷贝之前要先停止mysqld服务,如果是myisam类型则可以可以直接恢复。如果是innodb,还需要copy ibdata1.

2.如果数据量中等大小,是用命令行工具,mysqldump,注意编码。

3.如果中小型 数据量,用第三方工具,如sqlyog,phpmyadmin可能更省事。

mysql-bin.000001文件的来源及处理方法[转]

用ports安装了mysql以后,过一段时间发现/var空间不足了,查一下,会发现是mysql-bin.000001、mysql-bin.000002等文件占用了空间,那么这些文件是干吗的?这是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的。

这样做主要有以下两个目的:
1:数据恢复
如果你的数据库出问题了,而你之前有过备份,那么可以看日志文件,找出是哪个命令导致你的数据库出问题了,想办法挽回损失。
2:主从服务器之间同步数据
主服务器上所有的操作都在记录日志中,从服务器可以根据该日志来进行,以确保两个同步。

处理方法分两种情况:
1:只有一个mysql服务器,那么可以简单的注释掉这个选项就行了。
vi /etc/my.cnf把里面的log-bin这一行注释掉,重启mysql服务即可。
2:如果你的环境是主从服务器,那么就需要做以下操作了。
A:在每个从属服务器上,使用SHOW SLAVE STATUS来检查它正在读取哪个日志。
B:使用SHOW MASTER LOGS获得主服务器上的一系列日志。
C:在所有的从属服务器中判定最早的日志,这个是目标日志,如果所有的从属服务器是更新的,就是清单上的最后一个日志。
D:清理所有的日志,但是不包括目标日志,因为从服务器还要跟它同步。
清理日志方法为:
PURGE MASTER LOGS TO ‘mysql-bin.010′;
PURGE MASTER LOGS BEFORE ’2008-12-19 21:00:00′;

如果你确定从服务器已经同步过了,跟主服务器一样了,那么可以直接RESET MASTER将这些文件删除。

======================================

之前发现自己10G的服务器空间大小,用了几天就剩下5G了,自己上传的文件才仅仅几百M而已,到底是什么东西占用了这么大空间呢?今天有时间彻底来查了一下:

mysql-log

看下上面的目录web根目录是放在/home 里面的,所有文件加起来才不到300M,而服务器上已经占用了近5G空间,恐怖吧,最后经我一步一步查询得知,原来是这个文件夹占了非常多的空间资源:

mysql-log1

原来如此,是mysql文件夹下的var目录占用空间最大,那里面是啥 内容呢?我们来看下:

mysql-log2

发现了如此多的 mysql-bin.0000X文件,这是什么东西呢?原来这是mysql的操作日志文件.我才几十M的数据库,操作日志居然快3G大小了.

如何删除mysql-bin.0000X 日志文件呢?

红色表示输入的命令.

[root@jiucool var]# /usr/local/mysql/bin/mysql -u root -p
Enter password:  (输入密码)
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 264001
Server version: 5.1.35-log Source distribution

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql> reset master; (清除日志文件)
Query OK, 0 rows affected (8.51 sec)

mysql>

好了,我们再来查看下mysql文件夹占用多少空间?

[root@jiucool var]# du -h –max-depth=1 /usr/local/mysql/
37M     /usr/local/mysql/var
70M     /usr/local/mysql/mysql-test
15M     /usr/local/mysql/lib
448K    /usr/local/mysql/include
2.9M    /usr/local/mysql/share
7.6M    /usr/local/mysql/libexec
17M     /usr/local/mysql/bin
11M     /usr/local/mysql/docs
2.9M    /usr/local/mysql/sql-bench
163M    /usr/local/mysql/

好了,看一下,整个mysql 目录才占用163M大小!OK,没问题,既然mysql-bin.0000X日志文件占用这么大空间,存在的意义又不是特别大,那么我们就不让它生成吧.

[root@jiucool var]# find / -name my.cnf

找到了my.cnf 即mysql配置文件,我们将log-bin=mysql-bin 这条注释掉即可.

# Replication Master Server (default)
# binary logging is required for replication
#log-bin=mysql-bin

重启下mysql吧.

OK,至此,操作完成. 以后再不会因为就几十M的数据库大小生成N个G的日志文件啦.

这些个日志文件太恐怖了,我搬到这新VPS来才二十天左右,还不到一个月日志文件居然就近3个G大小,如果一两个月我不清除日志文件这还得了!