前言 🔗
在之前的文章中提到了Pgsql的一些使用，恰逢年度计划想把公司的整体业务从mssql迁移至pgsql中
至于为什么，道理是显而易见的，生命在于折腾（不是
截至本文攥写之日，迁移工作仍在继续中，未来可能会更新
初衷 🔗
首先如果你的公司购买了正版授权的mssql那我还是建议继续使用，花钱买背锅侠挺好的
以下是我总结出的mssql的劣势，当然优势有很多不再一一列举
- 在mssql中没有类似于mysql的binlog或pgsql的pub/sub的东西，对于redis或者elastic search来说只能通过代码侵入的方式写到业务里，比较冗长
- mssql正版授权较贵，一般公司无法承受
- 截至目前mssql的linux版本仍然跟个智障一样，无法用于线上服务
- 功能性没有pgsql多
选型 🔗
毋庸置疑，迁移工作是比较复杂且繁琐的，因为使用的orm并不是ef core这种，所以在curd层面会涉及到大量的代码变动，其次，pgsql与mssql的部分语法/类型不一样，需要检查哪些东西是mssql特有的（例如BulkCopy）
无比讨厌ef core，所以即便迁移也不会选择使用ef core!!!!
初选方案为：freesql，sqlsugar
备案方案为：在现有orm（自己写的）基础上进行魔改
迁移 🔗
迁移方案之前想到的有
- navicat
- export to csv
- pgload
- 手撸（
在各种对比之下还是选择了pgload的方式，navicat速度奇慢，export to csv有点麻烦（表多），手撸又太懒
然后开始查看pgload从mssql的迁移文档，看了半天觉得好像没啥难度，于是开始操作
首选安装如下工具
- freetds
- pgload
迁移开始
1pgloader --debug 'mssql://sa:密码@IP:1433/库名' 'postgresql://postgres:密码@127.0.0.1:5432/库名'
我觉得应该没啥问题，毕竟官网都这么写了，结果一直不行，就当我快放弃的时候，后来我才发现，我的mssql密码中有转义字符，毕竟数据库密码很复杂很正常你说是吧，（例如7YZ%T%@g^9hv5mVraN!xBc）
后来单独创建了一个账户，用了uuid作为密码可算是好了，结果又发现了新的问题
如下都是积累的宝贵经验，都是血与泪的经验啊！！
- mssql和pgsql的密码不要过于复杂，如果过于复杂创建个新账号即可
- 在打开–debug后，迁移速度很慢，然后硬盘也满了，记得迁移的时候一定要关闭–debug
- 在/etc/freetds/freetds.conf中，记得将global下的min pool conn和max pool conn设置高一点，否则会显示链接数已满然后崩溃
如下是我的迁移
1LOAD DATABASE
2 FROM mssql://sa:密码@IP:1433/库名
3 INTO postgresql://postgres:密码@IP:5432/库名
4
5WITH
6 batch rows = 10000,
7 concurrency = 30,
8 prefetch rows = 1000
9
10SET work_mem to '128MB',
11 maintenance_work_mem to '512MB',
12 search_path to 'public'
13
14# 不包括某些表
15#excluding table names like '表名' in schema 'dbo'
16
17alter schema 'dbo' rename to 'public';
迁移后的结果如下图所示，为测试版本库随便弄（线上记得备份）
因为在mssql中，我的表名为命名方式为PascalCase而非camelCase或者snake_case，这就很难受了
等过些时候弄成snake_case的方式会看起来很舒服2333（想不通为啥pgsql的查询如果有大写必须双引号