集群服务器

文档结构如下： 前言： Oracle 官方文档对索引的描述真是弱透了，对索引的说明就是一坨……，support也没有很好的资料，下面还是用的官方上的内容经过自己的整理加上网上的资料；至于为什么用索引，以及索引的重要性，相信大家都知晓；如果把数据库所有的表比如成一本书，那么，索引就是书的目录，你不可能每一次查看书的内容从第一页读到最后一页，不用目录吧！！ 索引类型： 索引是与表和群集关联的可选结构，可以使SQL查询对表执行得更快。正如本手册中的索引可以帮助您更快地找到信息（没有索引）一样，Oracle数据库索引提供了对表数据的更快访问路径。您可以使用索引而无需重写任何查询。结果是相同的，但是可以更快地看到它们。 Oracle数据库提供了几种索引方案，这些方案提供了互补的性能功能。这些是： B树索引：默认索引和最常见索引 B树集群索引：专门为集群定义 哈希集群索引：专门为哈希集群定义 全局和局部索引：与分区表和索引有关 反向键索引：对Oracle Real Application Clusters应用程序最有用 位图索引：紧凑；最适合具有少量值的列 基于函数的索引：包含函数/表达式的预先计算的值 域索引：特定于应用程序或盒带。 索引在逻辑上和物理上独立于关联表中的数据。作为独立的结构，它们需要存储空间。您可以创建或删除索引，而不会影响基表，数据库应用程序或其他索引。当您插入

导读 本文转载自MySQL解决方案工程师 作者：徐铁韬 这篇文章将详细地介绍MySQL的高可用解决方案—— MySQL InnoDB Cluster。 说到高可用性，首先要了解一下什么是高可用性？ 高可用性要求的实际上是对可靠性的要求，从本质上来说，是通过技术和工具来提高可靠性，尽可能长时间保持数据的可用和系统的正常运行时间。实现高可用性的原则为排除单点故障、通过冗余实现快速恢复，并且具有容错机制。 上面一页主要介绍了几个关键词汇，以及相关的定义，这些有助于理解可靠性和高可用性。 MySQL的高可用性解决方案目前大致分为5种，按照高可用的级别（99.9999%为最高级）排序依次为，主从复制、具有自动故障转移功能的主从复制、利用共享存储、OS或虚拟化软件实现主备架构、MySQL Group Replication 群组复制，以及MySQL NDB Cluster。 MySQL Replication：允许数据从一台实例上复制到一台或多台其它的实例上。 MySQL Group Replication：群组复制提供更好的冗余性、自动恢复以及写入扩展。 MySQL InnoDB Cluster：基于群组复制，提供了易于管理的API、应用故障转移和路由、易于配置，提供比群组复制更高级别的可用性。 MySQL NDB Cluster：容易与MySQL InnoDB Cluster混淆

