所有文章

非常郁闷的一件事。公司的网络架构非常有意思，灵活性极大。导致我这个总在公司之外用openvpn连进去的人很痛苦，无法复现同事提出的问题。 没办法，需要在公司网络内部有台测试机，那实际是有很多的，但都是debian或者ubuntu的，而问题偏偏是网页打不开的问题。 那就干脆找一台Ubuntu，安装一下远程桌面，用RDP 3389连进去，启动一个Firefox，进行测试即可。 步骤如下： 一、升级ubuntu到最新 sudo apt update sudo apt upgrade -y 二、安装xrdp sudo apt install xrdp -y 三、安装桌面环境xfce sudo apt install xfce4 xfce4-goodies -y 四、配置xfce使用xrdp echo xfce4-session > ~/.xsession # 将最后一行替换掉 sudo vi /etc/xrdp/startwm.sh #exec /bin/sh /etc/X11/Xsession exec startxfce4 五、设置xrdp服务自启动 sudo systemctl enable xrdp sudo systemctl start xrdp 六、如果有防火墙，记得放开3389的tcp端口 七、把用户加入ssl-cert组 # 这里我的登录用户是debian sudo adduser debian ssl-cert # 加组不用重启，如有其它改动需要重启 sudo systemctl restart xrdp 八、安装Firefox sudo apt install firefox-esr 九、开远程桌面，连上去，开个命令行执行firefox-esr ...

要做一个mongodb集群的迁移和恢复，真是折腾死人了。记录并顺便吐槽一下： mongodb的tools真的是太简易、粗糙、丑陋了。 线上的源数据库是腾讯的服务，要废弃搬迁到内网，足足折腾了一个星期。 线上源数据库环境如下： 云数据库 TencentDB 4C/8GB/500GB 3节点 于是在线下对等建立了mongo集群，同样配置，同样3节点。 噩梦由此开始啊，注意线下集群的memory配置一定要高： 32GB 用户名和密码一定要和线上完全一致 如果用户名密码不一致，Document恢复完毕，Index无法建立，因为是完全恢复，会覆盖admin这个db 然后开始dump线上数据 mongodump -vvvvv --uri="mongodb://root:xxxxxxxx@10.1.2.3:27017/?authSource=admin" 然后生成一个24G大小得dump文件夹，压缩后2.4G，传输到线下库上准备恢复 # 大量恢复必须扩大文件句柄，否则过不去 ulimit -n 655360 # 一定要记录下来开始的时间戳，后面有用 date Sun May 11 06:34:02 PM CST 2025 # 开始恢复，漫长的一天开始了 # 必须放到screen中执行，否则网络不好，断了也会很悲剧 screen -L ./mongorestore \ --drop \ --host=192.168.111.222 \ --port=27017 \ --username=root \ --authenticationDatabase=admin \ --nsExclude=admin \ /root/dump ctrl+a+d 其实刚开始线下三节点得配置是8G，然后恢复用了一晚，报错，直接把shard3给打崩了，虽然三节点都是docker启动得，有自动恢复机制，但是mongorestore可不管这个，中断期间有1000个Document没有恢复成功。 重试了2次后才发现这问题，2天已经过去了，意识到就立刻把内存提升到32G，再次进行恢复。 但是新建的集群的密码跟源库这时是不一致的，又一天过去了，Document文档是恢复完毕，Index又无法建立，因为用户名和密码不一致，Fuck！ 又双叒再次开始恢复，这下天下大吉了，然后这还不算完！ restore后，其实又过了一天，那要追平之后的数据，就得用上实时同步工具了，这里用的是阿里的mongoshake 下载： wget https://github.com/alibaba/MongoShake/releases/download/release-v2.8.5-20250403/mongo-shake-v2.8.5.tgz tar zxvf mongo-shake-v2.8.5.tgz cd mongo-shake-v2.8.5 wget https://raw.githubusercontent.com/alibaba/MongoShake/refs/heads/develop/conf/collector.conf 我们需要注意collector.conf的以下地方： ...

mongodb 公司现在运行的版本是mongodb 4.2.19，在处理allowDiskUse的时候失败 对比了一下，似乎另外一个集群跑的是5.0.5，就没有问题 那就升级一下，步骤如下： 首先下载 5.0.30 wget --no-check-certificate https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-debian11-5.0.30.tgz 然后解压弄好，准备好mongodb.conf dump下来老数据，不加·–quiet·的参数有可能会遇到EOF的错误 mkdir mongobackup cd mongobackup mongodump --quiet 然后杀掉4.2.19，启动5.0.30，把数据回灌回去，同样要用--quiet参数 cd mongobackup mongorestore --quiet 这样就OK了。 注意，mongo 是吃内存大户，如果备份不下来，或者恢复不进去，请增加内存。 曾有过一次，8G->16G->32G 才成功。 而且必须一个一个db进行备份，一个一个db进行恢复，记得备份 admin 数据库 mongodump -d message mongorestore --port 37017 --drop --nsInclude=message.*

