wzy0623的专栏

目录 一、DRBD简介 1. 工作原理 2. DRBD 支持的底层设备 3. DRBD资源 4. DRBD 配置工具 5. DRBD与RAID1区别 6. DRBD与共享存储 二、DRBD安装配置 1. 实验环境 2. 配置前准备 3. 下载安装DRBD 4. 配置DRBD 四、测试MySQL数据同步 五、heartbeat+DRBD+mysql高可用方案 1....

目录 一、测试目标 二、测试规划 三、测试过程 1. 缺省配置 2. 多线程 3. 流控 四、测试结论 参考： 本篇使用tpcc-mysql压测工具对实验环境的三节点Galera集群进行一系列性能测试。 一、测试目标 验证Galera的同步复制，检查是否存在复制延迟。 对比Galera与MySQL组复制的每秒事务数（TPS）。 验证多线程复制对Galera...

目录 一、管理 1. 在线DDL （1）TOI （2）RSU （3）pt-online-schema-change 2. 恢复主组件 （1）了解主组件状态 （2）修改保存的主组件状态 3. 重置仲裁 （1）查找最高级的节点 （2）重置仲裁 （3）自动引导 （4）手动引导 4. 管理流控 （1）监控流控 （2）配置流控 5. 自动逐出 （1）配置自动逐出 （2）...

目录 一、Galera集群实验环境 二、初始安装 1. 安装galera-3、mysql-wsrep-5.7、Percona-XtraBackup-2.4.15 2. 修改配置文件 3. 初始化集群 4. 启动集群其它节点的mysqld服务 5. 验证安装 6. 问题排查 三、使用SST增加节点 四、使用IST增加节点 1. 设置gcache.size 2. IST测试 ...

目录 一、同步复制 二、Galera复制架构 1. wsrep api 2. 全局事务ID（global transaction id，GTID） 3. Galera复制插件 4. 组通信插件 三、Galera复制工作原理 四、状态转移 1. 状态快照传输 2. 增量状态转移 3. 写集缓存（gcache） 五、流控 1. 流控原理 2. 理解节点状态 3. 节点状态...

下面的SQL脚本用于完成Data Vault的初始装载过程。 USE dv; SET AUTOCOMMIT = 0; -- 清空附属表、链接表、中心表 SET FOREIGN_KEY_CHECKS=0; TRUNCATE sat_customer; TRUNCATE sat_order_product; TRUNCATE sat_product; TRUNCATE sat_product_c

说明： 1. 定期装载的周期为每天一次。 2. 每天装载自上次装载后的变化数据 3. 建立源数据库的过渡表用于CDC 4. 建立cdc_time表用于基于时间戳的CDC 5. 因为源库上只有订单销售表有时间属性，所以除了sales_order和sales_order_item拉取变化数据外，其它表都整体拉取到过渡区。实际环境中建议在源表设计上应该有created和last_updated

总体作业： 设置日期变量： 清空过渡表： 装载过渡表：

装载中心表作业： 装载产品分类中心表： 装载客户中心表： 装载产品中心表： 装载销售订单中心表：

装载链接表作业： 装载订单客户链接表： 装载订单产品链接表： 装载产品-产品分类链接表：

装载附属表作业： 装载客户附属表： 装载订单_产品附属表： 装载产品附属表： 装载产品分类附属表：

（五）进阶技术         14. 维度合并         随着数据仓库中维度的增加，会发现有些通用的数据存在于多个维度中。例如，客户维度的客户邮编相关信息、送货邮编相关信息和工厂维度里都有邮编、城市和州。本篇说明如何把三个维度里的邮编相关信息合并到一个新的邮编维度。         修改数据仓库模式 为了合并维度，需要改变数据仓库模式。图（五）- 14-1显示了修改后的模式。新增

（五）进阶技术         8. 退化维度         本篇讨论一种称为退化维度的技术。该技术减少维度的数量，简化维度数据仓库的模式。简单的模式比复杂的更容易理解，也有更好的查询性能。当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把退化维度的相关数据迁移到事实表中，然后删除退化的维度。         退化订单维度         本节说明如何退化订单维度，包括对

（一）维度模型基础         既然维度模型是数据仓库建设中的一种数据建模方法，那不妨先看一下几种主流的数据仓库架构。         1. Kimball的DW/BI架构 图（一）- 1         2. Inmon企业信息工厂架构 图（一）- 2         3. 混合型架构 图（一）- 3         从图中可以看出，每

（五）进阶技术         1. 增加列         数据仓库最常碰到的扩展是给一个已经存在的维度表和事实表添加列。本篇先讨论如果需要增加列，模式会发生怎样的变化。然后进一步说明如何在客户维度和销售订单事实表上添加列，并在新列上应用SCD2。假设需要在客户维度中增加送货地址属性，并在销售订单事实表中增加数量度量值。         修改数据库模式         图（五）- 1-1