前言 OpenStack是 模仿亚马逊 AWS 使用python开发的 IssA层实现框架 ，openstack遵循Apache2.0协议，使我兴奋的是它的WEB管理模块 horizon ，是使用Django开发的，站在巨人的肩膀上，也许我可以对其 进行二次开发； openstack涉及知识大而全，本文主要介绍openstack以下内容 openstack概念 openstack主要 组件的介绍 以及 组件间的通信流程 openstack支持的几种网络模式 （vlam/ gre/ vxlan） openstack支持的分布式存储 （Ceph） 基于openstack搭建一个iaas层私有云环境 什么是OpenStack OpenStack是一个由NASA（ 美国国家航空航天局 ）和Rackspace合作研发并发起的，以 Apache 许可证授权的 自由软件 和 开放源代码 项目。 该项目采用了模块化设计 由众多的模块组成1个框架，各个模块负责自己不同的功能； 0.核心组件： Horzion ：提供web页面让用户管理主机（创建主机、挂载云盘、绑定浮动IP） Nova： 支持各种虚拟机驱动（Vmware/Zen/KVM）调用虚拟机驱动创建出主机；（硬件资源供应商） Glance ：给虚拟机提供镜像；（操作系统供应商） Newtron ：Neurton实现了SDN(软件定义网络

设计理念 1 时间换空间 1.1 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）， 反向代理缓存，应用端的缓存(memcache)，内存数据库，Buffer、cache机制（数据库，中间件等）。 1.2 索引 哈希、B树、倒排、bitmap 哈希索引:适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引:适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引:实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap:是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 2.1 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2.2 多进程

Spark简介 Spark是一种快速、通用、可扩展的大数据分析引擎，目前，Spark生态系统已经发展成为一个包含多个子项目的集合，其中包含SparkSQL、Spark Streaming、GraphX、MLlib等子项目，Spark是基于内存计算的大数据并行计算框架。简单来说Spark是 内存迭代计算，每个算子将计算结果保存在内存中，其他算子，读取这个结果，继续计算。 Spark的四个特性： 1.快 Spark实现了高效的DAG执行引擎，可以通过基于内存来高效处理数据流。 2.易用 Spark支持Java、Python和Scala的API，还支持超过80种高级算法，而且Spark支持交互式的Python和Scala的shell，可以非常方便地在这些shell中使用Spark集群来验证解决问题的方法。 依赖外部数据源hdfs、本地文件.kafka.flume.mysql.ELK） 3.通用 Spark提供了统一的解决方案。Spark可以用于批处理、交互式查询（Spark SQL）、实时流处理（Spark Streaming）、机器学习（Spark MLlib）和图计算（GraphX）。这些不同类型的处理都可以在同一个应用中无缝使用。 4.兼容性 Spark可以非常方便地与其他的开源产品进行融合。比如，Spark可以使用Hadoop的YARN和Apache

Zookeeper-3.4.14集群搭建 //先关闭防火墙（如果没有关闭防火墙，再多台机器之间不能连接） systemctl stop firewalld.service systemctl status firewalld systemctl start firewalld 解压 tar -zxvf zookeeper-3.4.14.tar.gz 1 修改配置文件 cd /usr/local/software/zookeeper-3.4.14/conf/ cp zoo_sample.cfg zoo.cfg vi zoo.cfg 修改zoo.cfg文件中 dataDir dataDir=/opt/data/zookeeper 启动zookeeper 启动zookeeper服务端 [root@node01 zookeeper-3.4.14]# bin/zkServer.sh start // 启动服务端 ZooKeeper JMX enabled by default Using config: /usr/local/software/zookeeper-3.4.14/bin/…/conf/zoo.cfg Starting zookeeper … STARTED [root@node01 zookeeper-3.4.14]# jps # 查看进程 7376 Jps 7358

前言 上篇文章梳理了redis的哨兵，截止到目前redis的原理已经梳理了四篇文章，键的过期策略、持久化、主从复制和redis哨兵，今天接着来梳理redis集群模式，之前我们谈到了主从复制是为了提高并发，哨兵模式是为了高可用，那么redis集群的意义是什么呢？这里我们先不谈redis集群的意义，我们来想象我们自己的业务系统的集群部署。 如上图所示一个简单的集群部署方式，在单机无法满足我们并发需求时，我们最常见的方式就是将服务集群部署来实现。redis的集群的架构思想其实和我们的服务集群部署是一样的，就我个人理解redis的集群模式有以下两个最直接的优点： 提高并发 水平扩充内存 redis集群简介 redis集群和我们的服务集群部署一样，由不同的节点组成一个集群，与我们系统不同的是redis集群不需要我们自己维护负载均衡，而是不同的节点负责不同的槽点，这个槽点可以放大理解为分片，放小看也可以认为是key的集合，假设我们的在一个redis集群里有两台redis服务器组成，那么我们就可以将这两台redis所负责的key进行划分，比如共有1000个key，那么redis-01负责1-500，redis-02负责501-1000，至于一个key到底是属于1-500还是501-1000是通过算法实现的。 节点握手 搭建redis集群的第一步是节点握手

一：集群部署准备工作 1.三台服务器： k8s-master：192.168.122.69 k8s-node-1: 192.168.122.232 k8s-node-2: 192.168.122.68 2.验证MAC和product_uuid的唯一性 检查MAC的唯一性： [ root@k8s-master ~ ] # ip link 1: lo: < LOOPBACK,UP,LOWER_UP > mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: < BROADCAST,MULTICAST,UP,LOWER_UP > mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 52:54:00:90:ee:f3 brd ff:ff:ff:ff:ff:ff [ root@k8s-node-1 ~ ] # ip link 1: lo: < LOOPBACK,UP,LOWER_UP > mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1 link

现在MapReduce/Hadoop以及相关的数据处理技术非常热，因此我想在这里将MapReduce的优势汇总一下，将MapReduce与传统基于HPC集群的并行计算模型做一个简要比较，也算是对前一阵子所学的MapReduce知识做一个总结和梳理。 引言 随着互联网数据量的不断增长，对处理数据能力的要求也变得越来越高。当计算量超出单机的处理能力极限时，采取并行计算是一种自然而然的解决之道。在MapReduce出现之前，已经有像MPI这样非常成熟的并行计算框架了，那么为什么Google还需要MapReduce，MapReduce相较于传统的并行计算框架有什么优势，这是本文关注的问题。 文章之初先给出一个传统并行计算框架与MapReduce的对比表格，然后一项项对其进行剖析。 传统 MapReduce 集群架构/容错性 共享式（共享内存/共享存储），容错性差 无共享式，容错性好 硬件/价格/扩展性 刀片服务器、高速网、SAN，价格贵，扩展性差 普通PC机（便宜），便宜，扩展性好 编程/学习难度 what+how，难 what，简单 适用场景 实时、细粒度计算、计算密集型 批处理、非实时、数据密集型 集群架构/容错性 在传统的并行计算中，计算资源通常展示为一台逻辑上统一的计算机。对于一个由多个刀片、SAN构成的HPC集群来说，展现给程序员的仍旧是一台计算机

1.单机安装（会的直接跳到下面集群安装） 下载，解压，安装 >> cd /usr/local/app >> wget http://download.redis.io/releases/redis-4.0.10.tar.gz >> tar -zxvf redis-4.0.10.tar.gz >> mv redis-4.0.10.tar.gz redis >> cd redis >> make MALLOC = libc >> make install 安装完成，这时候会在/usr/local/bin/目录下看到redis-server、redis-cli等可执行脚本，进入看一下，如果没有，就要去解压目录复制进去了。 修改配置 >> vim /usr/local/app/redis/redis.conf 修改以下两个地方 #默认是只有一个127.0.0.1，这个时候只能自己连接，其他局域网内是连接不上的。所以，需要配置多个 IP ，这样就可以局域网内进行连接了。我设置的0.0.0.0，虽然这不太安全，方便我在其它地方连接。 bind 0.0.0.0 ##后台启动 daemonize yes 启动redis >> redis-server /usr/local/app/redis/redis.conf ##查看是否启动成功 >> netstat -anp | grep 6379 >>