TiDB

刚修改密码后就忘记，囧囧囧囧囧。记录一下，以便以后犯了同样的错误可以快速找到解决方法。 测试阶段，还是使用的 TiUP cluster 在单机上模拟生产环境部署步骤 单机模拟生产环境 先停止tidb tiup cluster stop <cluster-name> 然后找到 tidb-server 的配置文件，一般默认是在 cd /tidb-deploy/tidb-4000/conf vi tidb.toml 添加如下security [security] skip-grant-table = true 然后找到 tidb-server 的启动文件，具体在 deploy 目录下的script/run_tidb.sh，一般是 /tidb-deploy/tidb-4000/scripts 由于 tidb 限制了 skip 模式只能在操作系统 root 用户启动 tidb-server 才可以进行，所以要用 root 用户来执行上面的脚本 sudo sh run_tidb.sh 此时再次登录 tidb，就会发现不需要输入 root 密码了. mysql -h 127.0.0.1 -P 4000 -u root 登录之后 SET PASSWORD FOR 'root'@'%' = 'xxx'; #或者 ALTER USER 'test'@'localhost' IDENTIFIED BY

作者介绍：朱志友，中通快递大数据架构师。 中通快递背景介绍 中通快递业务的规模目前是世界第一，是第一个达成年百亿业务量的快递企业，在 2019 年的双十一更是完成了订单量超过 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台，拥有一支千余人规模的研发团队，秉承着“互联网+物流”的理念，与公司的战略、业务紧密的衔接，为中通生态圈的业务打造全场景全链路的数字化平台服务。 上图展示了快递物流的生命周期，简单举个例子，大家如果在某宝上下了一个订单，从付款结束开始，到商家打单，大家的包裹基本上就开启了一个快递的旅程。简单的介绍可以分为五个字，收发到派签，整个物流的全链路中可以拆解成以下的关键节点，客户下单之后快递员的揽收，揽收网点的建包，建包之后会把快递交到中心，至此快递就开启了转运和运输的过程，最终负责派件的末端网点会根据三段码的解析去末端的中心把快递拉到末端的快递网点进行分拣，分拣之后会指派到指定的快递员，进行派件，快递小哥会把快递送到客户的手里，客户完成签收，在我们看来这一票件就完成了快递的全链路的生命周期。在每个环节中会产生大量的数据，对每个环节的每一个数据我们都会进行相关的分析，包括时效的监控。 2017 年的时候，我们就已经开始关注 TiDB ，那时候的关注点主要在解决一些分库分表的问题上，从 2018 年底开始调研测试大数据，我们主要想去解决存储和计算的问题，2019

本文收录在个人博客： www.chengxy-nds.top ，技术资料共享，同进步 最近部门订单业务调整，收拢其他业务线的下单入口，做个统一大订单平台。需要梳理各业务线的数据表，但每个业务线库都有近百张和订单相关的表，挨个表一个一个字段的弄脑瓜子嗡嗡的。 为了不重复 CV 操作，抱着一丝希望开始在 GitHub 里找，看看有没有什么工具可以用，结果就真的发现了宝藏， screw （螺丝钉），居然可以生成数据库文档，优秀啊~。 一、数据库支持 [x] MySQL [x] MariaDB [x] TIDB [x] Oracle [x] SqlServer [x] PostgreSQL [x] Cache DB 二、配置 1、pom文件 引入 screw 核心包， HikariCP 数据库连接池， HikariCP 号称性能最出色的数据库连接池。 <!-- screw核心 --> <dependency> <groupId>cn.smallbun.screw</groupId> <artifactId>screw-core</artifactId> <version>1.0.3</version> </dependency> <!-- HikariCP --> <dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP

