sdmei

虽然是公有云的鼻祖，AWS在某些产品的实现却太不给力；可能是习惯了阿里云喂到嘴边的感觉，AWS很多方案需要自己折腾，蛋疼！比如这里要讲的mysql数据同步方案。阿里云产品DTS，点几下就OK了，AWS，只能通过插件安装、配置、调试、蹚坑……，具体就是用msk的debezium插件连接器。没见识过的一脸懵逼，下面说下配置步骤和一些注意的坑。

功能看起来很简单，但麻雀虽小五脏俱全。直接操作生成环境的eureka\k8s，做了很多校验和保护，最终才敢在生产环境上线。技术栈：vue（element-plus）+flask技术上的关键点标签页和穿梭框，父子组件之间的通信，子组件选择应用后父组件动态响应；前后端分离，每个后端接口需要认证才能访问；每个应用的2个服务，在K8S中必须有1个共同的标签，和1个不同的标签如order-server应用，2个deployment的标签:功能上的关键点。

应用没有配置自动重试机制，因此发布或其他原因关闭时，调用方未及时更新本地缓存的IP，继续调用必然会有很多500错误。可用性低或访问量低的服务可能无感，但咱可是全国第四的充电SAAS平台，肯定不能接受这样的问题。要解决这个问题，K8S的prestop钩子函数就能派上用场了，即容器销毁前，先执行下线操作。容器销毁前，执行prestop.sh脚本，脚本的参数时注册在eureka中的名称。

环境：阿里云 + k8s + springcloud + prometheus + oss。poststart.sh调用上述python脚本（profile直接从环境变量中获取）目前我采用的方案是根据CPU负载自动执行jstack，并将文件上传到OSS。文件名最后的数字是当时的CPU使用量，如166指1.66C。逻辑主要在脚本：mon_cpu_jstack.py。oss相关的文件包括：oss客户端和配置文件；第三层目录：具体jstack文件。第一层目录：profiles。第二层目录：应用名称。

1.MSE是啥阿里云MSE（Microservices Engine）微服务引擎含以下三个主要模块：微服务注册中心、微服务治理和云原生网关。其中微服务治理功能中的标签路由，可以实现灰度功能。2.灰度需求除了流量入口（如桩服务、gateway服务等），所有后端服务都要能支持按版本分组；将应用的相关版本隔离成一个独立的运行环境，通过设置流控路由规则，将满足规则的请求流量路由到目标版本应用。示意图：线上服务版本v1111; 新版版本v2222，即灰度版本； 设置流量规则，满足规则的流.

大数据同事抽数的程序有点low，没有自动适配表的字段变化，需要写个脚本自动监控字段变化，并报警到钉钉群。思路很简单：python，定时获取目标表的字段，持久化到文件，作为下一次比对的依据；下一次获取当前字段，与上次持久化的字段对比，有新增或删除的字段报警；直接上脚本：rds_col_monitor.py#!/usr/bin/python3# -*- coding: utf-8 -*-# @Time : 2021-12# @Author : meishidongimpo

1.线上环境现状基于K8S容器化，spring cloud架构，eureka注册中心； 通过jenkins发布； 后端微服务使用AB版本发布（类似通常的蓝绿发布，我司内部俗称AB版本）；2.引入AB版本的原因分步验证（个人觉得这个作用有限，类似实现了50%的灰度）； 服务未配置重试机制，为了防止发布过程中删除老版后调用方继续调用老服务导致报错，需要手动在注册中心下线老版服务，然后再删除；AB版本可以在删除老版前快速回退3.AB版本发布流程因jenkins对上述步骤的界面...

之前处理mysql历史数据归档，直接写存储过程实现的（见方案《mysql历史数据自动归档》），换新东家后，还是决定研究下主流的pt-archiver并实施。mysql除了社区版，还有percona、mariadb两个分支；其中percona是一家做mysql咨询的公司，除了开发了自己的mysql分支外，还开发了大量的mysql运维工具，统称percona toolkit。使用最为广泛的，如pt-online-schema-change：解决DDL锁表问题，pt-archiver：数据归档。..

1. 基本概念和原理1.1.document(文档)数据记录，与关系数据库中的表记录类似。document由字段构成，每个字段有其特点的type，如integer, long, boolean, ip, keyword, text等等。1.2.index(索引)index是document的集合，与关系数据库中的table类似。index有静态特性和动态特性；静态特性在创建时指定，创建后不可修改，如index.number_of_shards（索引主分片的数量）；动态特性在创建后可.

规范目的：为研发人员在mysql表结构设计与SQL编码提供指导意见；规范等级：每个规范的强度由强到弱分为：强制、推荐、参考三个等级；规范范围：建表、建索引、SQL语句、编程框架

