AWS的跨账号访问不同VPC域中的服务

公司有两个AWS账号,有各自不同的 VPC 域。其中一个账号用到了 Aurora Postgres Serveless 的数据库。 现在另一个账号也需要用到posgres数据库,最直接的想法是在本域再搭一套postgres,或者ec2新加一台,上面安装posgres。 先去检查了一下已有的postgres serverless服务,结果使用率才23%,当下就直接想复用它了。 那能不能单独再开一个db,单独给第二个账号用呢,查了半天资料。可以的,但是吧,chatgpt真的是满嘴胡说八道,连带gemini也是。 aws家的东西都是开源经过魔改,跟网上占大多数的资料是不同的,这直接导致 chatgpt 按照网上大多数文档来进行推理,导致错误!!! 还有就是aws家的东西更新修改很快,最新的文档和之前的文档不同,也导致 chatpt 按照网上大多数的旧文档来进行推理,导致错误!!! 这个东西的架构图如上,右边的VPC里面连着 aurora 服务,它实际是target group的一个目标,然后上联到nlb,nlb再上联到endpoint service,对外提供服务. 然后左面VPC中建endpoint,通过PrivateLink连接到右边的EndpointService,这样通过私有的dns name和security group再进行控制,就可以直接连到右边的endpoint service服务资源了。 具体的做法步骤如下: 一、第一步,右边的VPC中 1、建立EndpointService 到VPC中,左边的Endpoint Services,点击: 点击Create endpoint service新建一个 名字:postgresql-serverless-endpoint-service,由于现在还没有nlb,需要再新建一个;点击Create new load balancer 2、建立nlb 点击:Create load balancer新建 这个类型,只能是nlb 我们这个nlb,不放在公网,不公开,所以选私有的Internal,只有IPV4,不提供IPV6. 网络选该VPC,子网选择三个private的子网 Security groups选择一下,这里rds-sg的inbound规则是允许TCP端口5432的进入,如果没有就新建一个SG 到最后了,居然还没有target group,那又要建一个了,点击Create target group建立 3、建立target group 名字叫做:postgres-target-group 我们选IP addresses,因为要连到后面的postgres服务 然后选好TCP,Port 5432, IPV4,VPC,其它保持缺省,然后建立 ...

2025年5月21日

kafka的测试替代品-redpanda

公司的一个公网要搬到内网的一个Rancher集群上,很繁琐 原有的架构有kafka,要在内网复现一个出来 那3节点的kafka和3节点的zookeeper,真的是不想搭啊 搜啊搜啊搜啊搜,终于找到若干平替: Redis 的平替 Dragonfly Mongo 的平替 FerretDB Kafka 的平替 Redpanda 那就选定用Redpanda来搞,方法还是有一些曲折的: Redpanda 在 2025年5月16日这个节点,有5个版本 最新的25.1的版本,如果用docker compose来启动,是个压缩包,好多文件。 数据盘有三个了,而且用到了minio做后端的持久化卷,这么复杂,那不如直接搞Kafka了 那只能往前回退,选用24.2的版本,docker compose 就一个文件,不过这个版本 2025年7月31日就终结支持了。 下载的话:https://docs.redpanda.com/24.2/get-started/quick-start/ 我们要的是一个broker的,那直接给出源文件 name: redpanda-quickstart-one-broker networks: redpanda_network: driver: bridge volumes: redpanda-0: null services: redpanda-0: command: - redpanda - start - --kafka-addr internal://0.0.0.0:9092,external://0.0.0.0:19092 # Address the broker advertises to clients that connect to the Kafka API. # Use the internal addresses to connect to the Redpanda brokers' # from inside the same Docker network. # Use the external addresses to connect to the Redpanda brokers' # from outside the Docker network. - --advertise-kafka-addr internal://redpanda-0:9092,external://localhost:19092 - --pandaproxy-addr internal://0.0.0.0:8082,external://0.0.0.0:18082 # Address the broker advertises to clients that connect to the HTTP Proxy. - --advertise-pandaproxy-addr internal://redpanda-0:8082,external://localhost:18082 - --schema-registry-addr internal://0.0.0.0:8081,external://0.0.0.0:18081 # Redpanda brokers use the RPC API to communicate with each other internally. - --rpc-addr redpanda-0:33145 - --advertise-rpc-addr redpanda-0:33145 # Mode dev-container uses well-known configuration properties for development in containers. - --mode dev-container # Tells Seastar (the framework Redpanda uses under the hood) to use 1 core on the system. - --smp 1 - --default-log-level=info image: docker.redpanda.com/redpandadata/redpanda:v25.1.4 container_name: redpanda-0 volumes: - redpanda-0:/var/lib/redpanda/data networks: - redpanda_network ports: - 18081:18081 - 18082:18082 - 19092:19092 - 19644:9644 console: container_name: redpanda-console image: docker.redpanda.com/redpandadata/console:v3.1.0 networks: - redpanda_network entrypoint: /bin/sh command: -c 'echo "$$CONSOLE_CONFIG_FILE" > /tmp/config.yml; /app/console' environment: CONFIG_FILEPATH: /tmp/config.yml CONSOLE_CONFIG_FILE: | kafka: brokers: ["redpanda-0:9092"] schemaRegistry: enabled: true urls: ["http://redpanda-0:8081"] redpanda: adminApi: enabled: true urls: ["http://redpanda-0:9644"] ports: - 8080:8080 depends_on: - redpanda-0 仔细看了一下,这里面有问题,卷是空的,这可不行,必须持久化到本地,改一下 ...

2025年5月16日

Ubuntu 如何安装远程桌面RDP

非常郁闷的一件事。公司的网络架构非常有意思,灵活性极大。导致我这个总在公司之外用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 ...

2025年5月16日

mongodb 集群的恢复

要做一个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的以下地方: ...

2025年5月12日

mongodb 如何升级

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.*

2025年1月22日

AWS alb 负载均衡做ingress的注意事项

管理了一个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去了 ...

2025年1月20日

Mysql的某个表恢复到某一个时间点的操作

同事上线,把数据库初始化脚本改了名。结果导致上线把库表的数据全给重新初始化了。这下事来了,恢复库表。 之前用过阿里云的库表恢复,非常简洁,那这次也照猫画虎学一回,步骤如下: 一、保存现在的记录: 把所有相关的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 导出。 ...

2025年1月3日

设置Mysql自动定时删除xxljob的日志数据

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;

2024年3月20日

阿里云DMS管理数据库变更审批流

其实我们用的是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变更,数据变更默认审批模板的设置,我们改成我们自己的审批流即可 其他的选项都可以按需进行修改。 五、设置用户权限 如上审批流就完成了,我们要登录具体的实例列表,再更多里设置权限 注意上面是设置的实例级别的权限。 如果要设置更细级别的库、表、行权限,需要点击数据库列表 在这里面的表详情的右边更多,可以控制库、表、行的权限 这样就可以弄完整个流程了。

2024年3月5日

邮箱地址无效导致群发邮件失败

这个问题十分的讨厌啊,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

2024年3月4日