weixin_42073629的博客

Apache Kudu 对频繁更新数据场景下的大数据实时分析最佳用例由于最近两次在大数据项目中使用Apache Kudu,写一篇文章谈谈对Kudu的一些看法和使用心得。一.对大规模数据实时分析的商业价值几乎所有的企业都有随着时间推移贬值的资产。直观地说，延长使用设备会降低设备的价值，如我们日常生活中的汽车、电子产品等。然而，数据通常不被视为随时间失去价值的资产，这种想法是错误的。虽然可能不是会计部门可以支付的费用，但是在可能导致更好的行动过程的时间段内，业务数据将失去价值。无论数据是否告诉您

概述：TiKV 最底层使用的是 RocksDB 做为持久化存储，所以 TiKV 的很多性能相关的参数都是与 RocksDB 相关的。TiKV 使用了两个 RocksDB 实例，默认 RocksDB 实例存储 KV 数据，Raft RocksDB 实例（简称 RaftDB）存储 Raft 数据。TiKV 使用了 RocksDB 的 Column Families 特性。默认 RocksDB 实例将 KV 数据存储在内部的 default、write 和 lock 3 个 CF 内。defaul

一些用户在做 DorisDB 的 POC 测试时，参照《DorisDB 企业版文档》进行了表模型选择、分区、分桶等基础配置后，查询性能离期望的理想状况可能还是会有些差异，或者想针对业务进一步优化以达到最佳性能。这里，我们就借用一个用户 POC 时的调优场景，来分享一些 DorisDB 系统性能调优中的技巧，同时也简要介绍下 DorisDB 企业版可视化 profiling 工具的使用。如果您使用的是 DorisDB 标准版，可以通过文字版的 profiling 信息，用文中提及的一些方法优化。下文将先介

背景介绍本文将介绍如何将 TiDB 中的数据，通过 TiCDC 导入到 Kafka 中，继而被 Flink 消费的案例。为了能够快速的验证整套流程的功能性，所有的组件都以单机的形式部署。如果需要在生产环境中部署，建议将每一个组件替换成高可用的集群部署方案。其中，我们单独创建了一套 Zookeeper 单节点环境，Flink、Kafka、等组件共用这个 Zookeeper 环境。针对于所有需要 JRE 的组件，如 Flink，Kafka，Zookeeper，考虑到升级 JRE 可能会影响到其他

背景介绍本文将介绍如何将 MySQL 中的数据，通过 Binlog + Canal 的形式导入到 Kafka 中，继而被 Flink 消费的案例。为了能够快速的验证整套流程的功能性，所有的组件都以单机的形式部署。如果手上的物理资源不足，可以将本文中的所有组件搭建在一台 4G 1U 的虚拟机环境中。如果需要在生产环境中部署，建议将每一个组件替换成高可用的集群部署方案。其中，我们单独创建了一套 Zookeeper 单节点环境，Flink、Kafka、Canal 等组件共用这个 Zookeeper

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)，本文接下来会详细介绍这三种日志。binlogbinlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储...

MySQL管理密码忘记后可以通过以下方式重置：1、在/etc/my.cnf配置中增加以下内容：[mysqld]skip-grant-tables2、重启MySQL服务后登录MySQL就可以不输入密码了，然后执行SQL重置密码mysql > update mysql.user set authentication_string=password('NEWPASSWORD') where user='root';mysql > flush privileges;3、取消.

脚本作用：实时拉取指定数据库实例上的binlog日志到本地进行存储应用场景：数据增量备份、MHA binlog server#!/bin/shBACKUP_BIN=/usr/local/mysql/bin/mysqlbinlogLOCAL_BACKUP_DIR=/data/mysql_binlog_backup/public/binlogBACKUP_LOG=/data/mysql_binlog_backup/public/backuplogREMOTE_HOST=10.3.0.221

一、Atlas介绍Atlas是由360基于官方mysql-proxy所优化改进的数据库中间件，除了atlas外，国内阿里巴巴还开源了一款数据库中间件Mycat，而且功能更为强大，只是配置相对复杂，后续会有相关文章对Mycat进行讲解。这里先对atlas进行介绍，相比官方的MySQL-Proxy，atlas效率要高出很多倍，而且配置也简单。Atlas运行在所有数据库节点的前面，用户通过Atlas来对数据库进行请求（有点像Nginx反向代理），能很好的实现MySQL读写分离、从库负载均衡、IP过滤等功能。在

