MySQL从库的Crash Safe
最近测试环境的一个三节点的MySQL GR集群(单主)的一个从节点发生了宕机,重启恢复后,过了一会监控系统告警,刚刚宕机的这个节点退出了GR集群。原因是主库上对某条数据的修改复制到从库后,在这个从库上找不到这条数据(slave_exec_mode=STRICT),第一反应就是主库和从库出现了不一致。因为是测试环境,数据量不大,所以采取的方案是将从库重建(团队没有专门的DBA)。接下来特意查看了一下MySQL复制和从库宕机恢复这块的资料。
最近测试环境的一个三节点的MySQL GR集群(单主)的一个从节点发生了宕机,重启恢复后,过了一会监控系统告警,刚刚宕机的这个节点退出了GR集群。原因是主库上对某条数据的修改复制到从库后,在这个从库上找不到这条数据(slave_exec_mode=STRICT),第一反应就是主库和从库出现了不一致。因为是测试环境,数据量不大,所以采取的方案是将从库重建(团队没有专门的DBA)。接下来特意查看了一下MySQL复制和从库宕机恢复这块的资料。
最近正在制定将团队生产环境的Kubernetes集群从1.6升级1.7的计划。 Kubernetes 1.8已经发布,所以准备考虑从1.6到1.7的升级。 准备 当前1.7的最新版本是1.7.8。在做准备之前需要仔细读一遍官方的Kubernetes 1.7 - Action Required Before Upgrading。 使用ansible升级k8s的核心组件 目前我们总共有两个高可用的Kubernetes集群,分别是测试环境和生产环境,版本都是1.6.10。 这两套环境的Kubernetes集群都是基于ansible自动部署,在1.6.x的每个小版本的升级也都是使用ansible完成。
kubeadm是Kubernetes官方提供的快速安装和初始化Kubernetes集群的工具,目前的还处于孵化开发状态,伴随Kubernetes每个版本的发布都会同步更新。 当然,目前的kubeadm是不能用于生产环境的。 但伴随着Kubernetes每次版本升级,kubeadm都会对集群配置方面的一些实践做调整,通过实验kubeadm我们可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
前面已经成功部署了OpenVPN的服务端。客户端和服务端采用的是基于TLS的双向认证,需要给每个客户端生成客户端私钥和证书。本篇将在OpenVPN服务端集成的OpenLDAP认证,这样能够使客户端用户在连接VPN时直接使用统一的OpenLDAP账号。部署的环境和版本信息如下:
为了方便团队成员从异地访问开发环境,考虑使用OpenVPN搭建虚拟局域网。部署的环境和版本信息如下: CentOS 7 OpenVPN 1.easy-rsa生成证书 从这里下载easy-rsa。 unzip easy-rsa-old-master.zip cd easy-rsa-old-master/easy-rsa/2.0 ls build-ca build-key-pkcs12 inherit-inter pkitool build-dh build-key-server list-crl revoke-full build-inter build-req openssl-0.9.6.cnf sign-req build-key build-req-pass openssl-0.9.8.cnf vars build-key-pass clean-all openssl-1.0.0.cnf whichopensslcnf ln -s openssl-1.0.0.cnf openssl.cnf 可修改vars文件中定义的变量用于生成证书的基本信息。下面生成CA证书:
目前我们线上环境使用的Kubernetes Dashboard的版本是1.6.1,这里记录一下升级到1.6.3的过程。 Dashboar和Heapster组件主要包含如下部署文件: kubernetes-dashboard.yaml heapster-rbac.yaml heapster.yaml influxdb.yaml 当前对应的docker镜像及版本如下: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.3 gcr.io/google_containers/heapster-amd64:v1.4.0 gcr.io/google_containers/heapster-influxdb-amd64:v1.3.3 从gcr pull这些镜像,并将其推送到我们的docker私有仓库:
前面我们已经在Kubernetes上部署了Redis - 《在Kubernetes上使用Sateful Set部署Redis》。 本篇我们继续把RabbitMQ也跑在K8S上。 1.RabbitMQ的基础知识 在正式开始部署工作之前,我们先来复习一下RabbitMQ的一些基础知识。 RabbitMQ内建的集群功能可以实现其高可用,允许消费者和生产者在RabbitMQ节点崩溃的情况下继续工作,同时可以通过添加更多的节点来提高消息处理的吞吐量。
DaemonSet好比Kubernetes集群Node的守护进程,可以保证在每个Node上(或者一部分Node上)都运行同一个Pod。 目前我们的线上环境主要用到以下两个DaemonSet: kube-flannel-ds 这个是部署Kubernetes集群时选用的是flannel network add-on fluent-bit 这个是用来在部署在各个Node上,收集各个Node上容器的日志。我们选用的日志收集方案是EFK(Elasticsearch+Fluent-bit+Kibana),后边有时间再写点fluent-bit的内容 我们目前线上Kubernetes的版本总是落后最新的release版本,例如现在Kubernetes最新是1.7,我们使用1.6.x。但是我们注意到Kubernetes 1.7中很多外部组件、Addon都做了更新。我们在使用1.6.x的过程中会考虑提前升级这些组件,以便于后续顺利将Kubernetes升级到1.7。DaemonSet的升级就是需要考虑的。
Kubernetes集群使用Cron Job管理基于时间的作业,可以在指定的时间点执行一次或在指定时间点执行多次任务。 一个Cron Job就好像Linux crontab中的一行,可以按照Cron定时运行任务。 定时任务对我们并不陌生,例如Linux的crontab,各种编程语言都内置了定时任务支持,这在我们应用开发中比较常见,但这种定时任务在分布式系统中使用会有限制,因此需要分布式计划任务。 Kubernetes的CronJob可以理解为Kubernetes对分布式计划任务的支持。
thumbor介绍 图片处理服务是互联网产品开发中必不可少的服务,有很多图片处理引擎如ImageMagic, Graphicsmagic, OpenCV等,我们之前的实现是在我们的对象存储前面搭建了Nginx+Lua+GraphicsMagick的组合,用Lua脚本实现了图片缩放和处理等功能。 最近要搭建独立的图片处理微服务,因此需要对一些图片处理系统做一些调研,就是其中之一。