2.快速导出数据库数据字典: SQL Server 数据库,生成数据字典 use YourDatabase --指定要生成数据字典的数据库 go SELECT 表名= then d.name else '' end, 表说明= then isnull(f.value,'') else '' end, 字段序号=a.colorder, 字段名=a.name, 标识= then '√'else '' end, 主键= FROM sysobjects where xtype='PK' and name

写在前面 估计二狗子这几天是大姨夫来了,心情很郁闷,情绪也很低落,工作的时候也有点心不在焉.让他发个版本,结果,一行命令下去把线上的数据库删了!你没听错:是删掉了线上的数据库!运营那边顿时炸了锅:怎么回事?系统不能访问了!什么情况啊?!很多客户都在投诉了!! 尽管运营那边慌慌张张的不知所措,但是,我们作为技术人员还是要淡定,不就是删了数据库吗?没事,哥帮你搞定! 如果文章对你有点帮助,请微信搜索并关注 冰河技术 微信公众号,点赞.在看.留言和转发,你的支持是我持续创作的最大动力!! 事件背景 M

tbl_user_data占用了大量磁盘空间,数据表占用大概200G,索引30G左右,查询非常慢,影响业务的支持进行现在需要对它进行清理 临时解决方案是将原表重命名,新建一个和这个表相同的空表来替换(缺点是不能做到根治,隔一段时间以后需要重新处理) 根除的办法是重新设计,或者在客户端进行过滤避免过多垃圾数据进入系统 1.新建一个和现在表相同结构的表create table tbl_user_data_new like tbl_user_data 将主键的ID改为bigint并且unsigned无

前文提要 承接前文<一次线上Mysql数据库崩溃事故的记录>,在文章中讲到了一次线上数据库崩溃的事件记录,建议两篇文章结合在一起看,不至于摸不着头脑. 由于时间原因,其中只讲了当时的一些经过以及我当时的一些心理活动,至于原因和后续处理步骤并没有在文章中很清晰的写出来,以致于很多朋友说看得不清不楚的,这里向他们道个歉,主要是上周真的没有足够的时间将两篇文章同时准备好,不然也不会草草结尾了,而且上篇文章中主观因素占了较大的比重,因为回忆起这件事的时候确实有很多想法,因此显得有些个人化.日记化了.

前文提要 承接前文<一次线上Mysql数据库崩溃事故的记录>,在文章中讲到了一次线上数据库崩溃的事件记录,建议两篇文章结合在一起看,不至于摸不着头脑. 由于时间原因,其中只讲了当时的一些经过以及我当时的一些心理活动,至于原因和后续处理步骤并没有在文章中很清晰的写出来,以致于很多朋友说看得不清不楚的,这里向他们道个歉,主要是上周真的没有足够的时间将两篇文章同时准备好,不然也不会草草结尾了,而且上篇文章中主观因素占了较大的比重,因为回忆起这件事的时候确实有很多想法,因此显得有些个人化.日记化了.

前言 生产环境的数据库往往需要经过严格的安全限制,所以禁用密码登录,使用秘钥的方式是一种相对安全的登录方式. 原理: 角色: 主机A:其他主机,有访问线上数据库的权限 主机B:线上数据库的主机 主机C:本机电脑,无访问线上数据库的权限 在本机C上(无访问B的权限),通过ssh配置的主机A(有访问B的权限),访问Navicat常规配置的主机B,即以A的身份连接使用B. 前期准备 生成ssh密钥对.可参考前期博文:快速通道 Navicat配置登录 1.连接的主机配置,如果连接的是线上数据库,就用线上