一、binlog2sql的作用binlog2sql可以从MySQL的binlog中解析出需要的SQL，并且可以生成原始执行SQL、回滚SQL、去除主键的INSERTSQL等，使用这个工具就不用再人工去对binlog进行解析，闪回方便。但是需要注意的是仅能针对DML进行操作，因为DDL语句并不会在binlog中记录每行数据的变化。除了binlog2sql可以实现闪回外，美团也有开源一款myflush工具实现DML语句的回滚，有兴趣的可以自行了解。二、安装binlog2sql#安装pip工具，等.

一、Mycat介绍Mycat是一款基于阿里的cobar二次开发的数据库中间件（cobar已经停止维护），同类产品还有360的Atlas、淘宝的TDDL、MySQL官方的mysql-router等。由于Mycat基本覆盖了所有竞品的特点，不依赖代码就可以实现数据库分布式、读写分离、水平拆分（分库分表）、基于心跳实现高可用一体，现在已经是最有优势的一个MySQL中间件。但中间件不适合处理复杂的业务逻辑，所以使用场景不一定很高。二、分库分表介绍当单表数据量达到千万级别之后，即使添加从库、优化索引，对于

一、gh-ost介绍作为MySQLDBA都会面临这样一个问题，就是当对大表（10G以上）进行DDL变更时会有长时间锁表问题，影响业务可持续性。目前解决这个问题的方案一个较为通用的使用Percona公司开源的pt-osc工具，还有一个就是github基于go语言开发的gh-ost。gh-ost和pt-osc类似都能对大表进行在线DDL，在表格存在高并发写的情况下由于gh-ost是模拟从库应用binlog，所以性能不如pt-osc并发操作，但是gh-ost更灵活，不依赖触发器，并能根据实际情况动态调整。.

1、使用iotop命令打印出所有产生IO的线程2、通过performance_schema查找占用IO资源最高的线程SELECT `name`,`type`,thread_os_id,processlist_id FROM performance_schema.`threads` WHERE thread_os_id=2101423、查找对应processlist_id，可以确定出正在运行的SQLmysql > show processlist...

1、使用top -H命令打印出所有线程ID2、通过performance_schema查找使用CPU高的线程SELECT `name`,`type`,thread_os_id,processlist_id FROM performance_schema.`threads` WHERE thread_os_id=1026263、查找对应processlist_id，可以确定出正在运行的SQLmysql > show processlist...

一、binlog内容简单解析在部署MySQL主从的时候已经知道MySQL的binlog文件记录了数据的每次变动，详细到了哪个主机在哪个时间点执行了哪些语句，有了这些语句就可以对数据进行还原。由于binlog是二进制文件，所以无法使用VI等编辑器直接打开，如果需要查看日志内容需要使用mysqlbinlog工具或者MySQL客户端show binlog events命令。经过解析后的日志格式与内容如下：二、mysqlbinlog工具介绍1、mysqlbinlog命令常用选项-d | --d.

基于从库的Xtrabackup全量备份+binlog文件实现数据恢复，由于增量数据是基于binlog进行恢复，所以为了保证备份数据完全，数据库双1参数一定要配置。恢复数据时建议先使用临时的数据库实例进行还原验证，没有问题后再进行生产还原。一、还原全量数据1、解压经过LZ4压缩的xtrabackup全量备份（如未压缩可跳过）lz4_decompress /data/mysql_backup/xmglb/mysqlfull_2021-04-06_3308.xbstream /data/restor

一、作用域相关配置[mysql]：mysql客户端作用域，该作用域下的配置仅对mysql这个命令客户端生效 [mysqldump]：mysqldump客户端作用域 [mysqladmin]：mysqladmin客户端作用域 [client]：其他客户端的作用域。该作用域下的配置对mysqladmin、myqsldump等客户端命令都生效。由于不是所有客户端都有相同的配置，可能会因为多余的配置导致启动报错 [mysqld]：服务端选项作用域，大部分配置都在该作用域下 [mysqld-5.7]：对