题外话：看完评论感觉杠精真的是多，这篇文章明显是在说，不要写一大堆if-else，一大堆是啥意思不懂么，我没有一句话说了不要写if-else。开头也给出了需求，在这种需求的前提下不要写if-else，没毛病吧?？？真的觉得毁三观了。。 代码洁癖狂们！看到一个类中有几十个if-else是不是很抓狂？ 设计模式学了用不上吗？面试的时候问你，你只能回答最简单的单例模式，问你有没有用过反射之类的高级特性，回答也是否吗？ 这次就让设计模式(模板方法模式+工厂模式)和反射助你消灭if-else！ 真的是开发中超超超超超超有用的干货啊！ 那个坑货 某日，码农胖滚猪接到上级一个需求，这个需求牛逼了，一站式智能报表查询平台，支持mysql、pgxl、tidb、hive、presto、mongo等众多数据源，想要啥数据都能通通给你查出来展示，对于业务人员数据分析有重大意义！ 虽然各个数据源的参数校验、查询引擎和查询逻辑都不一样，但是胖滚猪对这些框架都很熟悉，这个难不倒她，她只花了一天时间就都写完了。 领导胖滚熊也对胖滚猪的效率表示了肯定。可是好景不长，第三天，领导闲着没事，准备做一下code review，可把胖滚熊惊呆了，一个类里面有近30个if-else代码，我滴个妈呀，这可让代码洁癖狂崩溃了。 // 检验入参合法性 Boolean check = false; if(DataSourceEnum

1. 前言 相信参与使用 Oracle 数据库进行项目开发、运维的同学常常被 Oracle JDBC 驱动的 Maven 依赖折磨。现在这一情况在今年二月份得到了改变，甲骨文这个老顽固终于开窍了。 一位甲骨文的工程师发布博客：在 Maven 中央仓库中，现在不单单最新版本的 Oracle JDBC 驱动程序，而且还可以找到以往所有的 Oracle JDBC 驱动发行版，包括 19.6.0.0 、 19.3.0.0 、 18.3.0.0 、 12.2.0.1 和 11.2.0.4 。 Maven 中央仓库正式成为 Oracle 官方的 JDBC 驱动程序和配套 jar 的分发中心。 2. Oracle 正在整合其中央仓库的组件 此外， Oracle 希望对 Maven 中央仓库中的所有 Oracle 数据库组件合并到 com.oracle.database 下进行统一的管理，按照特定的领域指定 groupId ，比如 JDBC 相关的组件为 com.oracle.database.jdbc 、 XML 相关的为 com.oracle.database.xml 。Oracle正在进行一些整合工作，胖哥已经在 Maven 中央仓库找到了这些组件。 这就意味着你不再需要自行安装，只需要引入（以 ojdbc10 为例）相关依赖就能集成 Oracle JDBC 驱动了： <dependency

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用： 这么牛X的名单，你不想了解下LSM Tree吗？装X之前，我们先来了解一些基本概念。 设计数据存储系统可能需要考虑的一些问题有：ACID，RUM（Read,Write,Memory）。 ACID ACID 相信小伙伴都被面试官问过，我想简单讨论的一点是：如何 持久化数据 才能保证数据写入的 事务性 和 读写性能？ 事务性可简单理解为：1.数据必须持久化。2.一次数据的写入返回给用户 写入成功就一定成功，失败就一定失败。 读写性能可简单理解为：一次读 或 一次写 需要的IO次数，因为访问速率：CPU>>内存>>SSD/磁盘。 对于单机存储，最简单的方式当然是：写一条就持久化一条，读一条就遍历一遍所有数据，然后返回。当然没人这么干，在内存中我们都还知道用个HashMap呢。 拿Mysql InnoDB举例子：读性能体现在数据的索引在磁盘上主要用B+树来保证。写性能体现在运用 WAL机制 来避免每次写都去更新B+树上的全量索引和数据内容，而是通过redo log记录下来每次写的增量内容，顺序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，然后在一定条件下触发脏页的刷盘。 redo

