Posts Tagged mysql

将Apache日志实时写入mysql

貌似 站长Litrin已经很久没有关注过LAMP的东西了。

作为网站运行来说,日志分析是一个很重要的工作。当一个网站的日志到了一定程度,或者一个网站同时有多台服务器的时候,传统的文本日志分析总会遇到瓶颈。

这个时候我就会想起强大的sql语句。看了网上很多人的帖子,都是将日志转成sql语句再导入的,搞得有点复杂。本方案不需要任何多余的软件和操作,一切全是实时、自动,供各位参考。

Read the rest of this entry »

, ,

No Comments

Oracle+Sun=?

刚刚得到的消息,Oracle以每股$9.50的价格,总计74亿美元收购了Sun。具体官方报道

上回说到IBM的收购案,被IBM收购可以看作对SUN的一种讽刺甚至于侮辱。在一次次的谈判无果之后,忽然间传出了这么一条冷门消息。MS说明与IBM谈判是假,Oracle是真啊。

Read the rest of this entry »

, , ,

No Comments

Mysql的几个设置值

mysql数据库的优化——老声长谈的话题,总是有那么多的话题好谈。闲来无事,谈谈几个关键优化参数的设置问题。注意的是,本文主要针对于MyISAM引擎,其他的,日后再吧。

在此之前,如果对mysql的命令和配置不很熟的情况下,phpmysql是必要的。

首先,到状态选项栏,拉一个系统状态表下来,或者执行mysqladmin variables extended-status –u root –p  ,同时计算下系统的uptime.

配置文件一般保存在/etc/my.cnf中,直接修改其中的内容即可。

此外,我的设置中还有如下内容:

skip-networking #不使用网络连接
skip-innodb #不使用innodb引擎

thread_concurrency = 4 #这个数值等于cpu核心数x2

Read the rest of this entry »

No Comments

用FreeBSD的ports安装apache+php+mysql·改

 正如我一贯习惯于规律性的工作和生活一样,昨天,我按照惯例在以往的时间,用电脑里的outlook软件收信——天热,纵然室内空调的温度已经远远低于官方标准的26度,人毕竟还是没有冷天来的那么清醒。如果从心理学的角度上讲,也许那时的我正处在“意识朦胧状态”。除了正如以往枯燥的工作E-mail之外,我收到了一封网友的E-mail。出乎意料的是,不同于往常访客在浏览了我的个人网页以后会在文章后面发表评论,这次却是发了mail。既然如此,我觉得mail一定是重要的,至少体现了相当一部分访客的心情吧。

那篇E-mail不长,在我的电脑上显示下来仅仅只有三行不到的样子,大抵的内容无非是说本站如何如何的帮了忙,我不免沾沾自喜起来——正如往常的沾沾自喜一样,mail的结尾处指出了小站的几个问题,最重要的是说很多文章过于流程化了,没有一点文字上的修饰和润色,言外之意是字里行间缺乏应有的优雅和细致。要指明的是,所谓优雅和细致,正是目前白领文学或者说白领文化所擅长的。说到白领文化的代表,我想村上春树的小说(或者说林少华翻译的日本小说)、伍佰的歌词、汪家卫的台词、小女人的blog绝对可以作为代表。作为我,从来没有当作自己是白领的一员——乏味的代码、吵闹的机房、灰尘遍布的机架,也许能跟这些词句联系上的只有“体力劳动”一个词了。我固然写不出优雅和细致,字里行间唯独只有王朔依稀的身影。于是我决定做一个尝试,既然有这样的需求,按照目前常说的一句话似乎叫做“需求第一”吧,我决定润色并重写本站访问量最高的那篇文章……

  Read the rest of this entry »

, , ,

5 Comments

mysql的“降级”移植

开发了一个项目,在部署时遇到了一点问题。

开发环境原本是mysql5.1,可实际部署的时候才发现服务器端的环境是mysql4.0。可mysqldump出来的数据无法直接倒入4.0,直接拷贝出来的数据,mysql4.0根本无法识别。

