Submitted by gouki on 2022, November 11, 12:40 PM
买了腾讯云的轻量数据库,便宜(其实现在和直接买1c1g的数据库也差不多了)。在做数据迁移的时候直接用了navicat的data transfer(这功能真方便)
因为数据库不大,只有2~300M,用datatransfer走起来非常快。基本上3分钟左右 就搞定了。如果我dump sql,再upload & import sql,反而比这个速度还要慢一点。
然后问题就来了,查询的时候,全是乱码,这个很明显,是latin1的问题了,于是上数据库 执行了一下:SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然
character_set_client latin1
character_set_client_handshake ON
character_set_connection latin1
character_set_database utf8mb4
character_set_filesystem binary
character_set_results latin1
character_set_server utf8mb4
character_set_system utf8
这个就纠结了,即使我set names utf8mb4,用datatransfer也是这个问题。
我导数据过来的那一台,也是轻量级数据库,理论上不应该会有这个问题,于是我看一下connection的相关信息。发现正常的那台,encoding居然选的是auto,而这台不正常的选择的是utf-8,难道是因为这个原因?于是切回auto重连。
再次运行SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然 character_set_client 已经恢复成utf8mb4了。
这个问题也真是妖~
DataBase | 评论:0
| 阅读:3142
Submitted by gouki on 2022, July 19, 2:45 PM
突然发现自己还有一个database的分类,想想以前还在为了折腾怎么弄mysql更好,后面被各种数据库折腾(小型公司,不涉及大数据库,都是常规的,象pg/sqlite/sqlserver/mongodb/redis)。
平时用的最多的还是navicat,不过我现在还在用11,用它的原因很的很奇怪也很尴尬
1、他的 cmd+ . , cmd+shift+.可以用来关库关表 (12开始,居然没有这个快捷键了)
2、12开始密码存到keychain里了。导致我其实没有办法迁移数据库(确实很尴尬,很多密码居然都忘光了。。。。但还能连接)
3、UI的变化,也让我有点不太习惯。
所以只能一直用着11了,11也有不少小问题,比如从新版的macos 11起,在data管理界面,对数据操作的Icon全部不见了,我都是凭记忆在猜在操作。
所幸+,-等还在因定的位置,刷新可以cmd+R,所以我其实已经忍了好多年了。
之所以还在一直使用,就是因为navicat的data transfer实在太方便了。对于一些小的表,要复制到本地,或者复制到线上。。直接在表名上data transfer就可以导入到指定的target库里了。
当datagrip出来后,我本来想的是可以迁移了,至少他是免费的,而且也支持市面上几乎所有的数据库,然而就是我说的data transfer这个功能阻挡了我,即使我安装了datagrip,也很少用它,直接我无意中搜索到了这个:
Copy | DataGrip (jetbrains.com),原来它不叫data transfer,而是叫:copy to ....,将指定的表copy 到target里。
简单的在本地用sqlite进行了测试,操作完美,但这毕竟只是同库操作,于是我又试了一下,copy table from sqlite to mysql,完美~~
看来以后可以切换着使用datagrip了~(缺点也有,打开的时候数据过多的时候,没有navicat快。想想也是,毕竟是基于java的。而人家是纯C写的(也可能objc) )
结论:是的,你真的可以开始尝试DataGrip了
---EOF---
刚发现,DataGrip居然是收费的。不过我反正都买了全家桶了,所以也可以自豪的说用正版了,要知道原来用navicat premium可是擦边球的,You Know~~
DataBase | 评论:0
| 阅读:4670
Submitted by gouki on 2020, September 13, 11:47 PM
很突然,线上有一台服务器,突然报表不存在。所有的项目只要涉及到数据库的,都直接报表不存在。SSH到服务器上一看,进程也活着,目录下的文件也存在着,怎么就表不存在了呢?
当时也没有注意,觉得可能是程序出错了。就restart了一下数据库,结果,这回出大事了,数据库无法启动。再启动,仍然是这个问题。连忙看了一下日志,发现报错原因居然是磁盘满了。这,不科学啊。df -h 看一下,果然,系统盘自带的20G,剩余空间为0。
怎么办?先清一下apt-cache,发现多出100多M的空间,尝试启动了一下,果然数据库启动了。再检查到底是谁占了?直接du -sh /var/log。居然只有200M,那是怎么回事呢?
继续 找,du -sh 一个目录一个目录的看。发现居然是mail目录写满了,一个mail文件。17G,用tail -n 1000 看了一下。文件居然都来自crontab ,再打开crontab -l,才发现,原来是有一个5年前的svn的勾子在运行。这个勾子,每5秒一次,就这样辛苦的运行了5年,终于通过邮件,硬生生的将磁盘写满了。
知道问题所在就简单了。关闭crontab (因为已经不用了)。同时清空邮件文件。再df -h,发现多出17G空间。好嗨森
DataBase | 评论:0
| 阅读:6564
Submitted by gouki on 2020, March 31, 12:22 AM
习惯了用navicat之后。居然不会用命令行了。。。
记录一下算是备份
1、进入mysql命令行,创建一个新库,create database xxxx; //先看一下旧库的格式。用show create database `库名`,主要是看一下旧数据库的编码:
CREATE DATABASE `xxx` DEFAULT CHARACTER SET UTF8 COLLATE UTF8_GENERAL_CI;
2、mysqldump 旧库 -u root -p123456 --add-drop-table | mysql 新库 -u root -p123456
假设密码是123456
3、grant 权限给指定的用户
grant all privileges on xxx.* to 'user'@'localhost' identified by 'password',很方便的指定。记得localhost那个地方尽量不要留空。留空默认代码的是%
4、真正要用的时候,其实查一查都OK。。
DataBase | 评论:0
| 阅读:7829
Submitted by gouki on 2017, September 21, 2:07 AM
原来的数据库是N年前的,默认字符集是latin1,但是有一些旧代码中,连接参数写的是UTF8,于是就这样。。。DB字符集为latin1,连接UTF8,存到数据库也是UTF8,wj但查看的时候显示是???
为了标准统一,于是使用mysqldump -uxx -p database a b c d e > dump.sql,将部分表先导出来
然后修改导出sql的charset=latin1;改为charset=utf8;
至此,操作完成。简单粗暴
-------EOF--
deeka说,如果有200G呢。目前我是停机处理的。因为要处理的数据也不是很多。如果不是因为升级换库的时候出现不能访问我也不会这么做。
但好象也没有特别好的方案。因为直接alter的时候也是各种不正常。才dump的
DataBase | 评论:1
| 阅读:17252