（五）进阶技术         2. 按需装载         前面已经做了“初始装载”和“定期装载”。还有一种需要熟悉的装载类型，按需装载。所谓“按需装载”指的是，在正常调度之外，当源数据有效时或者数据仓库需要时进行装载。例如，促销销售源数据只有在促销期内有效，而在其它时间是无效的。         在“准备数据仓库模拟环境”中讨论的“生成日期维度数据”可以看做是一种按需装载。数据仓库

（五）进阶技术         5. 快照         前面实验说明了处理维度的扩展。本篇讨论两种事实表的扩展技术。         有些用户，尤其是管理者，经常会要看某个特定时间点的数据。也就是说，他们需要数据的快照。周期快照和累积快照是两种处理事实表扩展的技术。         周期快照是在一个给定的时间对事实表进行一段时期的总计。例如，一个月销售订单周期快照是每个月底时总的销售订

（三）初始装载         在数据仓库可以使用前，需要装载历史数据。这些历史数据是导入进数据仓库的第一个数据集合。首次装载被称为初始装载，一般是一次性工作。由最终用户来决定有多少历史数据进入数据仓库。例如，数据仓库使用的开始时间是2015年3月1日，而用户希望装载两年的历史数据，那么应该初始装载2013年3月1日到2015年2月28日之间的源数据。在2015年3月2日装载2015年3月1日的

（五）进阶技术         7. 多路径和参差不齐的层次         本篇讨论多路径层次，它是对单路径层次的扩展。上一篇里数据仓库的月维度只有一条层次路径，即年-季度-月这条路径。在本篇中加一个新的级别，推广期，并且加一个新的年-推广期-月的层次路径。这时月维度将有两条层次路径，因此具有多路径层次。本篇讨论的另一个主题是不完全层次，这种层次在它的一个或多个级别上没有数据。

（五）进阶技术         10. 多重星型模式         从（五）进阶技术1.  “增加列”开始，已经通过增加列和表扩展了数据仓库，在（五）进阶技术5. “快照”里增加了第二个事实表，month_end_sales_order_fact表。这之后数据仓库模式就有了两个事实表（第一个是在开始建立数据仓库时创建的sales_order_fact表）。有了这两个事实表的数据仓库就是一个正

最近看了三本关于数据仓库的书，很有收获，也很受启发。这三本书分别是《数据仓库工具箱（第三版）》、《Dimensional Data Warehousing with MySQL: A Tutorial》和《Pentaho Kettle解决方案》。在仔细研读了这三本书之后，感觉就像是一本书的三个层次。Ralph Kimball的经典著作数据仓库工具箱阐述的是维度建模方法论和按不同行业建模的示例。Di

（五）进阶技术         16. 分段维度         本篇说明分段维度的实现技术。分段维度包含连续值的分段。例如，年度销售订单分段维度可能包含有叫做“低”、“中”、“高”的三档；各档定义分别为0.01到15000、15000.01到30000.00、30000.01到99999999.99。如果一个客户的年度销售订单金额为10000，则被归为“低”档。 分段维度可以存储多个分段集

（二）准备数据仓库模拟环境         上一篇说了很多数据仓库和维度模型的理论，从本篇开始落地实操，用一个小而完整的示例说明维度模型及其相关的ETL技术。示例数据库和ETL的SQL实现是在《Dimensional Data Warehousing with MySQL: A Tutorial》基础上做了些修改，增加了Kettle实现的部分。本篇详细说明数据仓库模拟实验环境搭建过程。

（四）定期装载         初始装载只在开始数据仓库使用前执行一次，然而，必须要按时调度定期执行装载源数据的过程。本篇说明执行定期装载的步骤，包括识别源数据与装载类型、使用SQL和Kettle两种方法开发和测试定期装载过程。         从源抽取数据导入数据仓库有两种方式，可以从源把数据抓取出来（拉），也可以请求源把数据发送（推）到数据仓库。影响选择数据抽取方式的一个重要因素是源数

（五）进阶技术         3. 维度子集         有些需求不需要最细节的数据。例如更想要某个月而不是某天的记录。再比如相对于全部的销售数据，可能对某些特定状态的数据更感兴趣等。这些特定维度包含在从细节维度选择的行中，所以叫维度子集。维度子集比细节维度小，因此更易使用，查询也更快。         本篇中将准备两个特定维度，它们均取自现有的维度：月份维度（日期维度的子集），P

（五）进阶技术         13. 迟到的事实         装载日期在生效日期后的事实就是迟到的事实。晚于订单日期进入源数据的销售订单可以看做是一个迟到事实的例子。销售订单被装载进其事实表时，装载的日期晚于销售订单的订单日期，因此是一个迟到的事实。（因为定期装载的是前一天的数据，所以这里的晚于指的是晚2天及其以上。）         迟到事实影响周期快照事实表的装载，如（五）进阶

（五）进阶技术         4. 角色扮演维度         当一个事实表多次引用一个维度表时会用到角色扮演维度。例如，一个销售订单有一个是订单日期，还有一个交货日期，这时就需要引用日期维度表两次。         本篇将说明两类角色扮演维度的实现，分别是表别名和数据库视图。这两种都使用了MySQL的功能。表别名是在SQL语句里引用维度表多次，每次引用都赋予维度表一个别名。而数据库