如果仅需要表中的数据而不需要连表结构一起导出的话，推荐使用MySQL自带的into outfile和load data命令来进行表数据的导出和导入。这种导出方式更为高效，但是在进行表数据导出时不包含表结构，所以需要先备份表结构，然后恢复表结构后再进行表数据的导入。一、into outfile导出表数据1、导出MySQL表数据示例mysql > select * from db1.t1 where a>900 into outfile '/tmp/t1.csv';mysql &gt

通过LVM快照可以快速的备份数据，相比传统的复制粘贴数据到其他分区来讲，快照的优势除了速度快之外还可以不受磁盘数据动态变化的影响，它直接保存一个分区当时状态的元数据。但是有一个要求就是MySQL数据所在分区需要是逻辑卷分区，否则需要先将数据迁移到逻辑卷分区上再进行备份操作，下面是一个完整的迁移数据与备份流程：一、准备好磁盘并创建LVM快照：1、首先创建好逻辑卷，可参考本站文章《Linux逻辑卷工具lvm的使用教程》vgcreate mysql_vg /dev/sdblvcreate -L 2

mydumper是一款基于mysqldump进行过优化的逻辑备份工具，它能多线程并发备份和还原，效率比mysqldump更高。在同一服务器进行80G数据的备份还原测试，使用mydumper进行备份时间为5分钟左右，恢复时间为80分钟，相比mysqldump的备份还原，提升了2倍以上的性能。1、安装mydumperyum install https://github.com/maxbube/mydumper/releases/download/v0.10.1/mydumper-0.10.1-2.el

一、Xtrabackup作用Xtrabackup是Percona发布的一款物理备份工具，通常将直接复制数据文件作为备份手段的方式称为物理备份。相比逻辑备份而言速度更快、服务器负载也更低，并且备份期间不会锁表（MyISAM引擎依然存在FTWRL），备份期间不用间断业务，如果备份期间数据发生变化也会通过redolog保持数据一致，并且支持增量备份。只不过在进行单表备份和恢复时非常麻烦，这种场景建议用逻辑备份。二、Xtrabackup安装1、Percona官网推荐使用Yum方式安装，只需要配置好仓库地

一、什么是逻辑备份逻辑备份是将数据的每次变化记录在了备份文件中，查看备份文件可以看出备份的过程其实是把SQL语句给导出来了，然后再导入备份文件到数据库中进行还原。逻辑备份的优点是可跨平台迁移，但是效率较低，通常适合对一些数据量不大的业务进行备份，当数据量达到上百G就不再推荐使用逻辑备份。MySQL官方提供了2个逻辑备份工具，分别是mysqldump和mysqlpump，两者命令格式基本一致，区别在于mysqldump是单线程备份，mysqlpump是多线程备份（5.7开始支持）。这2个工具均不支持增

一、MySQL主从常见故障——主库日志丢失这种情况常发生于主库错误执行了reset master命令或者有reset master的需求，这样会导致binlog日志全部清空，从库会因为读取日志失败产生错误。要解决这个问题，通常就是找一个业务空闲期停服，然后从库进行reset操作重新做主从配置#主库操作mysql > reset master #清空binlog#从库操作mysql > stop slave #需等待从库把当前日志内容都读取完再做该操作mysql > r

当单节点MySQL或者主从架构下读压力较大的场景中，可能需要将复制拓扑扩展为一主多从的架构来缓解单个从库的读访问压力。甚至为了提高复制性能，除了单纯的对从库进行扩展以外，还可以增加一个中间库，将架构变为主-主-从*N的级联复制。一、单节点MySQL扩展为主从架构步骤1、主服务器需要保证binlog开启，具体配置可参考《MySQL主从复制（1）基于binlog的传统主从复制》文章中binlog相关设置部分。2、通过mysqldump或者xtrabackup导出主库当前数据mysqldump

一、什么是MGR集群MGR全称MySQL Group Replication，它是MySQL官方提供的一种高可用、高扩展性的分布式集群服务，可以实现数据的多点写入，适用于需要动态增加或收缩节点的大型业务系统以及对主从延迟要求十分敏感的场景。MGR竞品就是Percona的PXC了。二、MGR主要特点1、基于插件形式存在于MySQL服务中，不像PXC是打包了一个数据库2、有高容错性，只要故障节点数没有大于50%都是可以正常工作，计算公式：最大可故障主机=(节点数-1)/23、可自动增加和移除