研究了一下mysqldump的文档,找到了一个选项“–compatible=name” 问题迎刃而解。而且这个选项竟然支持在多个环境中的平移。 选项支持mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb,格式的SQL语句。

No Comments

请教mysql的数据备份

我想备份服务器(linux)上的数据 mysqldump -p db_name > backup.txt 提示Enter password : 但我输入不进去密码(光标不动),为什么? 急呀,请求帮助,谢谢了! MSN:zch1125@163.com email : linda.zh@vonno.com

3 Comments

Mysql的存储引擎

mysql5.1里包含了好几种存储引擎(Storage Engine )。性能各有千秋,究竟哪个才是您需要的?

功能列表:


MyISAM BDB Memory InnoDB Archive NDB
最大数据 256TB No Yes 64TB No 384EB[4]
事务处理 No Yes No Yes No Yes
锁定级别 Table Page Table Row Row Row
读取快照 No No No Yes Yes No
特殊类型字段支持 Yes Yes[1] No Yes[1] Yes[1] Yes[1]
B-tree 索引 Yes Yes Yes Yes No Yes
哈西索引 No No Yes No No Yes
全文搜索 Yes No No No No No
集群索引 No Yes No Yes No No
数据缓存 No Yes N/A Yes No Yes
索引缓存 Yes Yes N/A Yes No Yes
压缩数据 Yes No No No Yes No
加密[2] Yes Yes Yes Yes Yes Yes
集群数据库 No No No No No Yes
复制支持[3] Yes Yes Yes Yes Yes Yes
外键支持 No No No Yes No No
热备份热恢复[3] Yes Yes Yes Yes Yes Yes
结果缓存支持 Yes Yes Yes Yes Yes Yes
字典更新统计 Yes Yes Yes Yes Yes Yes

注:

[1]支持特殊的数据类型,但不可作为索引
[2] 通过编程在服务器执行,效果远胜于在存储引擎中执行
[3] 在服务器内执行,远胜过在存储引擎中执行
[4] EB = 1024 * 1024TB

其中最常用的非MyISAM莫数。也是mysql下功夫最多的一个引擎了,几乎所有的参数都可以调节。速度超快,适合存储网页数据。类似的还有一个ISAM引擎,但就我看来,它不过是MyISAM的前身为了保证兼容性保留下来的。

Memory首次接触是将php的seesion保存在数据库中,Memory顾名思义,将所有数据保存在内存中,访问速度有所提高,当然关机后数据消失。感觉这个引擎更加体现了mysql的“裸奔原则”,为了速度,能丢弃的全部丢弃。

InnoDB因为有了事务处理和外键支持,很适合做企业数据库。但说老实话,他的速度实在叫人提不起兴趣。支持COMMIT, ROLLBACK, 和 savepoints.

BDB,很接近于InnoDB,支持
RCOMMITROLLBACK 操作

NDB,如果你的mysql不得不作集群,这也是不得不选择的引擎。

一个数据库中每个表都可以用不同的引擎,你可以使用“CREATE TABLE engineTest (id INT) ENGINE = MyISAM;” 的方式来创建一个表,同时也可以使用“ALTER TABLE engineTest ENGINE = ARCHIVE;”的方式改变一个表的属性。

No Comments

细解mysqldump

