Archive for the '大话技术' Category
核心业务系统数据库平台迁移： Oracle -> MySQL
Tuesday, August 24th, 2010
为了对核心技术拥有更多的自主控制能力，为了解决数据库的线性扩展问题，为了尽量减少对商业软件的依赖，为了摆脱对高端硬件的依赖，为了… 基于以上多种原因，2年前，我们计划将公司某核心应用平台进行大手术：数据库平台从软件到硬件全部重构。当然，这其中应用架构的改造也不可避免的进行了大 换血。
这个项目无论是从技术角度还是是业务角度来说，都对我们有着非常大的价值，也必定会带来非常深远的影响。项目历时2年多，分4个阶段才完成：
应用接口统一
这一阶段主要是为了后面真正迁移的时候做准备工作，将该核心应用系统的所有数据访问入口统一到一起，全部以服务化的接口方式呈现给其他有需要的系统，一来方便后续变更的控制，二来也推进了服务化的进程。
Oracle数据库中拆分（1拆16）
这个阶段本不是必要的，但是由于项目启动稍微晚了点，数据出现了爆发性增长，导致该系统的数据表太大（单表不带索引过500GB），原 Oracle 数据库已经快撑不住了。为了安全起见，先在 Oracle 中从一个主表以会员ID进行 hash 运算后再进行水平拆分，从1个表分拆成了16个。附表由于访问量稍小，而且全部是根据主键访问，暂时保留原样。
当然，这样的水平拆分，必然会带来数据访问路由以及数据合并的问题。我们专门为此开发了具有分布式数据库路由/数据合并，数据库读写分离，数据库链接管理等功能的数据访问中间层，专门解决拆分后给应用服务器带来的影响，使得应用服务器完全感受不到后端数据库的变化。
这个数据访问中间层，对前端应用服务器来说，就是一个完整的数据库，所有数据请求都从这里实现，以协议的方式和前端应用服务器的jdbc驱动进行交互，以便让数据库对应用服务器彻底透明。
Oracle迁移至 MySQL（16拆128）
这个阶段是整个阶段中历时最长，复杂度最高，风险系数最高的，未知因素也最多的一个阶段。虽然 MySQL 数据库已经在互联网行业占据了大片江山，但是对于阿里巴巴来说，却仍然是一个新鲜玩意儿，因为之前我们一直都用 Oracle 来提供所有的业务系统的数据库服务。
在此之前，我们从来没有在如此核心业务系统的数据库上使用过 PC Server 和本地硬盘来承载数据库，一直是使用 IBM 小型机和中高端存储设备来解决高性能和高可靠的问题。在更换成 PC Server 和本地硬盘来承载数据库之后，我们就必须面对 PC Server 本身硬件可能存在的不可靠性所带来的 Crash，所以我们必须有一套完善的 HA 切换机制，要比小型机厂商所提供的商业 HA 管理软件更加高效更加自动化更加可控，才能我们降低了设备本身可靠性之后达到原有的可用性要求。
对于一个需要满足 365 * 24 * 7 的核心业务系统来说，肯定是不可能给我们太多时间来进行数据迁移的，所以我们不得不设计出一个对现有系统影响尽可能小的迁移方案，这势必会造成方案的高度复杂化，带来更多的风险。最后的迁移方案要经历如下4个阶段：
1. Oracle 读/写;；MySQL 初始化并增量写
2. Oracle 读/写； MySQL 写
3. Oracle 写； MySQL 读/写
4. Oracle [...]
Alibaba DBA Team 2010/08
Tuesday, August 10th, 2010
MySQL Query Cache 小结
Monday, July 5th, 2010
最近经常有人问我 MySQL Query Cache 相关的问题，就整理一点 MySQL Query Cache 的内容，以供参考。
顾名思义，MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说，Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲，就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。
在大部分的 MySQL 分发版本中，Query Cache 功能默认都是打开的，我们可以通过调整 MySQL Server 的参数选项打开该功能。主要由以下5个参数构成：
query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cache
query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小
query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数
query_cache_type：控制 [...]
ORACLE BITMAP INDEX
Monday, May 24th, 2010
ORACLE BITMAP INDEX
在Vmware上安装Oracle 11gR2 的安装简易手册
Thursday, May 20th, 2010
有感于今天内部被问到的一个问题
1. 运行如下的rpm命令,找到安装Oracle需要而没有安装的rpm包.并mount Redat安装盘安装这些包.
rpm -qv binutils-2.17.50.0.6 \
compat-libstdc++-33-3.2.3 \
elfutils-libelf-0.125 \
elfutils-libelf-devel-0.125 \
elfutils-libelf-devel-static-0.125 \
gcc-4.1.2 \
gcc-c++-4.1.2 \
glibc-2.5-24 \
glibc-common-2.5 \
glibc-devel-2.5 \
glibc-headers-2.5 \
kernel-headers-2.6.18 \
ksh-20060214 \
libaio-0.3.106 \
libgcc-4.1.2 \
libgomp-4.1.2 \
libstdc++-4.1.2 \
libstdc++-devel-4.1.2 \
make-3.81 \
sysstat-7.0.2 \
libaio-devel-0.3.106 \
unixODBC-2.2.11 \
unixODBC-devel-2.2.11
mkdir /media/cdrom/
mount -t iso9660 /dev/cdrom /media/cdrom/
cd /media/cdrom/Server/
rpm -ivh sysstat-7.0.2-1.el5.i386.rpm libaio-devel-0.3.106-3.2.i386.rpm unixODBC-2.2.11-7.1.i386.rpm unixODBC-devel-2.2.11-7.1.i386.rpm
2. 关闭大部分无用的服务(可能因人因环境而异,这只是我的个人喜好).
chkconfig NetworkManager –level 2345 off
chkconfig NetworkManagerDispatcher –level 2345 off
chkconfig acpid –level 2345 off
chkconfig [...]
Linux一些页的东西
Thursday, May 6th, 2010
LINUX PAGE 页
Oracle高可用架构
Friday, March 19th, 2010
今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture
Oracle高可用架构
作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”).Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:
将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:
从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:
如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.
现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:
备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:
这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.
上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).
附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).
使用数据库存图片
Thursday, March 11th, 2010
图片是网站上很重要的资源，用户发布的产品图片，用户的logo，AV男，兽兽女，犀利哥等等等等，一个稍具规模的网站，图片的数量可能是千万级，这种资源的特点就是文件小，数量大，每个文件在几字节到几K不等，所以针对图片的访问，基本是非常离散的IO，考验的是系统的磁盘并发和CPU处理能力
一般网站，图片都是存放专门的图片服务器，可集中也可以分布式，比如有条件的可以购买昂贵的NAS存储，由主机拖着，以NFS或者HTTP的方式，供前面的应用访问，或者使用多台廉价PC，图片分布打散到每个机器，前台应用解决图片存取和访问策略，以便充分利用所有资源，在应用与图片服务器中间还可能加一层cache，来缓冲前台的访问压力
上面所说的方法，弊端是有很多的
1.文件系统一定是要使用的，为了管理数千万的图片，必须进行目录分层，因为一个目录下不可能存放太多的文件，前期的目录规划要考虑后期的扩展，还有图片分布均匀，这样做下来，往往目录的深度会达到5层甚至7层
2.数据迁移，备份怎么做？高级的NAS存储，有自己的卷复制，但这个粒度太粗，如果要细分到底层或中间层，会有点力不从心，对于这种大数据量的小文件拷贝，PC也是非常吃力
3.每一个图片的访问，基本会做5-7次的目录跳转，转换到磁盘，也可能有10次物理IO了，在并发量上来的时候，磁盘会是个瓶颈，当然，分布式是个方向
这里想到了另外一种方法，利用数据库来存放图片，存储的方式就是现在最流行的key-value
create table mypic
(
key number not null,
pic blob
);
create index ind_picid on mypic(key);
key是图片名称，事先最好统一规划一下，使用number数字来命名，并针对key建立索引
VALUE就是图片内容，用blob来保存
访问一个图片的方式就是：
获取图片名称 数据key
走key上的索引，定位到记录表记录
根据表记录，定位到图片的blob，并读取
这个方法的优点：
1.单个图片的访问路径缩短，数字索引比较小，分区做的好的话可能小到两层，从索引到表，到blob段，大概是4-5跳
并且KEY是区分度非常高的数据类型，在索引每层的横向检索中，不会超过1个数据块，而文件目录结构中，子目录繁多，
要遍历这层的inode后，才知道具体跳转的下层位置
2.备份方式比较灵活，可以基于整个数据库，或者单独的表，数据的迁移，删除，都是基于表级别的，比较直观，方便
3.可以在数据库层面，考虑图片的水平拆分，垂直拆分，分表，分库，都不错
4.数据库的复制技术可以派上用场，读写分离
这里数据库完全是当成一个KEY-VALUE的存储在用，我们可以考虑将一些廉价的PC堆在一起，做成一个picdb的群集，
大致画了一个草图，当然在WEB与picdb间应该还有层cache的,这个方法是YY出来的，可能很多地方不成熟，但SY强身，YY强国，没有想法，哪来的动力？欢迎各位专业人士拍砖
