您的位置:

mysql数据库复制延时分析(mysql 延时函数)

本文目录一览:

数据包延时问题?

谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作,主库对所有DDL和 DML产生binlog,binlog是顺序写,所以效率很高,slave的Slave_IO_Running线程到主库取日志,效率很比较高,下一步, 问题来了,slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的,不是顺 序的,成本高很多,还可能可slave上的其他查询产生lock争用,由于Slave_SQL_Running也是单线程的,所以一个DDL卡主了,需要 执行10分钟,那么所有之后的DDL会等待这个DDL执行完才会继续执行,这就导致了延时。有朋友会问:“主库上那个相同的DDL也需要执行10分,为什 么slave会延时?”,答案是master可以并发,Slave_SQL_Running线程却不可以。

2. MySQL数据库主从同步延迟是怎么产生的。

答:当主库的TPS并发较高时,产生的DDL数量超过slave一个sql线程所能承受的范围,那么延时就产生了,当然还有就是可能与slave的大型query语句产生了锁等待。

3. MySQL数据库主从同步延迟解决方案

答:最简单的减少slave同步延时的方案就是在架构上做优化,尽量让主库的DDL快速执行。还有就是主库是写,对数据安全性较高,比如 sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。

mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似,丁奇的是以表做多线程,Oracle使用的是以数据库(schema)为单位做多线程,不同的库可以使用不同的复制线程。

基于局域网的master/slave机制在通常情况下已经可以满足'实时'备份的要求了。如果延迟比较大,就先确认以下几个因素:

网络延迟

master负载

slave负载

一般的做法是,使用多台slave来分摊读请求,再从这些slave中取一台专用的服务器,只作为备份用,不进行其他任何操作,就能相对最大限度地达到'实时'的要求了

slave_net_timeout单位为秒 默认设置为 3600秒 参数含义:当slave从主数据库读取log数据失败后,等待多久重新建立连接并获取数据 master-connect-retry单位为秒 默认设置为 60秒 参数含义:当重新建立主从连接时,如果连接建立失败,间隔多久后重试。

通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟

MySQL数据库服务器逐渐变慢分析与解决方法分享

一、检查系统的状态

通过操作系统的一些工具检查系统的状态,比如CPU、内存、交换、磁盘的利用率,根据经验或与系统正常时的状态相比对,有时系统表面上看起来看空闲,这也可能不是一个正常的状态,因为cpu可能正等待IO的完成。除此之外,还应观注那些占用系统资源(cpu、内存)的进程。

1.使用sar来检查操作系统是否存在IO问题

#sar-u210—

即每隔2秒检察一次,共执行20次。

结果示例:

注:在redhat下,%system就是所谓的%wio。

Linux2.4.21-20.ELsmp

(YY075)05/19/2005

10:36:07AMCPU%user%nice%system%idle

10:36:09AMall0.000.000.1399.87

10:36:11AMall0.000.000.00100.00

10:36:13AMall0.250.000.2599.49

10:36:15AMall0.130.000.1399.75

10:36:17AMall0.000.000.00100.00

其中:

%usr指的是用户进程使用的cpu资源的百分比;

%sys指的是系统资源使用cpu资源的百分比;

%wio指的是等待io完成的百分比,这是值得观注的一项;

%idle即空闲的百分比。

如果wio列的值很大,如在35%以上,说明系统的IO存在瓶颈,CPU花费了很大的时间去等待I/O的完成。Idle很小说明系统CPU很忙。像以上的示例,可以看到wio平均值为11,说明I/O没什么特别的问题,而idle值为零,说明cpu已经满负荷运行了。

2.使用vmstat监控内存

cpu资源

[root@mysql1

~]#

vmstat

procs

———–memory———-—swap–

—–io—-–system–

—–cpu——

r

b

swpd

free

buff

cache

si

so

bi

bo

in

cs

us

sy

id

wa

st

72

25428

54712672264

14

43

53

59

1

198

vmstat

的输出那些信息值得关注?

io

bo:

磁盘写的数据量稍大,如果是大文件的写,10M以内基本不用担心,如果是小文件写2M以内基本正常

CPU问题

下面几列需要被察看,以确定cpu是否有问题

Processesinthe

run

queue

(procs

r)

Usertime

(cpu

us)

System

time

(cpu

sy)

Idle

time

(cpu

id)

问题情况:

如果processes

in

run

queue

(procs

r)的数量远大于系统中cpu的数量,将会使系统便慢。

如果这个数量是cpu的4倍的话,说明系统正面临cpu能力短缺,这将使系统运行速度大幅度降低

如果cpu的idle时间经常为0的话,或者系统占用时间(cpu

sy)是用户占用时间(cpu

us)两辈的话,系统面临缺少cpu资源

解决方案

:

解决这些情况,涉及到调整应用程序,使其能更有效的使用cpu,同时增加cpu的能力或数量

②内存问题

主要查看页导入的数值(swap中的si),如果该值比较大就要考虑内存,大概方法如下:

最简单的,加大RAM

减少RAM的需求

3.磁盘IO问题

处理方式:做raid10提高性能

4.网络问题

telnet一下MySQL对外开放的端口,如果不通的话,看看防火墙是否正确设置了。另外,看看MySQL是不是开启了skip-networking的选项,如果开启请关闭。

现在我在学习MySQL,问问怎么复制粘贴数据库

这得看你的数据表是什么存储引擎,

新建的数据表默认是InnoDB

数据表的存储引擎是可以更改的

随便进入一张表,选择操作,里面有存储引擎可以修改,你想复制表就可以将存储引擎修改成

myisam,

然后找到数据库的data目录复制好后,存储引擎再改成你需要的类型

phpmyadmin新建表时存储引擎

phpmyadmin修改存储引擎

如何解决mysql主从复制带来的数据延迟问题

从DB2转到MySQL,做过线上环境的配置,不过是先配置好,然后再把数据导入,前期测试好就行了,具体主主还是主备,还是主主备要看你们的需求了,网上都有配置过程。

怎样解决MySQL数据库主从复制延迟的问题

在老版本的MySQL 3.22中,MySQL的单表限大小为4GB,当时的MySQL的存储引擎还是ISAM存储引擎。但是,当出现MyISAM存储引擎之后,也就是从MySQL 3.23开始,MySQL单表最大限制就已经扩大到了64PB了(官方文档显示)。也就是说,从目前的技术环境来看,MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定,而是由所在主机的OS上面的文件系统来决定了。 而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的,一种是共享表空间存储方式,还有一种是独享表空间存储方式。 当使用共享表空间存

储方式的时候,Innodb的所有数据保存在一个单独的表空间里面,而这个表空间可以由很多个文件组成,一个表可以跨多个文件存在,所

以其大小限制不再是文件大小的限制,而是其自身的限制。从Innodb的官方文档中可以看到,其表空间的最大限制为64TB,也就是说,Innodb的单

表限制基本上也在64TB左右了,当然这个大小是包括这个表的所有索引等其他相关数据。

而当使用独享表空间来存放Innodb的表的时候,每个表的数据以一个单独的文件来存放,这个时候的单表限制,又变成文件系统的大小限制了。