master

【巨杉数据库SequoiaDB】巨杉 Tech | SequoiaDB SQL实例高可用负载均衡实践

不羁岁月 提交于 2020-03-25 00:59:08
1 前言 在应用程序中,应用配置连接的数据库IP地址和端口号都是固定一个的,当所属IP地址的服务器宕机后,需要人为手工更改IP地址切换数据库服务器。同时当应用接收到成千上万的并发 http 请求时,会导致服务器消耗大量系统资源,轻则响应速度降低,严重的甚至会引发宕机。 为了充分合理的利用服务器资源,提高数据服务的性能和稳定性,在较低成本的前提下,保证在部分服务器宕机或发生故障的情况下不影响业务的正常运作。本文主要介绍 Nginx+Keepalived 连接 SequoiaDB -MySQL 实例的高可用方案与实践。 2 SequoiaDB 数据库介绍 SequoiaDB 巨杉数据库是一款完全自研的金融级分布式数据库产品,采用计算与存储分离架构,由数据库实例层和数据库存储引擎层组成。数据库实例层负责解析请求并转发至数据库存储引擎层处理,同时会将数据库存储引擎层的响应结果反馈给应用层,数据库实例层支持包括针对结构化数据的 MySQL 实例、PostgreSQL 实例、SparkSQL 实例,以及针对非结构化数据的 S3 和 PosixFS 文件系统的对象存储实例实例,而数据库存储引擎层是由 SequoiaDB 巨杉数据库的协调节点、编目节点和数据节点组成。该数据库集群架构能方便用户实现由传统数据库到巨杉数据库的无缝迁移,减少应用开发者的开发和学习成本。 2.1 SequoiaDB

kubeadm部署kubernetes v1.17.4 单master节点

不羁岁月 提交于 2020-03-24 17:46:35
环境说明: #操作系统:centos7 #docker版本:19.03.8 #kubernetes版本:v1.17.4 #K8S master 节点IP:192.168.3.62 #K8S worker节点IP:192.168.2.186 #网络插件:flannel #kube-proxy网络转发: ipvs #kubernetes源:使用阿里云源 #service-cidr:10.96.0.0/16 #pod-network-cidr:10.244.0.0/16 部署准备: 操作在所有节点进行 修改内核参数: 关闭swap vim /etc/sysctl.conf vm.swappiness=0 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-arptables=1 sysctl -p 临时生效 swapoff -a && sysctl -w vm.swappiness=0 修改 fstab 不在挂载 swap vi /etc/fstab /dev/mapper/centos-swap swap swap defaults 0 0 安装docker yum-config

我的 K8S 架构搭建 之旅

不问归期 提交于 2020-03-24 12:24:31
一、总体框架图: Master组件: nkube-apiserver Kubernetes API,集群的统一入口,各组件协调者,以HTTP API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。 nkube-controller-manager 处理集群中常规后台任务,一个资源对应一个控制器,而ControllerManager就是负责管理这些控制器的。 nkube-scheduler 根据调度算法为新创建的Pod选择一个Node节点。 Node组件: nkubelet kubelet是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、 下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。 nkube-proxy 在Node节点上实现Pod网络代理,维护网络规则和四层负载均衡工作。 ndocker或rocket/rkt 运行容器。 第三方服务: netcd 分布式键值存储系统。用于保持集群状态,比如Pod、Service等对象信息。 二、部署的步骤: 1、环境规划 2、安装Docker 3、自签TLS证书 4、部署Etcd集群 5、部署Flannel网络 6、创建Node节点kubeconfig文件 7、获取K8S二进制包 8

三、git学习之——管理修改、撤销修改、删除文件

一世执手 提交于 2020-03-24 07:13:39
一、管理修改 现在,假定你已经完全掌握了暂存区的概念。下面,我们要讨论的就是,为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件。 你会问,什么是修改?比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。 为什么说Git管理的是修改,而不是文件呢?我们还是做实验。第一步,对readme.txt做一个修改,比如加一行内容: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes. 然后,添加: $ git add readme.txt $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: readme.txt # 然后,再修改readme.txt: $ cat readme.txt Git is

Haproxy+Keepalived(双机热备)搭建高可用web架构

旧时模样 提交于 2020-03-23 23:05:08
1、目的 搭建web高可用架构,用haproxy作为前段负载均衡分摊后端web服务器压力,Keepalived保证haproxy的存活(双机热备:一台haproxy挂了,自动切换到另外一台haproxy上) 2、环境(系统均为centos7,防火墙与selinux都关闭) 192.168.0.100:web1(端口7000)、web2(端口8000) 192.168.0.101:haproxy1、keepalived(MASTER) 192.168.0.102:haproxy2、keepalived(BACKUP) 虚拟ip(VIP):192.168.0.11(端口8600) 3、搭建web1与web2 在192.168.0.100上安装docker,运行两个容器分别是web1与web2 4、分别在master和backup节点上安装haproxy与keepalived 直接yum安装,过程省略。。。 5、配置haproxy(在master与backup节点配置相同) 编辑配置文件/etc/haproxy/haproxy.cfg 在最后添加后端web主机的访问地址 backend webapp balance roundrobin server web1 192.168.0.101:7000 check inter 2000 fall 3 weight 1 server web2

使用Git将最新提交移至新分支