管理了一个AWS的EKS集群，用的是ALB的负载均衡，这个负载均衡和Nginx有区别，有很多特殊的地方需要注意。 基本需要宣告很多独有的 annotations 一、http自动跳转到https annotations: alb.ingress.kubernetes.io/actions.ssl-redirect: | {"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}} ...... - host: '*.bajie.dev' http: paths: - backend: service: name: ssl-redirect port: name: use-annotation path: / pathType: Prefix 注意，annotation了上面一条，那么在LB中，http 80的规则就只剩下这一条了，压倒一切的规则。 之后你再annotation别的http规则，会不生效；你只能去annotition https的规则。 二、www重定向 例子： 输入 rendoumi.com，会自动重定义到 www.rendoumi.com annotations: alb.ingress.kubernetes.io/actions.www-redirect: | {"type":"redirect","redirectConfig":{"host":"www.rendoumi.com","port":"443","protocol":"HTTPS","statusCode":"HTTP_301"}} ...... - host: rendoumi.com http: paths: - backend: service: name: www-redirect port: name: use-annotation path: / pathType: Prefix 这个是直接301跳转到https去了 ...

同事上线，把数据库初始化脚本改了名。结果导致上线把库表的数据全给重新初始化了。这下事来了，恢复库表。 之前用过阿里云的库表恢复，非常简洁，那这次也照猫画虎学一回，步骤如下： 一、保存现在的记录： 把所有相关的binlog拷贝到一个备份目录保存。 二、最好新建一个mysql实例： 阿里确实事新起了一个实例，避免操作对旧实例造成影响。 我们实战中可能没必要，但也要封锁数据库的读写： iptables -I INPUT -p tcp --dport 3306 -j DROP # 把自己放通，后续可能自己要进行 mysql 或 mysqldump 的操作 iptables -I INPUT -s 127.0.0.1/32 -p tcp --dport 12530 -j ACCEPT 三、解析binlog 我们需要把重放日志拿出来： mysqlbinlog --start-datetime="2025-01-02 14:40:00" --stop-datetime="2025-01-02 14:50:00" --verbose binlog.000009 |grep -i -C15 "drop table"|more mysqlbinlog binlog.000009 --stop-position=260734003 --database=work_oa > 9.sql 注意，分析：看到 at 260734003 下面有个 drop table ，说明是在 260734003 之后发生了 drop table 操作 所以，回放到260734003就可以了。之后、之后、之后才操作的！！！ /*!80014 SET @@session.original_server_version=80019*//*!*/; /*!80014 SET @@session.immediate_server_version=80019*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 260734003 #200311 20:06:20 server id 1 end_log_pos 355 CRC32 0x2fc1e5ea Query thread_id=16 exec_time=0 error_code=0 SET TIMESTAMP=1583971580/*!*/; SET @@session.pseudo_thread_id=16/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1168113696/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8mb4 *//*!*/; SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; /*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/; DROP TABLE `pets`.`cats` /* generated by server */ /*!*/; # at 260734009 #200311 20:07:48 server id 1 end_log_pos 434 CRC32 0x123d65df Anonymous_GTID last_committed=1 sequence_number=2 rbr_only=no original_committed_timestamp=1583971668462467 immediate_commit_timestamp=1583971668462467 transaction_length=473 # original_commit_timestamp=1583971668462467 (2020-03-11 20:07:48.462467 EDT) # immediate_commit_timestamp=1583971668462467 (2020-03-11 20:07:48.462467 EDT) /*!80001 SET @@session.original_commit_timestamp=1583971668462467*//*!*/; /*!80014 SET @@session.original_server_version=80019*//*!*/; /*!80014 SET @@session.immediate_server_version=80019*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 260734188 #200311 20:07:48 server id 1 end_log_pos 828 CRC32 0x57fac9ac Query thread_id=16 exec_time=0 error_code=0 Xid = 217 use `pets`/*!*/; SET TIMESTAMP=1583971668/*!*/; /*!80013 SET @@session.sql_require_primary_key=0*//*!*/; CREATE TABLE dogs 我们还是先找到 binlog 中 drop table 之类的操作字样，然后确定 position 后，把 binlog.00009 中之前的 log 导出。 ...

xxl-job的日志数据实在是太大了，压根就没有清理过，设置一个定时任务来定时删除无用的废数据吧： 首先要确认定时任务开关已经打开了 show variables like 'event_scheduler'; On表示开启 然后到指定的库下，use k8s_xxl_job CREATE EVENT delete_k8s_xxl_log ON SCHEDULE EVERY 1 DAY DO DELETE FROM xxl_job_log WHERE trigger_time < CURRENT_TIMESTAMP - INTERVAL 7 DAY; 保留今天的数据，以及前7天的老数据。 查看以及编辑定时任务的命令： #查看 show events; #查看细节 SHOW CREATE EVENT delete_k8s_xxl_log #编辑 ALTER EVENT delete_k8s_xxl_log ON SCHEDULE EVERY 1 DAY DO BEGIN -- 在这里添加你想要执行的操作 END;

其实我们用的是yearning来管理 MySQL 数据库变更需求的，但是，类似 Oracle 或者 PolarDB，就用不成了。 这事只能交给阿里云的dms来管理了，其实dms要比yearning强大很多，可以精确控制到表的行级别权限的。 理由就是dms是个web页面，代理连接到后端的数据库，所以要显示什么，不要显示什么，从web界面是完全可以控制的。实际到数据库级别反而有的是控制不住的。 这就梳理一下建立审批流的步骤： 一、dms同步ram用户 ram用户是管理的基础了，这些用户必须先行导入dms，我们才能进一步赋予owner，DBA的权限 用户管理–>同步子账号，选择要dms要使用的账号同步过来即可 二、设定实例DBA DMS里的权限是这样的：库的话有Owner，然后实例的话有DBA，最上是管理员。 那么一个实例里有几万张表，没人会想一个一个点击赋Owner的权限吧。 那就粗分一下，一个人对整个实例有权限审批即可。这样要先设定整个实例的DBA角色。 我们先编辑用户，让他有DBA的角色，以供之后在实例级别可以选择他 然后去实例管理里面： 选择实例的右边，更多–>编辑实例 实例的账号、密码、安全协同、安全规则都选上，然后高级信息里，实例DBA就可以选择刚才设置了DBA角色的人了 三、设置审批流程 然后去安全与规范，审批流程，新增审批模板，来自定义审批流 我们公司的审批流不是380缺省那个，380是需要三个人审批的： 我们的链路就很建单了，有操作权限的人找实例的DBA审批，然后过最高管理员批就完了，所以做如下的流程： 四、设置安全规则 我们再到安全与规范，点击安全规则，找到具体实例里设置的 强管控模式 for MySQL 可以看到已经有2个实例用上了，然后到右边，点击编辑： 最主要的就是SQL变更，数据变更默认审批模板的设置，我们改成我们自己的审批流即可 其他的选项都可以按需进行修改。 五、设置用户权限 如上审批流就完成了，我们要登录具体的实例列表，再更多里设置权限 注意上面是设置的实例级别的权限。 如果要设置更细级别的库、表、行权限，需要点击数据库列表 在这里面的表详情的右边更多，可以控制库、表、行的权限 这样就可以弄完整个流程了。

这个问题十分的讨厌啊，Bi大数据部会群发报表邮件，但是如果有某位员工离职了，邮件地址被清理掉不存在了，那么群发邮件的时候会导致群发失败。 网上搜索了一圈，阿里有篇文章是同样问题： https://blog.csdn.net/javaee_sunny/article/details/114836546 解决方法是修改发送程序，剔除掉失效的邮件地址再发。 这个方法在我们这里是行不通的，因为发送程序没人维护了，无法修改。 那就只能曲线救国了：建立一个转发服务器，把群发邮件变成一封一份单独发，那么偶尔一份失败就失败了，不会导致整个群发的失败。 搭建一个Postfix relay转发服务器： vi /etc/postfix/main.cf relayhost = [smtp.qiye.aliyun.com]:587 smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_use_tls = yes smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_sender_dependent_authentication = yes smtp_destination_recipient_limit = 1 message_size_limit=102400000 解释：转发到阿里邮件服务器的标准配置，网络上已经有很多教程了。然后关键就一条smtp_destination_recipient_limit = 1,这个就会把群发的邮件拆成单独的一封一封发送，发不出去的会回到queue尝试不断发送，最后失败drop掉。 另外postfix缺省发送邮件的大小是10M，阿里邮局缺省是50M，我们需要修改一下，message_size_limit=102400000改成100M的限制。 最后生成一下邮件用户的hash库： vi /etc/postfix/sasl_passwd [smtp.qiye.aliyun.com]:587 report@ddky.com:xxxxxxxx postmap /etc/postfix/sasl_passwd 那么发邮件的时候指定这台服务器，用户名是 report@ddky.com , 密码是xxxxxxxx就可以了 补充，需要安装缺少的库，否则登录阿里邮局过不去，还需要打开服务器的允许网段列表，mynetwork yum install -y cyrus-sasl-plain

这不是要出国就提前搭建了一个voip的电话系统么，结果在使用的过程中，华为的猫棒居然出现地址来回跳动的问题。 正常情况下，lsusb的结果 lsusb Bus 001 Device 017: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick 过一阵子，或者持续几天后，地址就变了 lsusb Bus 001 Device 017: ID 12d1:1446 Huawei Technologies Co., Ltd. HSPA modem 看上面，vender id从1436变成了1446，名字也从stick变成了modem 由于这个usb设备是直通到kvm的freepbx虚机里面去的，这直接导致voip系统不能用了，可恶啊。 必须把它给固定下来，首先先从1446变回1436 yum -y install epel-release yum -y install use_modeswitch usb_modeswitch -v 12d1 -p 1446 -c "/usr/share/usb_modeswitch/12d1:1446" 变回来了不成，还得把它彻底固定下来 vi /lib/udev/rules.d/40-usb_modeswitch.rules #装了usb_modeswitch后居然已经自带了 # Generic entry for most Huawei devices, excluding Android phones ATTRS{idVendor}=="12d1", ATTRS{manufacturer}!="Android", ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch '%b/%k'" shit，不管它，再次强行固定 vi /lib/udev/rules.d/40-usb_modeswitch.rules、 # Huawei, newer modems ATTR{idVendor}=="12d1", ATTR{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'" 这样就搞定了，得亏提前发现了这问题，否则跑到国外再发现，就晚了！ ...

公司选用了阿里云的PolarDB做数据库，这个东西其实就是Postgres增加了外挂，可以支持Oracle语法。 没办法，得仔细研究一下Postgres的用户管理了。 PostgreSQL权限架构是宝塔形结构 最上层是实例 实例中允许创建多个数据库 每个数据库中可以创建多个schema， 每个schema下面可以创建多个对象。 对象包括表、物化视图、操作符、索引、视图、序列、函数、… 等等。 上面schema中有个奇怪的东西，public，注意：是小写。 先总结：PUBLIC是缺省的权限，代表所有人的意思（是个角色）。 默认情况下，在创建数据库之后，允许PUBLIC角色(大写)连接，即允许任何人连接。 默认情况下，数据库在创建后，不允许除了超级用户和owner所有者之外的任何人在数据库中创建schema。 默认情况下，在创建数据库之后，会自动创建名为 public 的schema，这个schema的all权限已经赋予给PUBLIC角色（注意是大写），即允许任何人在里面创建对象。 schema级别的权限，包括允许查看schema中的对象(USAGE)，以及允许在schema中创建对象(CREATE)。 默认情况下新建的schema的权限不会赋予给PUBLIC角色，因此除了超级用户和owner，任何人都没有权限查看schema中的对象或者在schema中新建对象。 举例来说，建了个库，又建了用户，没给这个用户赋予任何权限。缺省他就从PUBLIC角色继承了对库里的schema.pulic权限，可以连接到这个schema.pulic，并且在这里建临时表、建表、view等等对象，但是没办法建立其它schema。 PostgreSQL的模式（SCHEMA）可以看作是一个表的集合。 一个模式可以包含视图、索引、数据类型、函数和操作符等。 再来说角色： 在数据库中所有的权限都和角色挂钩。 角色和用户的唯一区别在于，角色是nologin的，而用户允许login，仅此而已。 而"PUBLIC"是一个特殊的角色，代表着所有人。 那又有一个问题： 每个PostgreSQL对象都有一个名为“所有者”的特殊角色。只有所有者才能执行某些操作，如 ALTER TABLE ，而你不能将这样的权限授予非所有者。 那不可能只有一个人可以alter表结构吧，我们可以使用角色继承来解决此问题。创建 table_owner 角色并且 GRANT table_owner TO user1, user2 （user1和user2继承table_owner)，然后赋权 ALTER TABLE my_table OWNER TO table_owner 赋予table_owner所有者角色。现在表的所有者是 table_owner 了，但是因为 user1 和 user2 是该角色的成员，所以他们也具有继承权限来运行 ALTER TABLE了，如下图 。 啰嗦了这么多，除了修改pg_hba.conf，赋权的命令就两条，grant和revoke，看下图： 进入实战，首先从上到下都看一看，有什么库，有什么schema，有什么对象，有什么表，有什么索引，有什么角色： #推荐用psql来进行管理，有很多快捷键，navicat里面是没有的 #没有的话就装一个 yum install postgresql.x86_64 psql -h 10.8.2.61 -U admin #必用快捷键 #列出所有的库 \l #列出所有的schema \dn #看schema.public权限 \dn+ public #列出所有的对象（table, view, sequences） \d #列出所有的角色 \du #列出所有表 \dt #列出所有索引 \di #同样的sql select * from pg_roles; #看看能登录的用户有哪些 select * from pg_user; 那自顶向下开始： ...