6 月 7 日，TiDB 社区年度技术大会 TiDB DevCon 2020 圆满落幕，本届大会采取线上直播的形式，汇聚了来自全球各地的 80+ 开发者、TiDB 用户及合作伙伴分享第一手开发及实践经验，议题覆盖金融、电信、电商、物流、视频、资讯、教育、医疗等诸多行业，干货满满，目不暇接。会上我们正式发布了具有里程碑意义的 TiDB 4.0 GA 版本，并分享了技术细节及生产环境的实战效果，并为过去年在 TiDB 社区作出卓越贡献的 Contributor、Committer、Maintainer 授予了荣誉奖杯与证书。 本届大会历时 2 天，共设置 7 个论坛， 29 小时 累计分享时长，直播间人气值高达 2.3 万 ，错过的小伙伴们可以继续“蹲守”本公众号近期推送，我们将陆续挑选整理部分精彩内容输出，敬请期待！ 以下是我司联合创始人兼 CEO 刘奇的现场分享实录。 每年我都有一个时间会特别激动，就是产品大版本发布的时候，通常也是社区年度技术大会 TiDB DevCon 举办的时间。去年 TiDB DevCon 2019 ，我们发布了 TiDB 3.0 Beta，当然今年 TiDB 4.0 GA 也如约而至。 Serverless 很长一段时间 TiDB 用户使用的集群规模都很大，然后就会再提出一个诉求说“怎么降低我的使用成本”。TiDB 4.0 拥有了 Serverless

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 自去年开始，中台话题的热度不减，很多公司都投入到中台的建设中，从战略制定、组织架构调整、协作方式变动到技术落地实践，每个环节都可能出现各种各样的问题。技术中台最坏的状况是技术能力太差，不能支撑业务的发展，其次是技术脱离业务，不能服务业务的发展。前者是能力问题，后者是意识问题。在本专题中，伴鱼技术团队分享了从 0 到 1 搭建技术中台的过程及心得。 背景 随着伴鱼业务的快速发展，公司各产品线的业务不断丰富，日常的 SQL 上线也在不断增加。 SQL 审核与执行，作为 DBA 每天工作中相当重要的一环，如何保证 SQL 语句的质量，对于系统的高效运行和长久稳定有着很大的影响。 本文在对开源 SQL 审核平台 (例如 Yearning、See 和 Archery 等) 进行调研，并结合 DBA 在 SQL 上线实践经验的基础上，设计了伴鱼 SQL 审核平台。相比其它 SQL 审核平台，新系统主要包括以下核心功能： 基于 TiDB Parse 做 SQL 语法解析，践行 SQL 规范 基于公司组织架构做权限管理和流程审核 基于审核规则列表的动态开关 支持 SQL 执行数据备份和回滚 支持任务定时调度执行 下面从整体架构、流程设计等方面详细介绍下伴鱼 SQL

这次能拿到TIDB MVA，要感谢的人太多，首先要感谢我的师傅卓汝林，潘友飞，张甦，靳国军，还要感谢我的领导，李彬，张良，徐国强，杨挺，王立新，还有好多帮助过我的大佬们，感谢tidb官方人员戚铮和高振娇对我的细心和耐心的帮助，感谢TUG，我会继续尽自己的一份力，让更多人接触，了解和使用TIDB~祝TUG越来越好，也祝自己越来越好 来源： oschina 链接： https://my.oschina.net/u/4275462/blog/4280944

数据库存储了公司的数据，是公司的最重要资产之一。正确性和稳定性是数据库最重要的特性。测试团队之于 TiDB 是一个“破坏之王”的角色，团队的使命是炼成更高、更快、更强的 “无敌风火轮” 技能。在这篇文章里，我们介绍 PingCAP 测试团队（QA Team）是怎么工作的。 我们在做什么？ 我们测试团队是 TiDB 的“破坏者”，用各种手段尽早发现系统的 bug 是我们的工作。TiDB 有丰富的产品线，在这些产品线中，我们面对着不同的挑战。 首先，TiDB 内核稳定是整个系统稳定的基础和重中之重。TiDB 新版本的内核仍然处于高速发展的阶段。因此，测试要尽早发现新特性的正确性和稳定性问题，包括但不限于： 对 TiFlash 列存引擎，测试要构造破坏一致性保证的情况； 在 3.0 中，TiDB 增加了悲观事务，并支持了 RC 隔离级别。在 4.0 中，TiDB 支持了大事务，优化了 GC 的性能。这些特性的重要性不言而喻，必须进行严苛的、长时间的性能测试和稳定性测试； 挑战不断优化的 SQL 优化器和执行引擎，确保功能增强后的系统正确性和性能。例如 Index Merge、SQL Hint 和 SQL Plan Management 等特性； 验证调度稳定性的特性，例如 4.0 中的新热点调度器，构建不同的接近真实场景的负载，找出在这些负载下的系统不稳定的情况； TiKV