ASKDBA

随着业务越来越复杂，数据量越来越大，并发量越来越大，数据库的性能越来越低。好不容易找运维申请了两台机器，让DBA部署了几个实例，想把一些业务库拆分出来，却发现拆不出来，扩不了容，尴尬！ 因为数据库强关联在一起，无法通过增加数据库实例扩容，就是一个耦合的典型案例。 场景还原 有一个公共用户数据库DB_USER，里面table_user存放了通用的用户数据： table_user (uid, name, passwd, …) 在数据量比较小，并发量比较小，业务还没有这么复杂的时候，为了提高资源利用率（程序员才没有考虑什么资源利用率，更多的是图方便），业务A把用户个性化的数据也放在这个库里： table_A(uid, A业务的个性化属性) 业务A有一个需求，即要展现用户公共属性，又要展现业务A个性化属性，程序员经常这么实现的： select * from table_user, table_A _      where table_user.uid = table_A.uid_ _      and table_user.uid = $uid_ 初期关联查询没有任何问题， ...

将5.7更新后的Transportable Tablespace 功能做一总结 一 普通表和分区表的传输 将db1的t1表传输到db2上 普通表创建 CREATE TABLE t1 (i int) ENGINE = InnoDB ;分区表创建 CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 4; db1上1.flush table t1 for export;2.将 t1 表的 .cfg 和 .idb 文件拷贝出来3.unlock tables; db2上1.创建相同的表结构 CREATE TABLE t1…2.alter table t1 discard tablespace ;3.将 db1 的.cfg 和 .idb 文件拷贝到db2并修改权限4.alter table t1 import  tablespace ; 二 分区表的若干分区传输 将db1的t1表的p2,p3分区传输到db2上 分区表创建 CREATE TABLE t1 (i int) ENGIN ...

本文就来详细讲述一下MySQL线程池相关的知识，以帮助广大DBA快速了解MySQL的线程池机制，快速配置MySQL的线程池以及里面存在的一些坑。 其实我想说，了解和使用MySQL线程池，看这篇文章就够了。 一、为何要使用MySQL线程池在介绍为什么要使用线程池之前，我们都知道随着DB访问量越来越大，DB的响应时间也会随之越来越大，如下图： 而DB的访问大到一定程度时，DB的吞吐量也会出现下降，并且会越来越差，如下图所示： 那么是否有什么方式，能实现随着DB的访问量越来越大，DB始终表现出最佳的性能呢？类似下图的表现： 答案就是今天要重点介绍的线程池功能。总结一下，使用线程池的理由有两个： 1、减少线程重复创建与销毁部分的开销，提高性能 线程池技术通过预先创建一定数量的线程，在监听到有新的请求时，线程池直接从现有的线程中分配一个线程来提供服务，服务结束后这个线程不会直接销毁，而是又去处理其他的请求。这样就避免了线程和内存对象频繁创建和销毁，减少了上下文切换，提高了资源利用率，从而在一定程度上提高了系统的性能和稳定性。 2、对系统起到保护作用 线程池技术限制了并发线程数，相当于限制了 ...

NAME       systemd.service - Service unit configuration SYNOPSIS       service.service DESCRIPTION       A unit configuration file whose name ends in .service encodes information about a process controlled and       supervised by systemd.        This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common       options of all unit configuration files. The common configuration items are configured in the generic “[Unit]“ and       “[Install]“ sectio ...

Redo日志配置相关的两个参数： innodb_log_file_size innodb_log_files_in_group 总的大小是两个参数的乘积。 大小设置可以参考几条PMM曲线： InnoDB Checkpoint Age          Uncheckpointed Bytes 如果很接近 Max Checkpoint Age，说明 innodb_log_file_size 设置小了。 Total Size of InnoDB Log Files     表示所有的 redo log 大小(所有成员总的大小),Data Written 表示每小时写入的日志，通过计算可以得到大约多久日志会循环一次。进而判断应该如何设置 innodb_log_file_size 。大约控制在一个小时左右切换一次。 InnoBD Buffer Pool Content          如果 Data Dirty 很高，可以考虑调整如下两个参数          innodb_io_capacity_max 和 innodb_io_capacity (50%*innodb_io_capa ...

如果开启了AHI（adaptive hash index，自适应哈希索引）就关闭AHI，这里因为AHI是通过buffer pool中的B+树页构造而来。 如果新设定的buffer pool size小于原来的size，就需要计算需要删除的chunk数目withdraw_target。 遍历buffer pool instances，锁住buffer pool，收集free list中的chunk page到withdraw，直到withdraw_target或者遍历完，然后释放buffer pool锁。 停止加载buffer pool。 如果free list中没有收集到足够的chunk，则重复遍历收集，每次重复间隔时间会指数增加1s、2s、4s、8s…，以等待事务释放资源。 锁住buffer pool，开始增减chunk。 如果改变比较大，超过2倍，会重置page hash，改变桶大小。 释放buffer_pool,page_hash锁。 改变比较大时候，重新设置buffer pool大小相关的内存结构。 开启AHI。

今天将数据库从5.6升级到5.7的过程中发现日志有如下关于分区表的warnings。 1234567eprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check. 2017-12-21T03:08:49.944449Z 0 [Note] Beginning of list of non-natively partitioned tables2017-12-21T03:08:49.947899Z 2 [Warning] The partition engine, used by table 'ddz_log.user_daily_data_change', is deprecated and will be removed in a future release. Please use native partitioning instead.2017-12-21T03:08:49.947 ...

今天lys问了一个问题， NO_ENGINE_SUBSTITUTION 是干啥的，这个还真没注意过以前。 研究了一下，原来这个是在创建表指定engine子句的时候，让mysql对此DDL做判断用的。看一个例子： 1234567891011121314151617181920212223242526272829303132mysql> show variables like '%sql_mode%'; +---------------+------------------------+| Variable_name | Value |+---------------+------------------------+| sql_mode | NO_ENGINE_SUBSTITUTION |+---------------+------------------------+1 row in set (0.01 sec)mysql> show engines;+--------------------+------- ...

说明 版本：percona 分支的mongodb3.4的二进制版本percona-server-mongodb-3.4.6-1.7-centos6-x86_64.tar.gz 目录规划：安装目录： /data/opt/数据文件目录: /data/mongo配置文件: /etc/mongod.conf 增加用户和组1groupadd mongodb  &&  useradd -g mongodb mongodb 解压1tar zxvf percona-server-mongodb-3.4.6-1.7-trusty-x86_64.tar.gz -C /data/opt/ 创建相关目录1mkdir -p /data/mongo/{db,log,tmp} 更改属性12chown -R mongodb:mongodb /data/opt/percona-server-mongodb-3.4.6-1.7/ chown -R mongodb:mongodb /data/mongo ...

MySQl出现这个问题基本有三种情况 1.网络原因 2.如果错误日志中存在”during query”，表明在发送大量的行数据。可将 net_read_timeout 增大到60或更大,以保证数据有足够的时间传输完成。 3.也有少许情况下，当客户端初始化连接的时候，如果 connect_timeout 设置的太小，而距离又太远或者查询太慢也会报错。可以通过 show global status  LIKE ‘Aborted_connects’ 来诊断。而当出现  ER_NET_PACKET_TOO_LARGE 说明需要增加 max_allowed_packet。