介绍 从系统管理员或 DBA 的角度来讲, 总期望将线上的各种变更限制在一个可控的范围内, 减少一些不确定的因素. 这样做有几点好处: . 记录线上的库表变更; . 对线上的库表变更有全局的了解; . 如果有问题, 方便回滚操作; 从这三点来看, 有很多种方式可以实现, 比如通过 migrate 等工具强制所有的操作都以统一的方式执行, 这需要开发人员做更多的配合, 所以这类工具在非规模话的业务场景中较难实现; 另外管理员或 DBA 也可以通过知识库比如 redmine 等类似的方式记录变更,

       近期公司运营同学经常表示线上我们一个后台管理系统运行特别慢,而且经常出现504超时的情况.对于这种情况我们本能的认为可能是代码有性能问题,可能有死循环或者是数据库调用次数过多导致接口运行过慢.应领导要求,我们将主站中进行性能测试的框架代码(见我前面一篇博文记录一次通过性能日志处理线上性能问题的过程)添加到了该后台管理系统中.上线运行一段时间后,查看相关日志可以看到如下分析日志:        通过该日志可以发现,dao方法一直获取不到数据库链接池,但是根据实际情况考虑应该不大可能,

我们的业务是 所使用的数据库是 自己搭建的mysql-server-5.05, 服务器 红帽子6.0. 考虑到 服务的稳定性,计划将数据库向dba进行迁移,由他们进行维护.dba的迁移计划是 1 先创建 从库,将我们旧库(现有库)的数据 同步过去. 2 同步好以后,让我将app 切换过去就好. 为了给旧库 加从库,需要修改旧库配置文件,并添加一下配置,重启. log-bin = mysql-bin log-bin-index = mysql-bin.index innodb_flush_log_

前言 MySQL 死锁异常是我们经常会遇到的线上异常类别,一旦线上业务日间复杂,各种业务操作之间往往会产生锁冲突,有些会导致死锁异常.这种死锁异常一般要在特定时间特定数据和特定业务操作才会复现,并且分析解决时还需要了解 MySQL 锁冲突相关知识,所以一般遇到这些偶尔出现的死锁异常,往往一时没有头绪,不好处理. 本篇文章会讲解一下如果线上发生了死锁异常,如何去排查和处理.除了系列前文讲解的有关加锁和锁冲突的原理还,还需要对 MySQl 死锁日志和 binlog 日志进行分析. 正文 **日常工作

最近在CNode社区看到有人分享了免费的线上mongodb数据库(容量500M),今天去注册了一下,成功的将线下数据库替换掉了,现在就说一下它的使用和配置需要注意的地方: mLab是一款免费的在线mongodb数据库,它为用户免费提供了500M容量,这个数据库只能选择默认的,当然想要使用其他的就肯定要收费,以美刀计算. 说一下他的配置和使用: 首先需要注册,注册完之后在首页有MongoDB Deployments和Private Environments两个,后面这个是私人环境,不太懂什么意思,

