淡定在黑暗和黎明时分!!!
2008年九月
mysql sql 修改表名 建立外键 修改列名 删除列
九 19th
–重命名表
rename table t_softwareport to software_port;
–建立外键
alter table software_port add constraint fk_software_port_softwareprocessid foreign key (softwareprocessid)
references software_process (id) on delete restrict on update restrict;
–删除列
alter table software_type
drop column upid,
drop column orderid;
–修改列名
alter table software_process change software_id softwareid int(11) not null;
apache自带负载均衡的集群功能实战录(mod_proxy模块的应用)
九 15th
下面以在apache mod_proxy下做的反向代理负载均衡为配置实例:在站点www.test.com,我们按提供的内容进行分类,不同的服务器 用于提供不同的内容服务,将http://www.test.com/news的访问转到IP地址为192.168.1.1的内部服务器上处理,对 http: //www.test.com/it的访问转到服务器192.168.1.2上,http://www.test.com/life的访问转 到服务器 192.168.1.3上,http://www.test.com/love的访问转到合作站http://www.love.com上,从 而减轻本apache服务器的负担,达到负载均衡的目的。
首先要确定域名www.test.com在DNS上的记录对应apache服务器接口上具有internet合法注册的IP地址,这样才能使internet上对www.test.com的所有连接请求发送给本台apache服务器。
在本台服务器的apache配置文件httpd.conf中添加如下设置:
proxypass /news http://192.168.1.1
proxypass /it http://192.168.1.2
proxypass /life http://192.168.1.3
proxypass /live http://www.live.com
注意,此项设置最好添加在httpd.conf文件“Section 2”以后的位置,服务器192.168.1.1-3也应是具有相应功能的www服务器,在重启服务时,最好用apachectl configtest命令检查一下配置是否有误。
接下来也是我真正想要介绍的2.2版本后在mod_proxy中新添加的mod_proxy_balancer模块给我们带来的新功能。
首先将在主配置文件http.conf以下Module的注释去掉
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so
再并增加以下元素
ProxyRequests Off
ProxyPass /test balancer://xuanfei stickysession=jsessionid nofailover=On
<proxy balancer://xuanfei/>
BalancerMemberhttp://192.168.28.131 loadfactor=1
BalancerMemberhttp://192.168.28.130 loadfactor=1
</proxy>
ProxyPass为代理转发的Url,即将所有访问/test的请求转发到群集balancer://xuanfei
loadfactor为各主机间的负载比例参数,可是设置不同指数
BalancerMember为群集的成员,即群集服务器A或B,负载均衡服务器会根据均衡规则来将请求转发给BalancerMember。
配置好后,启动Apahce服务<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from all
</Location>
器,访问xuanfei/test就会看到群集服务器中应用返回的结果。恭喜你,负载均衡和群集已经配置成功了!
而且还可以同样在http.conf主配置文件主添如下元素:
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from all
</Location>
如果配置成功后你可以可以在地址栏输入 xuanfei/balancer-manager,将可以清楚的看到各节点的工作运行状态:)
同样还可以同样在http.conf主配置文件主添如下元素:
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from all
</Location>
便可以方便的观测到主服务器的当前运行状态,只要在地址栏输入 xuanfei/server-status
用ab对apache负载均衡集群的性能测试对比报告
用ab对apache负载均衡集群的性能测试对比报告
小结:apache 自带mod_proxy功能模块中目前可以实现两种不同的负载均衡集群实现方式,第一种是分工合作的的形式,通过各台主机负 责不同的任务而实现任务分工。第二种是不同的机器在担任同样的任务,某台机器出现故障主机可以自动检测到将不会影响到客户端,而第一种却不能实现但第一种 实现方式的优点在于他是主服务器负担相应没第二种大因为台只是提供跳转指路功能,形象的说他不给你带路只是告诉你有条路可以到,但到了那是否可以看到你见 的人他已经不会去管你了:)。相比之下第二种性能要比第一种会好很多;但他们都有个共同点都是一托N形式来完成任务的所以你的主机性能一定要好
Yahoo!社区架构(转载)
九 4th
旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加,但是看看各个网站”晒架构”也是个比较过瘾的事情。请参观并收藏这个页面:Architectures you’ve always wondered about。
eBay 的架构和去年相比基本是换汤不换药,倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思,披露了一些鲜为人知的信息。
Yahoo! 社区包括我们比较熟悉的 del.icio.us、Flickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo!把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。
架构特点
有两点值得注意:1)层次化 2)模块化。这也是大规模作业下的比较经济的途径。
软件架构
首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux,这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle,构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon(监控),还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache,请参考我以前写的 Yapache-Yahoo! Apache 的秘密
数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了),通过快照复制到其他数据中心。
Yahoo! Mail 架构:
这里面居然部署了 Oracle RAC,用来存储 Mail 服务相关的 Meta 数据。非常有趣。
运营维护
监控工具主要用的是 Nagios,用以监控集群。使用标准插件,另 外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo!自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo!的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。

应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。