（五）进阶技术         6. 维度层次         大多数维度都具有一个或多个层次。例如，日期维度就有一个四级层次：年、季度、月和日。这些级别用date_dim表里的列来表示。日期维度是一个单路径层次，因为除了年-季度-月-日这条路径外，它没有任何其它层次。除此之外，本篇还将讨论在维度的层次上进行分组和钻取查询。多路径层次在下一篇“多路径和参差不齐的层次”中讨论。

（五）进阶技术         9. 杂项维度         本篇讨论杂项维度。简单地说，杂项维度就是一种包含的数据具有很少可能值的维度。例如销售订单，它可能有很多离散数据（yes-no这种类型的值），如 verification_ind（如果订单已经被审核，值为yes）credit_check_flag（表示此订单的客户信用状态是否已经检查）new_customer_ind（如果这是

（五）进阶技术         11. 间接数据源         本篇讨论如何处理间接数据源。间接数据源与维度表具有不同的粒度，因此不能直接装载进数据仓库。在这里通过修改（五）进阶技术7. “多路径和参差不齐的层次”里的推广源数据说明怎样处理间接数据源。 CAMPAIGN SESSION,MONTH,YEAR 2014 First Campaign,1,2014 2014 First

（五）进阶技术         12. 无事实的事实表         本篇讨论一种技术，用来处理源数据中没有度量的需求。例如，产品源数据不包含产品数量信息，如果系统需要得到产品的数量，很显然不能简单地从数据仓库中直接得到。这时就要用到无事实的事实表技术。使用此技术可以通过持续跟踪产品的发布来计算产品的数量。可以创建一个只有产品（计什么数）和日期（什么时候计数）维度代理键的事实表。之所以叫做无

（五）进阶技术         15. 累积的度量         本篇说明如何实现累积月底金额，并对数据仓库模式和初始装载、定期装载脚本做相应地修改。累积度量是半可加的，而且它的初始装载比前面做的要复杂的多。         可加、半可加、不可加事实         事实表中的数字度量可划分为三类。最灵活、最有用的度量是完全可加的，可加性度量可以按照与事实表关联的任意维度汇总。半可加

源数据库模型（3NF）如下图： 星型模型如下图： Data Vault模型如下图： 说明： 星型模型（star schema）的事实表采取了完全规范化的第三范式（3NF）模型，而维表采取了第二范式的设计模型。有时也会把维表的设计规范化，就成了所谓的雪花模型（snowflake schema）。 星型模型向Data Vault模型转化： 星型模趔的主要构成部分是维表与事实

一、概述         MySQL Fabric这一新的架构为MySQL提供了高可用和向外扩展的特性。本实验专注于使用Fabric对多个MySQL服务器进行读写实现向外扩展。当单个MySQL服务器（或HA组）的写性能达到极限时，可以使用Fabric把数据分布到多个MySQL服务器组。注意这里说的组可以是单一服务器，也可以是HA组。管理员通过建立一个分片映射定义数据如何在多个服务中分片。一个分片

实验步骤： 1. 安装虚拟机         使用VirtualBox安装四个CentOS release 6.4虚拟机，安装Python 2.6或以上版本，关闭iptables和selinux。虚拟机和网卡说明如下表所示。 主机名 内部网络IP 说明 fab_connector 192.168.56.101 安装

摘自：《Pentaho Kettle 解决方案: 使用PDI构建开源ETL解决方案》         Data Vault（DV）模型是用于企业级的数据仓库建模。由Dan Linstedt在20世纪90年代提出（http://www.danlinstedt.com）。在最近几年，Data Vault模型获得了很多关注，并在BI社区里拥有了一批追随者。         Dan Linsted

摘自：《下一代数据仓库模型Data Vault的研究及其应用》         Data Vault模型的构建         在Data Vault模型中，各个实体组件有着严格、通用的定义与准确、灵活的功能描述，这不但使得Data Vault模型能够最直观、最一般地反映数掘之间内含的业务规则，同时也为构建Data Vault模型提供了一致而普遍的方法。 简单地讲，Data Vault模

本示例源数据库是一个订单销售的普通场景，共有省、市、客户、产品类型、产品、订单、订单明细7个表。ERD如下图所示。 使用下面的脚本建立源数据库表： CREATE TABLE province ( province_id varchar(2) NOT NULL COMMENT '省份编码', province_name varchar(20) DEFAULT NULL COMMENT

一、概述         MySQL Fabric这一新的架构为MySQL提供了高可用和向外扩展的特性。本实验专注于高可用。高可用指的是系统提供持续服务的能力。下图显示了一个系统中应该为服务可用提供的不同层次。         MySQL Fabric在MySQL复制上增加了一个管理和监控层，它和一组MySQL Fabric-aware连接器一起，把写和一致性读操作路由的当前的主服务器

原文出自http://blog.itpub.net/29254281/viewspace-1851457/ 借鉴Oracle Hr模式下的Employees表的结构和数据 DROP TABLE IF EXISTS `employees`; CREATE TABLE `employees` (   `employee_id` int(11) NOT N