mysqldump是mysql自带的一个强大的备份工具。如果您像装载整个数据库mydb的内容到一个文件中,可以使用下面的命令:

  #mysqldump –-database mydb –user=username –password=password > mydb.sql
  
  这个语句也允许您指定一个表进行dump(备份/导出/装载?)。如果您只是希望把数据库db中的表table中的整个内容导出到一个文件,可以使用下面的命令:

  #mysqldump –database db table >db_table.sql
  
  这个非常的灵活,您甚至可以使用WHERE从句来选择您需要的记录导出到文件中。看过mysql官方手册中就介绍了这样一个实现mysql增量备份的例子:
      
        #mysqldump –where=“ last_modified < NOW() – INTERVAL 1 MONTH”  >backup.sql
    
  mysqldump工具有大量的选项,部分选项如下表:

  选项/Option 作用/Action Performed

  –add-drop-table

  这个选项将会在每一个表的前面加上DROP TABLE IF EXISTS语句,这样可以保证导回MySQL数据库的时候不会出错,因为每次导回的时候,都会首先检查表是否存在,存在就删除

  –add-locks

  这个选项会在INSERT语句中捆上一个LOCK TABLE和UNLOCK TABLE语句。这就防止在这些记录被再次导入数据库时其他用户对表进行的操作
  
  -c or – complete_insert

  这个选项使得mysqldump命令给每一个产生INSERT语句加上列(field)的名字。当把数据导出导另外一个数据库时这个选项很有用。

  –delayed-insert 在INSERT命令中加入DELAY选项

  -F or -flush-logs 使用这个选项,在执行导出之前将会刷新MySQL服务器的log.

  -f or -force 使用这个选项,即使有错误发生,仍然继续导出

  –full 这个选项把附加信息也加到CREATE TABLE的语句中

  -l or -lock-tables 使用这个选项,导出表的时候服务器将会给表加锁。

  -t or -no-create- info

  这个选项使的mysqldump命令不创建CREATE TABLE语句,这个选项在您只需要数据而不需要DDL(数据库定义语句)时很方便。
  
  -d or -no-data 这个选项使的mysqldump命令不创建INSERT语句。

        –opt 此选项将打开所有会提高文件导出速度和创造一个可以更快导入的文件的选项。

  -q or -quick 这个选项使得MySQL不会把整个导出的内容读入内存再执行导出,而是在读到的时候就写入导文件中。

   -T path or -tab = path 这个选项将会创建两个文件,一个文件包含DDL语句或者表创建语句,另一个文件包含数据。DDL文件被命名为table_name.sql,数据文件被命 名为table_name.txt.路径名是存放这两个文件的目录。目录必须已经存在,并且命令的使用者有对文件的特权。
  
  -w "WHERE Clause" or -where = "Where clause "

  如前面所讲的,您可以使用这一选项来过筛选将要放到 导出文件的数据。
  

PS: 如果你的mysql是运行在*nix平台上的,可以利用其强大的pipe连接一下,输出压缩后的数据:mysqldump -A | bzip2 -9 -f > db_backup.sql.bz2。直接从一个服务器备份到另一服务器:mysqldump –opt database | mysql –host=remote-host -C database  。

No Comments

优化你的数据库

最近一段时间似乎是受到了刺激,弄来弄去都是优化各种数据库的活所以继续还是写这一类的东西。凡是运行中的数据库,总会数据越来越多(废话!),性能同时也会越来越差。这里就按照一般的顺序,从应用逐步提高到硬件升级。

应用优化

任何一个数据库他的作用都不是全力运行算术运算的,所以除了必须的工作之外,其他的还是交给外部软件来完成吧。让数据库来执行类似于计算器功能的算术运算或者执行一系列无谓的数据校验可谓是愚蠢至极,过于复杂的函数最好也不要使用,记住数据库的优势在于:

  • SELECTINSERT 指定的行

  • JOIN

  • GROUP BY

  • ORDER BY

  • DISTINCT

 对于一般的简单运算,类似于sum avg之类的操作,出于节省连接时间的考虑还是交给外部软件吧。当然不要查询应用中不需要的列同时可以试试看UPDATE table set count=count+1 where key,性能可能会有不少提升。如果在一个批处理中进行大量修改,可以使用LOCK TABLES例如将多个UPDATESDELETES集中在一起;Insert使用默认值也是一个不错的选择。当然可以多试试EXPLAIN 工具,总会找到一种适合的最优化操作的。

优化数据结构

