分类目录归档:db

mysql reset slave / reset master

RESET SLAVE

官方的解释如下

1)RESET SLAVE makes the slave forget its replication position in the
master's binary log. This statement is meant to be used for a clean
start: It clears the master info and relay log info repositories,
deletes all the relay log files, and starts a new relay log file. It
also resets to 0 the replication delay specified with the MASTER_DELAY
option to CHANGE MASTER TO. To use RESET SLAVE, the slave replication
threads must be stopped (use STOP SLAVE if necessary).

2)RESET SLAVE does not change any replication connection parameters
such as master host, master port, master user, or master password, which
are retained in memory. This means that START SLAVE can be issued
without requiring a CHANGE MASTER TO statement following

reset slave

其实,它是直接删除master.info和relay-log.info文件,并删除所有的relay log,然后重新生成一个新的relay log,即使relay log中还有SQL没有被SQL线程apply完。

但是RESET SLAVE有个问题,它虽然删除了上述文件,但内存中的change master信息并没有删除,此时,可直接执行start
slave,但因为删除了master.info和relay-log.info,它会从头开始接受主的binlog并应用。(注意:这里所说的从头是说:reset的时候,正在接受的主的binlog,从新接受这个binlog).如果SQL
thread 正在复制临时表的过程中,执行了stop slave ,并且执行了reset slave,这些被复制的临时表将被删除。

reset master 做了什么?

1. reset master 将删除日志索引文件中记录的所有binlog文件,创建一个新的日志文件 起始值从000001 开始,

2. reset master 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master
命令不被支持,reset master 将master 的binlog从000001 开始记录,slave 记录的master log
则是reset master 时主库的最新的binlog,从库会报错无法找的指定的binlog文件。

继续阅读

发表在 db | mysql reset slave / reset master已关闭评论

Mysql Replicate Relay log read failure

一、描述

Mysql主从复制模式中,slave上报错 “relay log read failure”,导致主从同步停止。

mysql> show slave status\G
...
Master_Log_File: dd-bin.002542
Relay_Master_Log_File: dd-bin.002540
Exec_Master_Log_Pos: 950583017
Last_Error: Relay log read failure:...
...

二、分析

      报错信息为从库“无法读取relay log 里的条目”,可能原因为master库的binglog错误,或slave库的中继日志错误。或者为网络问题及bug原因。

      一般是由于网络故障或slave库压力过大,导致relay-log格式错误造成的。找到当前已经同步的时间点,重新设置主从同步,就会产生新的中继日志,恢复正常。

三、问题处理

从"show  slave  status\G"的输出中,找到如下信息:

Relay_Master_Log_File: dd-bin.002540     //slave库已读取的master的binlog

Exec_Master_Log_Pos: 950583017           //在slave上已经执行的position位置点



    停掉slave,以slave已经读取的binlog文件,和已经执行的position为起点,重新设置同步。会产生新的中继日志,问题解决。

(不需要指定host,user,password等,默认使用当前已经设置好的)

mysql>stop slave;

mysql>change master to master_log_file='dd-bin.002540' , master_log_pos=950583017;

mysql>start slave;



四、验证结果

再次查看,错误已经解决,slave 开始追 master 的日志

mysql>show  slave status\G

Exec_Master_Log_Pos: 225927489        //slave上已经执行的position已经变化

Seconds_Behind_Master: 58527            //slave  落后主库的时间,单位秒



过几秒钟,再次查看。离与master同步更近了

mysql>show  slave status\G

Exec_Master_Log_Pos: 307469867

Seconds_Behind_Master: 29570

继续阅读

发表在 db | 标签为 | Mysql Replicate Relay log read failure已关闭评论

db

RDS:

Oracle - Business
DB2    - Business
PostgreSQL    - Free
Microsoft SQL Server
MySQL - Free

Embed:

SQLite - Free
Microsoft Access - Free

Document:

MongoDb - Free
CouchDB - Free

Memory/Key Value:

Redis - Free
Memcache - Free
Cassandra - Free

Other:

HBase - Free
Infinite Graph - Free
InfoGrid - Free
Riak - Free

继续阅读

发表在 db | db已关闭评论

MySQL大数据场景的优化和运维之道

前言

MySQL数据库大家应该都很熟悉,而且随着前几年的阿里的去IOE,MySQL逐渐引起更多人的重视。