使用percona-xtrabackup实现对线上zabbix监控系统数据库的主从同步 业务背景: zabbix3.0.4是业务的主要监控,部署在一台单机中,为避免数据丢失先对其做数据主从同步,因主数据库已经运行了一段时间,数据量大概有10G左右为快速实现主从,使用percona-xtrabackup工具进行备份和恢复 master db: 操作系统: centos7.2 x86_64 mysql: mariadb 5.5.47 通过yum安装的mariadb(yum -y install ma

文章简介 工作这几年,技术栈在不断更新,项目管理心得也增加了不少,写代码的速度也在提升,感觉很欣慰,毕竟是在一直进步,但是过程中也有许许多多的曲折,也踩过了数不尽的坑坑洼洼,从一个连百度都不知道用的萌新到一个悠哉悠哉的老油子也不容易,很多人应该都有类似的经历和感受,因此博客中也会整理一些曾经碰到过的事故和问题给自己提个醒. 由于接下来要在perfect-ssm项目中引入缓存模块,恰好在翻看日记时看到了这次事故的记录,因此整理了这篇文章,根据事件发生时的日记来回顾一下这次事件,通过这次数据库事故的

作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载. 文章简介 工作这几年,技术栈在不断更新,项目管理心得也增加了不少,写代码的速度也在提升,感觉很欣慰,毕竟是在一直进步,但是过程中也有许许多多的曲折,也踩过了数不尽的坑坑洼洼,从一个连百度都不知道用的萌新到一个悠哉悠哉的老油子也不容易,很多人应该都有类似的经历和感受,因此博客中也会整理一些曾经碰到过的事故和问题给自己提个醒. 由于接下来要在perfect-ssm项目中

更改默认端口 sudo vi /etc/mongod.conf 进入conf文件,修改port值为19999保存并退出. 重启mongodb sudo service mongod restart 进入mongo shell mongo --port 19999 本地数据库导入线上服务器的mongodb中 1 备份本地数据库 git 切换到mongodb/data,输入: ../bin/mongodump -h 127.0.0.1:27017 -d vueBlog -o ../data/vueB

SSM上传EXCLE到数据库 和 从数据库导出为EXCLE package com.ABC.controller; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.FileOutputStr

        最近线上项目报了一个MySQL死锁(DealLock)错误,虽说对业务上是没有什么影响的,由于自己对数据库锁这块了解不是很多,之前也没怎么的在线上碰到过.这次刚好遇到了,便在此记录一下.   出现死锁问题背景         项目层面:报错的项目做的是一个批量下单的动作,会同时写入多条订单数据,代码之前写的是一个事务中一个循环一条一条insert到数据库(至于为啥没用批量插入就不追究了,历史原因了).         数据库层面:一张test表(非线上真实表),比较重要的是有一个

1.特别注意:拿来线上php程序后一般是不需要修改config.php里面的数据库连接信息的,如果修改了会报错:站点已关闭.所以 2.5 步骤是需要省略的.如果拿来的是最开始的php源码,需要配置原始数据库信息,2.5 步骤就需要做,但是一般也是研发配置里面的数据库信息, 2.创建php程序的数据库用户(可省略) mysql> create database itshop; mysql> grant all privileges on *.* to'itshop'@'%' identified

背景 公司有一个数据处理线,上面的数据经过不同环境处理,然后上线到正式库.其中一个环节需要将数据进行处理然后导入到另外一个库(Sql Server).这个处理的程序是老大用python写的,处理完后进入另外一个库后某些字段出现了乱码. 比如这个字符串:1006⁃267X(2020)02⁃0548⁃10 另外一个库变成:1006?267X(2020)02?0548?10 线上人员反馈回来后老大由于比较忙,一直没有排查,然后我问了下估计是什么原因.老大说他python里面转了utf8,可能是编码问题

文章首发在公众号(龙台的技术笔记),之后同步到博客园和个人网站:xiaomage.info 优化项目代码过程中发现一个千万级数据深分页问题,缘由是这样的 库里有一张耗材 MCS_PROD 表,通过同步外部数据中台多维度数据,在系统内部组装为单一耗材产品,最终同步到 ES 搜索引擎 MySQL 同步 ES 流程如下: 通过定时任务的形式触发同步,比如间隔半天或一天的时间频率 同步的形式为增量同步,根据更新时间的机制,比如第一次同步查询 >= 1970-01-01 00:00:00.0 记录最大的更

一.MDL元数据锁 在修改表结构之前,先来看下可能存在的问题. 1.什么是MDL锁 MySQL有一个把锁,叫做MDL元数据锁,当对表修改的时候,会自动给表加上这把锁,也就是不需要自己显式使用. 当对表做增删改查的时候,加的是MDL读锁 当对表结构做变更修改的时候,加的是MDL写锁 读与读之间不互斥,读与写,写与写之间互斥,因此 当有一个线程对表执行增删盖茶的时候,会阻塞掉别的线程对表结构修改的请求 当有一个线程对表结构修改的时候,会阻塞掉别的线程对表增删改查的请求 2.MDL锁的问题 并且MDL