sdmei

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

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

之前处理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

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

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

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

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

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

1. 背景我司目前数据库之间的数据同步都是oracle goldengate(ogg)方案，该方案的特点：优点：基于数据库的变更日志同步（oracle redo\mysql binlog），速度很快，对数据库性能影响很小，适合大量数据同步的场景缺点：同步表变更字段、新增表，需要修改数据库服务器上的很多配置文件，比较繁琐，在exact、pump、replicate进程很多的情况下，易...

数据库跑一段时间后，因为查询性能、磁盘容量，运维管理等方面的原因，需要将在线数据挪到历史库(不同的服务器）。如我们的在线订单只留3个月数据，3个月以前的就需要到历史库查了。自动归档常见的方式有pt-archiver，但我还是觉得自己写存储过程更靠谱。。。思路：在线库实例打开federated支持，创建数据库dborder(业务库), linkhis(归档用); 历史库创建历史表dbo...

1.前言跨平台、异构数据库之间的数据同步，方案有限，Oracle OGG算比较靠谱的一个：优点：性能好，大数据量速度快，对线上库性能的影响忽略不计；缺点：安装配置、维护有点麻烦，尤其是后期有字段变更时；个人觉得适合部署在小范围、大数据量、对性能要求较高的同步需求。本案例以Oracle(10.10.10.1) -> mysql(10.10.10.2)说明其部署过程以及注意事项。原理说明：OGG...

Mysql的高可用方案五花八门，本人人为最可靠、稳定、实用的还是mha。mha方案涉及到5个节点：manager\secondary-check1\secondary-check2\db1\db2备注：a.secondary-check1\secondary-check2虽是可选的，但强烈建议使用，防止因为网络原因误切换；b.官方推荐数据库3节点，但我人为业务量不是超大的情况下2节

mha的博文中说到mha切换mysql时，如果主库无法正常ssh，为防止脑裂，需要通过控制卡关物理机，或者vmware api关闭虚拟机。这里总结下如何调用api关闭虚拟机。安装环境：centos6.91.下载python安装包Python-3.3.7.tgzpip-9.0.1.tar.gzsetuptools-36.5.0.zip2.安装python3yum install readline-d...

现象短信报警凌晨的备份任务失败；研发说应用挂了，应用都重启过了，貌似还没解决；其他cpu、磁盘空间、日志等指标都正常，没收到报警，疑惑；排查凌晨1点开始的备份不成功：>> log scanned up to (348743804470)xtrabackup: Creating suspend file '/data1/backup/2017-11-14_

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