一、MHA介绍1、MHA的作用MHA是实现MySQL高可用的一种成熟解决方案，可以在主从故障时自动完成主从切换，切换速度在30-60秒，并且可以最大程度的去保持数据一致性。MHA由管理节点（Manager）和数据节点（Node）组成，一套MHA Manager可以管理多套MySQL集群。当Manager发现MySQL Master出现故障时自动将一个拥有最新数据的Slave提升为Master，并让另外的Slave重新指向到新的Master上来。除此之外MHA还可以在线进行主从切换，大概2秒内就可以完

在MySQL 5.6以前不支持GTID机制，所以都是使用传统的binlog模式进行主从同步。在5.6以后引入的GTID机制可以对数据库的维护工作带来不少便利，大多数用户最终都会选择切换到GTID复制模式。在进行主从复制模式的切换之前复习下GTID的相关设置：· MySQL 5.7.6之前gtid_mode是只读参数，无法在线配置，需要重启服务·MySQL事务分为匿名事务（anonymous）和GTID事务。匿名事务不带有GTID信息，在主从复制中必须指定binlog文件和位置点· MySQL 5.

在非故障情况下需要手动进行主从切换的场景有很多，比如数据库版本升级时需要先升级从库，然后再切换角色升级其他节点；比如操作系统级别的异常需要重启服务器。而根据主从架构不同，手动切换的步骤也会有一些区别。一、一主一从架构1、从库开启binlog日志，因为主从切换后从库就称为了主库，此时要写入数据到binlog中2、将原主库修改为只读模式或者加FTWRL锁，防止新数据继续写入mysql > set global read_only =1;mysql > flush tables w

一、延迟从库的作用MySQL从5.6开始支持延迟复制，通过人为配置延迟复制的目的：· 用户在主库上误操作，通过延迟从库中的数据来恢复被误删除的数据 · 经常要求查询时间比较久远的数据进行比对，不需要重新加载备份数据。比如要查看一周前的数据，就配置一个从库延迟一周二、延迟从库配置在需要配置为延迟从库的客户端上执行以下命令mysql > stop slave sql_thread; #配置前需要停止SQL线程mysql > change master to master_d.

一、什么是双主复制在传统主从复制的架构中，如果主库出现故障，从库便无法再写入数据。主库故障后手动进行主从切换的过程较为繁琐。为了解决这个问题可以使用双主模式，其中一台主库提供线上服务，另一台作为备机，两台数据库使用VIP提供服务，依靠Keepalived进行故障自动切换。但是强烈不建议用双主模式来实现双写，这样数据不一致的风险非常大。如果真要开启，建议指定不同的库写入指定的节点。比如DB1的写入都在MasterA完成、DB2的写入都在Master2完成。除了双写问题以外，还有一个binlog循环复制的问

一、多源复制介绍当业务数据被打散到多个数据库实例后，如果需要实现一个从库同时同步多个主库的数据就需要使用多源复制这样的主从架构。在多源复制架构中，从库通过多个不同的复制通道（channel）来接受不同主库的数据，然后将这些数据存放在以通道命名的relaylog中。在MySQL 5.7中一个从库最多可以配置256个复制通道，这些通道名称不能重复（多源复制中每个数据库名也不可重复）。从库数据量控制在1T以内，除非有很好的存储设备，如PCIE-SSD。每个通道可以独立配置和运行，对于数据库的日志等相关配置，每

一、什么是GTIDMySQL 5.6开始支持GTID特性，即全局事务标识。GTID是全局唯一且具有幂等性的，每当有事务导致数据变化，GTID末位的数字就会自增，也就是说每个事务都有一个全局唯一的编号。从5.7版本开始即便不配置GTID也会存在匿名事务，只不过这个匿名事务不包含GTID信息，不能用于复制。在MySQL中每个DDL都会有一个GTID，而DML则是从begin开始到commit才算一个GTID。GTID由UUID+GTID共同组成，UUID即MySQL variables中的Server_