1. 前言这个世界离不开时间，同样，数据库中也是如此，表中的每条记录除了数据模型的时间字段（如生日，生产日期，出发日期等），一般至少还有两个固定的时间字段：记录插入时间，记录更新时间。然而，看似很简单时间字段，谁能想到会导致应用报错，引发血案：个中缘由，正是接下来要讲到的。2. mysql中的时间字段因时间字段的一些特性与版本有关，且目前我司统一使用的mysql 5.7版本，因此本文内容都基于mysql 5.7。mysql时间相关的字段主要有DATE、DATETIME、TIMESTA

随着应用程序版本的发布，k8s环境会留下大量过期的镜像占用空间，因此需要通过任务自动清理。crontab任务调用以下脚本即可：1.节点镜像清理删除dangling镜像docker image prune -f删除无容器使用的镜像，外加条件：创建于10天前、限于应用程序imagedocker image prune -a --force --filter "label=t...

pt-query-digest 3.0.11后续版本，生成的checksum包含英文字母，点击SQL的checksum进详情页提示：“Unknown checksum: ……”说明：老版本pt-query-digest生产的checksum存数字，anemometer为了展示美观（固定长度）等原因，将checksum转成16进制列表展示，进详情页后，再讲16进制转换成10进制查找具体SQL详...

1.主从切换因为数据库迁移、升级、主库停机维护等原因，需要将从库升为主，主要步骤如下：1.主库锁库，禁止写入mysql> flush table with read lock;确认Executed_Gtid_Set不再变化，并记录mysql> show master status\G*************************** 1. row ******...

用过阿里高防的都知道，高防有个很牛X的防CC功能配置：基于域名，基于某URL（精确匹配或后模糊匹配），限制某个时间跨度的请求频率，超过该频率会拉黑n分钟，如：10秒内请求20次，达到这个阈值则拉黑IP5分钟。然而：高防不是所有公司都用得起的（月费用1万以上），高防配置的域名数量越来越苛刻（一级域名和二级域名数都有严格限制了），高防也有抽风的时候，有很多时候发现该功能没起效果，所以我们搞了个自己的防CC功能。改方案暂取名lbwaf，主要功能包括手动拉黑（就是手动填IP黑名单），自动拉黑（重点功

整体思路：从kafka集群读取请求日志流，经过spark structured streaming(结构化流)实时分析，将触发阈值的数据输出至mysql。1.数据源nginx日志通过syslog协议输出至logstash，然后同时写入es和kafka:nginx -> logstash -> elasticsearch and kafkalogstash配置：output { elasticsearch { …… } ## 尽可能在来源...

mysql慢查询，已经有现成的成熟的方案收集展示了：pt-query-digest结合box公司的anemometer，没用过的移步：《mysql慢查询可视化》（本章内容需要了解anemometer）。但DBA们一定还遇到过这样的问题：某个时间段CPU负载较高，但慢查却没有，有时连实时看processlist都看不出异常。这种情况一般是由高并发的但单个性能正常的SQL导致的，所以慢查没有，但总体负载会升高。那怎么办呢？选择1：配置events_statements_history_long，缺点明显

mysql实例多了，直接查slowlog文件即便用某些脚本自动处理文件，效率也是极其低下，发现Anemometer很好用。官方文档：https://github.com/box/Anemometer一般一台4C4G的虚拟机作为Anemometer足够了，假设IP：1.1.1.1安装apache# yum installgcc gcc++ zlib zlib-devel如果已

分库分表设计阶段的一个重要考虑的因素是分库分表的数量以及后期扩容问题。建议根据业务5-10年的发展，一次性固话表的数量，因为如果后期要改变表的数量，数据迁移难度较大（会涉及到记录级别的迁移）；如果我们规划支持1024张表，初期可以1个实例，32个库，每个库32张表；后期随着业务发展，可以将32个库切分到不同实例，甚至将每个库的表切到不同的实例，最多切1024个实例，对应1024个库，每个库一个表。扩容的一个原则是只能表级迁移，不能记录级迁移。一个普遍的规则是(假设分1024张表，初期32个库)

1.前言自从踏进互联网运维这个行当，就无时不刻不在为高可用费神。nginx、tomcat、缓存、队列、数据库，每个环节高可用的最基本要求是避免单点故障，能够自动failover。mysql的高可用方案说起来很多，但真正想在你家的生产环境大面积使用，发现这个有缺点、那个不完美。之前用过MHA一段时间，代码较复杂（可能因为我没搞过perl），作者不再更新，总担心误切、脑裂……，至于高大上的pxc\...