MySQL历史

  • 1979年,Monty Widenius写了最初的版本,96年发布1.0

  • 1995-2000年,MySQL AB成立,引入BDB

  • 2000年4月,集成MyISAM和replication

  • 2001年,Heikki Tuuri向MySQL建议集成InnoDB

  • 2003发布5.0,提供了视图、存储过程等功能

  • 2008年,MySQL AB被Sun收购,09年推出5.1

  • 2009年4月,Oracle收购Sun,2010年12月推出5.5

  • 2013年2月推出5.6 GA,5.7开发中

MySQL的优点

  • 使用简单

  • 开源免费

  • 扩展性“好”,在一定阶段扩展性好

  • 社区活跃

  • 性能可以满足互联网存储和性能需求,离不开硬件支持

上面这几个因素也是大多数公司选择考虑MySQL的原因。不过MySQL本身存在的问题和限制也很多,有些问题点也经常被其他数据库吐槽或鄙视

MySQL存在的问题

  • 优化器对复杂SQL支持不好

  • 对SQL标准支持不好

  • 大规模集群方案不成熟,主要指中间件

  • ID生成器,全局自增ID

  • 异步逻辑复制,数据安全性问题

  • Online DDL

  • HA方案不完善

  • 备份和恢复方案还是比较复杂,需要依赖外部组件

  • 展现给用户信息过少,排查问题困难

  • 众多分支,让人难以选择


到了刚才讲的MySQL的优势和劣势,可以看到MySQL面临的问题还是远大于它...

继续阅读

发表在 db | 标签为 | MySQL大数据场景的优化和运维之道已关闭评论

msmq,rabbitmq,activemq,zeromq

摘自网络

RabbitMQ是实现AMQP(高级消息队列协议)的消息中间件的一种,最初起源于金融系统。

一些概念:

channel:通道,amqp支持一个tcp连接上启用多个mq通信通道,每个通道都可以被作为通信流。

producer:生产者,是消息产生的源头。

exchange:交换机,可以理解为具有路由表的路由规则。

queues:队列,装载消息的缓存容器。

consumer:消费者,连接到队列并取走消息的客户端。

核心思想:在RabbitMQ中,生产者从不直接将消息发送给队列。

事实上,有些生产者甚至不知道消息是否被送到某个队列中去了。生产者只负责将消息送给交换机,而交换机确...

继续阅读

发表在 db | 标签为 , , , | msmq,rabbitmq,activemq,zeromq已关闭评论

MySQL数据库命名规范及约定

一、【操作规范】
1. 如无备注,则表中的第一个id字段一定是主键且为自动增长;
2. 如无备注,则数值类型的字段请使用UNSIGNED属性;
3. 如无备注,排序字段order_id在程序中默认使用降序排列;
4. 如无备注,所有字段都设置NOT NULL,并设置默认值;
5. 如无备注,所有的布尔值字段,如is_hot、is_deleted,都必须设置一个默认值,并设为0;
6. 所有的数字类型字段,都必须设置一个默认值,并设为0;
7. 针对varchar类型字段的程序处理,请验证用户输入,不要超出其预设的长度;
8. 建表时将数据字典中的字段中文名和属性备注写入数据表的备注...

继续阅读

发表在 db | 标签为 | MySQL数据库命名规范及约定已关闭评论

ibdata1 & mysql-bin

ibdata1和mysql-bin
问题:磁盘空间报警,经查发现ibdata1和mysql-bin日志占用空间太多(其中ibdata1超过120G,mysql-bin超过80G)
原因:ibdata1是存储格式,在INNODB类型数据状态下,ibdata1用来存储文件的数据和索引,而库名的文件夹里的那些表文件只是结构而已。
innodb存储引擎有两种表空间的管理方式,分别是:
1)共享表空间(可拆分为多个小的表空间文件),这个是我们目前多数数据库使用的方法;
2)独立表空间,每一个表有一个独立的表空间(磁盘文件)
对于两种管理方式,各有优劣,具体如下:
①共享表空间:
优点:可... 继续阅读

发表在 db | 标签为 , | ibdata1 & mysql-bin已关闭评论

MySql ibdata1文件

MySql innodb如果是共享表空间,ibdata1文件越来越大,达到了30多个G,对一些没用的表进行清空:
truncate table xxx;
然后optimize table xxx; 没有效果
因为对共享表空间不起作用。
mysql ibdata1存放数据,索引等,是MYSQL的最主要的数据。
如果不把数据分开存放的话,这个文件的大小很容易就上了G,甚至几十G。对于某些应用来说,并不是太合适。因此要把此文件缩小。
无法自动收缩,必须数据导出,删除ibdata1,然后数据导入,比较麻烦,因此需要改为每个表单独的文件。
解决方法:数据文件单独存放(共享表空间如何改为每个表独立的表空间文件)。
步骤如... 继续阅读