假装没事ソ 提交于 2020-03-23 20:55:09
3 月,跳不动了?>>> 问题: I'd like to move the last several commits I've committed to master to a new branch and take master back to before those commits were made. 我想将我已承诺掌握的最后几个提交移动到新的分支,并在做出这些提交之前将master重新带回去。 Unfortunately, my Git-fu is not strong enough yet, any help? 不幸的是,我的Git-fu还不够坚固,有什么帮助吗? Ie How can I go from this 即我该如何去 master A - B - C - D - E to this? 对此吗? newbranch C - D - E / master A - B 解决方案: 参考一: https://stackoom.com/question/6pf9/使用Git将最新提交移至新分支 参考二: https://oldbug.net/q/6pf9/Move-the-most-recent-commit-s-to-a-new-branch-with-Git 来源: oschina 链接: https://my.oschina.net/u/3797416/blog

为什么数据库读写分离可以提高性能

我与影子孤独终老i 提交于 2020-03-23 17:59:32
3 月,跳不动了?>>> 虽然知道处理大数据量时,数据库要做读写分离,但是为什么读写分离可以提高性能呢? 下面是搜来的一些解释,看看再说! 一 什么是读写分离 MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询,而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中 的从数据库。 当然,主服务器也可以提供查询服务。使用读写分离最大的作用无非是环境服务器压力。可以看下这张图: 二 读写分离的好处 1.增加冗余 2.增加了机器的处理能力 3.对于读操作为主的应用,使用读写分离是最好的场景,因为可以确保写的服务器压力更小,而读又可以接受点时间上的延迟。 三 读写分离提高性能之原因 1.物理服务器增加,负荷增加 2.主从只负责各自的写和读,极大程度的缓解X锁和S锁争用 3.从库可配置myisam引擎,提升查询性能以及节约系统开销 4.从库同步主库的数据和主库直接写还是有区别的,通过主库发送来的binlog恢复数据,但是,最重要区别在于主库向从库发送binlog是异步的,从库恢复数据也是异步的 5.读写分离适用与读远大于写的场景,如果只有一台服务器,当select很多时,update和delete会被这些select访问中的数据堵塞,等待select结束,并发性能不高。

如果有一个特别大的访问量到数据库上,怎么做优化?主从复制、读写分离

余生颓废 提交于 2020-03-23 17:07:34
第一个就是使用优化查询的方法。这个在前期的内容中有具体说明,这里不再做说明。 第二、这里简要说明一个以下几个方法:    主从复制、读写分离、负载均衡    目前,大部分的主流关系型数据库都提供了主从复制的功能,通过配置两台(或多台)数据库的主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站可以利用数据库的这一功能, 实现数据库的读写分离,从而改善数据库的负载压力。 一个系统的读操作远远多于其写操作,因此写操作发向master,读操作发向slaves进行操作(简单的轮循算法来决定使用哪个slave)。   利用数据库的读写分离,web服务器在写数据的时候,访问著数据库(Master),主数据库通过主从复制机制将数据更新同步到从数据库(Slave),这样web服务器读数据的时候,就可以通过从数据库获得数据。这一方案使得在大量读操作的web应用可以轻松地读取数据,而主数据库也只会承受少量的写入操作,还可以实现数据热备份,可谓是一举两得的方案。 1.复制的基本原则    MySQL复制是异步的且串行化的;   每个Slave只有一个Master;   每个Slave只有一个唯一的服务器ID;   每个Master可以有多个Slave; 2.一主一从常见配置:   MySQL版本一致且后台以服务运行;   主从都配置在[mysqld]结点下,都是小写,主机修改my

华为云3

跟風遠走 提交于 2020-03-23 09:14:03
[root@room9pc01 ~]# scp -r /var/ftp/local/ 139.9.60.12:/var/ftp/local/ [root@ecs-abc local]# cat /etc/yum.repos.d/local.repo [local] name=local baseurl=file:///var/ftp/local enabled=1 gpgcheck=0 [root@ecs-abc local]# ls mysql-community-client-5.7.17-1.el7.x86_64.rpm mysql-community-common-5.7.17-1.el7.x86_64.rpm mysql-community-devel-5.7.17-1.el7.x86_64.rpm mysql-community-embedded-5.7.17-1.el7.x86_64.rpm mysql-community-embedded-compat-5.7.17-1.el7.x86_64.rpm mysql-community-embedded-devel-5.7.17-1.el7.x86_64.rpm mysql-community-libs-5.7.17-1.el7.x86_64.rpm mysql-community-libs-compat-5.7.17

MySQL主从修复

隐身守侯 提交于 2020-03-23 09:13:52
MySQL主从故障修复 测试库: 192.168.1.2 主 192.168.1.3 从 192.168.1.4 主 4又是2的从库 192.168.1.5 从 有人修改了192.168.1.2和192.168.1.3的数据库参数后,重启数据库。 忘记了192.168.1.4又是192.168.1.2的从库,导致192.168.1.2和192.168.1.4的主从断掉。 并且在192.168.1.2上创建了新库还原数据删除等操作,导致192.168.1.4提示错误。 模拟如下: 通过从库查看主从状态: mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.16.33.243 Master_User: master Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000006 Read_Master_Log_Pos: 303 Relay_Log_File: relay-log.000005 Relay_Log_Pos: 340 Relay_Master