CtripMySQLDBA
- 浏览: 56409 次
- 来自: 上海
-
最新评论
-
王恒-Henry：
帅哥，有时间聊一下数据库技术吗，有时间加我QQ:5064377 ...
MySQL数据自动清理系统 -
CtripMySQLDBA：
martyl 写道freetds的转换没看懂，是什么转换到了什 ...
Linux系统通过python访问SQL SERVER，无法显示数据库内中文的问题 -
martyl：
freetds的转换没看懂，是什么转换到了什么，这种转换是否有 ...
Linux系统通过python访问SQL SERVER，无法显示数据库内中文的问题 -
carlfeng：
楼主IP故障转移，是通过什么方式实现的 ？ 是这个mas ...
MySQL高可用方案：基于MHA实现的自动故障转移群集 -
CtripMySQLDBA：
jinnchang 写道楼主能提供下具体的详细方案吗？可以以一 ...
MySQL高可用方案：基于MHA实现的自动故障转移群集
文章列表
MySQL版本：5.6.12-log
Ø 场景一
Session1:
Session2:
Session3:
至此，我们会产生疑问，MySQL5.6说好的online DDL呢，怎么又会出现Waiting for table metadata lock？
在一台服务器中以各数据库的备份文件为数据文件启动多个MySQL实例供SQL Review使用。之前运行一直没有问题（最多的时候有23个MySQL实例同时运行），后来新配置了一台服务器，启动其对应的实例时失败。部分错误日志如下：
……
140505 16:05:59 InnoDB: Using Linux native AIO
140505 16:05:59 InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.
InnoDB: Warning: io_setup() ...
MySQL数据自动清理系统
一、 目标
1. 以时间字段为条件，自动清理一定时间之前的数据
2. 支持每次小批量分批清理
3. 支持自定义执行清理的时间窗
4. 支持简单的主从表的关系数据删除
二、清理数据方法
1 ...
由于一些数据库重构项目的需求，最近遇到很多从SQL Server将表和数据迁移到MySQL的需求。这个需求说简单也简单，说麻烦也麻烦。前不久为了把一张大日志表成功导入到mysql，也折腾了不少时间。现在简单整理下实施方案。
首先是表结构的问题：
SQL Server中的部分字段类型不能直接沿用到MySQL，需要进行转换，主要有以下几种：
然后是数据迁移的问题：
数据迁移时，我们采取的是从SQL Server将数据导出为文本文件，然后将文本文件load到MySQL的方式（也尝试过通过etl工具直接迁移，例如SQL Server Integration S ...
MySQL版本为5.6.12。
在进行alter table操作时，有时会出现Waiting for table metadata lock的等待场景。而且，一旦alter table TableA的操作停滞在Waiting for table metadata lock的状态，后续对TableA的任何操作（包括读）都无法进行，也会在Opening tables的阶段进入Waiting for table metadata lock的队列。如果是产品环境的核心表出现了这样的锁等待队列，就会造成灾难性的后果。
造成alter table产生Waiting for table metadat ...
Infobright是开源的MySQL数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算(类似sum/avg/group by之类)。TokuDB是一个高性能、支持事务处理的MySQL和MariaDB的存储引擎，其主要特点是对高写压力的支持。我们针对以上两种特殊引擎，和InnoDB作了个简单的对比测试。
压缩性能
InnoDB、Infobright、ToKuDB占用存储空间
同等数据表history（zabbix后台数据表）占用空间情况如下：
从各引擎存储数据的大小看，Infobright引擎可以让数据获得更大限度的压缩，占用空间最少。
在MySQL发布第一个5.6的GA版本时，我们对5.5.28 VS 5.6.10 做了个简单的sysbench性能对比测试（见之前的博客），测试是基于我们自己的标准配置（innodb_flush_log_at_trx_commit=1 & sync_binlog=1）。从测试结果来看，5.6的性能提升非常明显， ...
我们基于Django框架实现了MySQL数据库管理的web系统，为了能直接使用域用户登录，需要在Django中集成LDAP认证。一开始由于对Django和LDAP都不熟悉，也折腾了很长时间。
首先需要安装以下模块：
django-1.4.3
openldap-2.4.33
python-ldap-2.4.10 （需要有cyrus-sasl-devel.x86_64）
django-auth-ldap-1.1.2
最近遇到几个需求，需要从centos上通过python访问sql server服务器查询数据，本来倒也不是很复杂，通过pyodbc比较顺利地实现了，具体如下：
先直接通过yum安装unixODBC、unixODBC-devel和freetds （pyodbc需要）
然后源码编译安装pyodbc
...
在MySQL 推出第一个5.6的GA版本后，我们对5.6进行了简单的性能对比测试。测试的基本思路是在同一台服务器上（保证硬件环境完全一样），先后安装MySQL 5.6和5.5，使用sysbench工具进行同样的压力测试，对比结果。
第一次对比测试
服务器配置：8核CPU+16G内存的HP360服务器
测试压力：sysbench的oltp的性能测试，测试表数据量5000万
Read_only结果：
Read_write结果：
这里出现了一个比较奇怪的现象，MySQL5.6的read only测试的结果反而要比MySQL5.5差了10%左右。Percona公司的
从SQL SERVER转型到MySQL的过程中，我发现对SQL SERVER的DBA来说，使用MySQL时有些容易忽略的问题。先整理了几个：
一、用户名是大小写敏感的（我们开启了lower_case_table_names来解决表名和库名大小写的问题，但是貌似没找到参数可以配置用户名的大小写问题），比如说创建的用户名是appuser，用AppUser登录就会失败，这点在我们配置连接串的时候出现过问题，而且一时难以发现。
二、关于自增长列：
1、 自增长列可能不是唯一的。MySQL在创建表时，要求auto_crement的字段必须是key,但并不要求是唯一索引，因此如果只将自 ...
常用MySQL不同高可用方案的对比（下图来自官方手册）
能实现自动数据库故障转移的方案只有MySQL Cluster和 DRBD+Heartbeat，这也是两种不依赖Replication的HA方案。
但是，MySQL Cluster（NDB）配置维护复杂，不像Replication一样稳定易用，大部分公司可能不会考虑这一方案；而DRBD的额外性能消耗又比较大，约为20%—30%，在可用性上大打折扣。
因此，对于我们来说，在Replication的基础上设计HA方案是最好的选择。
MySQL支持单向、异步的复制，复制过程中一个服务器充当主服务器，而一个或多个其 ...
基于MySQL服务器安全性需求，我们需要部署一套安全审计机制，以便当服务器出现用户活跃访问数据库、用户修改表结构、大批量数据修改等等危险操作时，我们可以进行实时的监控，报警。对于事后问题处理，有据可查。
在MySQL5.5之前，MySQL本身缺少一套的对服务器操作的审计机制，对于非法或者危险的操作、错误捕捉、登录审计尚不能很好的支持。当出现drop了一个表或者不慎不带where的删除表数据等危险操作时，应该被明确的记录下来。
在MySQL5.5里，添加了额外的流程来对这些我们所关心的地方进行事件捕获；然后将捕获到的事件传递给Audit Plugin；而Audit Plugin所要做的，就 ...
MongoDB支持在多个机器中通过异步复制达到故障转移和实现冗余。多机器中同一时刻只有一台是用于写操作。MongoDB的复制机制分为两种：1 Master-Slave 主从复制：MongoDB的最新版本已不再推荐此方案。2 Replica Sets复制集：增加了故障自动切换和自动修复成员节点，各个DB之间数据完全一致，大大降低了维护成功。
从节约资源的角度出发，我们一般都只用两台机器来部署MongoDB的复制集，在备节点所在服务器上再运行一个仲裁节点，然后将主节点的优先级调高，以保证仲裁节点总和备节点在一起。
基本上所有mongodb的连接驱动都支持连接复制集的方式，且方法大同小异，以 ...