发表在 db | 标签为 | MySql ibdata1文件已关闭评论

oracle license

Oracle软件本身是免费的,所以任何人都可以从Oracle官方网站下载并安装Oracle的数据库软件,收费的是License,即软件授权,如果数据库用于商业用途,就需要购买相应Oracle产品的License。

现在Oracle有两种授权方式,按CPU(Process)数和按用户数(Named User Plus)。前一种方式一般用于用户数不确定或者用户数量很大的情况,典型的如互联网环境,而后一种则通常被用于用户数确定或者较少的情况。



按CPU: License数=CPU 数*系数。系数来自Oracle的一个参数表,如IBM Power6的处理器为1,AMD和Intel的处理器为0.5,详细情况...

继续阅读

发表在 db | 标签为 | oracle license已关闭评论

windows memcache

下载memcached-1.2.6-win32-bin
cmd进入memcached.exe的目录
安装命令:
安装 memcached.exe –d install
卸载 memcached -d uninstall
启动 memcached.exe –d start
停止 memcached.exe –d stop

netstat –an 默认端口11211
登陆 telnet localhost 11211
查看状态 stats

对查看的信息的关键字中英文对照表


pid

memcache服务器的进程ID

u...

继续阅读

发表在 db | 标签为 | windows memcache已关闭评论

postfix main.cf

一、设定邮件主机的识别身分(重要)

  myhostname 主机名称:如果系统设置得当,应该不用设置,系统会以gethostname()取得

  mydomain 网域名称:预设会以myhostname第一个点之后的作为domain名称

  myorigin 补齐缺少的资讯:自动补齐资讯所用的,通常使用网域名称

  mydestination 本地网域:指Postfix应该视为「本地网域」的所有网域名称

  (本地网域的部份会后续在设定)

  myhostname = host.domain.tld

  mydomain = domain.tld

  myorigin = $mydomain

  二、设定 P...

继续阅读

发表在 db | 标签为 | postfix main.cf已关闭评论

SQL Server死锁

其实所有的死锁最深层的原因就是一个:资源竞争

 

表现一:

  一个用户A 访问表A(锁住了表A),然后又访问表B,另一个用户B 访问表B(锁住了表B),然后企图访问表A,这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B,才能继续,好了他老人家就只好老老实实在这等了,同样用户B要等用户A释放表A才能继续这就死锁了。

  解决方法:

  这种死锁是由于你的程序的BUG产生的,除了调整你的程序的逻辑别无他法

  仔细分析你程序的逻辑:

  1:尽量避免同时锁定两个资源

  2: 必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源.

 

表现二:

  用户A读一条纪录,然...

继续阅读

发表在 db | 标签为 | SQL Server死锁已关闭评论

SQL Server 索引结构

作者:freedk 
一、深入浅出理解索引结构
  实际上,您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引:聚集索引(clustered index,也称聚类索引、簇集索引)和非聚集索引(nonclustered index,也称非聚类索引、非簇集索引)。下面,我们举例来说明一下聚集索引和非聚集索引的区别: 
  其实,我们的汉语字典的正文本身就是一个聚集索引。比如,我们要查“安”字,就会很自然地翻开字典的前几页,因为“安”的拼音是“an”,而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的,那么“安”字就自然地排在字典的前部。如果您翻...

继续阅读

发表在 db | 标签为 | SQL Server 索引结构已关闭评论

SQL Server死锁总结

 1. 死锁原理

    根据操作系统中的定义:死锁是指在一组进程中的各个进程均占有不会释放的资源,但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。

    死锁的四个必要条件:
互斥条件(Mutual exclusion):资源不能被共享,只能由一个进程使用。
请求与保持条件(Hold and wait):已经得到资源的进程可以再次申请新的资源。
非剥夺条件(No pre-emption):已经分配的资源不能从相应的进程中被强制地剥夺。
循环等待条件(Circular wait):系统...

继续阅读

发表在 db | 标签为 | SQL Server死锁总结已关闭评论

sqlserver 内部函数、存储过程、角色

/*日期函数*/
DATEADD ( datepart , number, date )
--在向指定日期加上一段时间的基础上,返回新的 datetime 值。
DATEDIFF ( datepart , startdate , enddate )
--返回跨两个指定日期的日期和时间边界数。
DATENAME ( datepart , date )
--返回代表指定日期的指定日期部分的字符串。
DATEPART ( datepart , date )
--返回代表指定日期的指定日期部分的整数。
DAY ( date )
--返回代表指定日期的天的日期部分的整数。
... 继续阅读

发表在 db | 标签为 | sqlserver 内部函数、存储过程、角色已关闭评论