注意的是,这里说的并不是让你去更改系统的数据结构,特别是在运行中的系统中,这样做是“相当”危险的。

  • 明智地使用键码。
  • 键码适合搜索,但不适合索引列的插入/更新。

  • 不要索引你不想用的东西。

  • 虽说有种说法叫做“同样的数据只保存一次”但前提是“在所有的运算只做一次且有用”的前提下,创建足够总结表、简化表是非常有益的

  • 在大表上不做GROUP BY,相反创建大表的总结表/简化表并查询它。

  • ANALYSE过程可以帮助你找到表的最优类型:SELECT * FROM table_name PROCEDURE ANALYSE()

数据库优化

这里一句话也讲不清这么多种数据库的优化,本站有不少相关的东西可供大家参考,并且本站会不断更新和完善,同时也希望大家协助。

磁盘优化

磁盘系统通常是影响数据库第二个重要的因素(第一重要的是内存,但内存的优化相比较复杂)

  • 为系统、程序和临时文件配备一个专用磁盘,如果确是进行很多修改工作,将更新日志和事务日志放在专用磁盘上。

  • 低寻道时间对数据库磁盘非常重要。对与大表,你可以估计你将需要log(行数)/log(索引块长度/3*2/(键码长度 + 数据指针长度))+1次寻到才能找到一行。对于有500000行的表,索引Mediun int类型的列,需要log(500000) / log(1024/3*2/(3 + 2))+1=4次寻道。上述索引需要500000*7*3/2=5.2M的空间。实际上,大多数块将被缓存,所以大概只需要1-2次寻道。

  • 然而对于写入(如上),你将需要4次寻道请求来找到在哪里存放新键码,而且一般要2次寻道来更新索引并写入一行。

  • 对于非常大的数据库,你的应用将受到磁盘寻道速度的限制,随着数据量的增加呈N log N数据级递增。

  • 将数据库和表分在不同的磁盘上。在MySQL中,你可以为此而使用符号链接。

  • RAID 0将提高读和写的吞吐量。

  • RAID 0+1将更安全并提高读取的吞吐量,写入的吞吐量将有所降低。

  • 不要对临时文件或可以很容易地重建的数据所在的磁盘使用镜像或RAID(除了RAID 0)

  • Linux上,在引导时对磁盘使用命令hdparm -m16 -d1以启用同时读写多个扇区和DMA功能。这可以将响应时间提高5~50%

  • Linux上,用async (默认)noatime挂载磁盘(mount)

  • 对于某些特定应用,可以对某些特定表使用内存磁盘,但通常不需要。

升级硬件

按照数据库对于硬件的依赖程度,内存、硬盘、CPU的顺序来升级硬件,包括操作系统。

  • 如果你需要庞大的数据库表(>2G) ,最好采用64位的CPU64位的操作系统。

  • 如果有足够大的内存,关掉Swap分区吧。

  • 更多的内存通过将最常用的键码页面存放在内存中可以加速键码的更新 ,但前提是要正确的设置而且配置好这些内存——这正是我前些天碰到的比较讽刺的例子,空有24G的内存只执行了2秒钟的“F5攻击”就死的一塌胡图。

  • 如果不使用事务安全(transaction-safe)的表或有大表并且想避免长文件检查,一台UPS就能够在电源故障时让系统安全关闭

  • 如果数据库单独列出来需要网络连接,请选择至少千兆网卡和交换机的连接,如果采用了类似于8139的烂网卡你会抓狂的。

其他的类似于定期优化表、修复磁盘、消除碎片等等工作属于一般性的维护操作,这里不加深解。

, ,

1 Comment

数据库系统升级

根据PostgresSQL8.1的手册所描述,8.1新增了诸如数据库自动清理和自动备份等新功能。在本地测试了大约3周,确实如实。故今天上午9:00~11:00升级了网站的数据库至8.1的版本,同时连带升级还有PHP5的pgsql模块和perl。

整体性能有了一定提高,首页的平均载入时间减少了百分之三秒且还有潜力可挖。升级过程中可能部分用户会注册失败,还请重新注册。

No Comments