一、MySQL过滤复制介绍当主库上存在多个database，但从库只需要同步一部分的话就需要用到MySQL的复制过滤功能。比如一个主库承载多个业务数据库，需要将不同业务数据库复制到不同的从库进行查询的场景。通过过滤复制可以灵活的指定哪些库和表需要复制，哪些库不需要同步。通常建议在从服务器上配置过滤复制，可以减轻主库的负载。二、MySQL过滤复制配置介绍1、主库静态配置复制过滤· binlog_do_db：白名单，只对指定数据库进行binlog记录与复制，多个数据库设置可以写多行 ·bin.

一、异步复制与半同步复制的区别MySQL主从复制默认是采用异步机制进行同步，所谓异步即指主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收到binlog并同步。如果从库还没有接收到binlog的时候主库发生宕机，那么进行主从切换后的从库数据并不能和主库完全一致。为了解决这个问题，从MySQL 5.5开始以插件的形式支持半同步复制（另需要注意由于半同步复制仅与默认复制通道（for channel ""）兼容，不支持与多源复制混用。）。半同步复制中，当一个客户端提交事务时主库执

一、MySQL主从复制介绍主从复制是MySQL自带的一种横向扩展方案，通过“数据变更在主库执行，查询请求在从库执行”这样的形式可以在一定程度上实现读写分离。如果配置了无损复制，从库一定程度上还可以当做备份使用，甚至配置一台节点为延迟从库。有了主从复制后，还可以实现服务滚动升级（先升级从库进行测试，然后手动切换主从后升级其他从库）。主从结构通常可以分为一主一从、一主多从、级联复制等，如果是一主多从的架构需要注意从服务器的数量不能太多，否则会因为日志的传输给主库带来过多的带宽消耗（曾遇到主库网卡异常导致从库

本文介绍MySQL与Redis缓存的同步的两种方案 方案1：通过MySQL自动同步刷新Redis，MySQL触发器+UDF函数实现 方案2：解析MySQL的binlog实现，将数据库中的数据同步到Redis 一、方案1（UDF） 场景分析：当我们对MySQL数据库进行数据操作时，同时将相应的数据同步到Redis中，同步到Redis之后，查询的操作就从Redis中查找 过程大致如下： 在MySQL中对要操作的数据设置触发器Trigger，监听...

1.简介和安装sysbench是一个很不错的数据库性能测试工具。官方站点：https://github.com/akopytov/sysbench/rpm包下载：https://packagecloud.io/akopytov/sysbench/packages/el/7/sysbench-1.0.15-1.el7.centos.x86_64.rpm源码包下载：https://github.com/akopytov/sysbench/archive/1.0.15.tar

本文介绍MySQL与Redis缓存的同步的两种方案 方案1：通过MySQL自动同步刷新Redis，MySQL触发器+UDF函数实现 方案2：解析MySQL的binlog实现，将数据库中的数据同步到Redis 一、方案1（UDF） 场景分析：当我们对MySQL数据库进行数据操作时，同时将相应的数据同步到Redis中，同步到Redis之后，查询的操作就从Redis中查找 过程大致如下： 在MySQL中对要操作的数据设置触发器Trigger，监听...

MySQL架构为master/slave，当master故障时，vip漂移到slave上。提供服务。当然也可以设置为双master，但是不是每个方案都是完美的。这里设置为双master有个问题需要注意，比如，当用户发表文章时，由于此时主机的压力很大时，假设落后2000秒，那么这台主机宕机了，另一台主机接管（vip漂移到从机上）时，因为同步延时大，用户刚才发表的文章还没复制过来，于是用户又发表了一遍文章，当原来的master修复好后，由于I/O和SQL线程还处于开启状态，因此还会继续同步刚才没有同步复制完的数

本文主要介绍的是MHA+ProxySQL读写分离以及高可用，ProxySQL的细节请参考文档，目前已经有人写的非常详细了，文章最后会给出链接。当然和Group Replication，PXC搭配那是更完美的。MHA和ProxySQL搭配使用的架构图：测试环境（1主2从）：M-> 192.168.0.20S1-> 192.168.0.30S2-> 192.168.0.40proxysql -> 192.168.0.101. 检查主从复制是否正常：..