所有文章

Cross-Origin Resource Sharing (CORS) 跨域，一个网站引用了另外一个网站的资源，就需要跨域了。 最通俗点，就是服务器的返回头上要加上三行： Access-Control-Allow-Origin", "*" Access-Control-Allow-Methods", "GET, POST, OPTIONS" Access-Control-Allow-Headers", "DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization" 说白点：就是允许的来源站，允许的方法，允许的头信息 那在不同的地方配置又不相同： 一、Nginx server { add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS'; add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization'; 二、openresty中的lua脚本 location /pg/nginit { rewrite_by_lua_block { ngx.log(ngx.ERR, "Environment configuration update, about to get configuration information from redis") -- 添加跨域 CORS 头 ngx.header["Access-Control-Allow-Origin"] = "*" -- 允许所有域名请求 ngx.header["Access-Control-Allow-Methods"] = "GET, POST, OPTIONS" -- 允许的方法 ngx.header["Access-Control-Allow-Headers"] = "DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization" -- 允许的请求头 三、AWS的S3 <CORSConfiguration> <CORSRule> <AllowedOrigin>http://example.com</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <AllowedHeader>*</AllowedHeader> </CORSRule> </CORSConfiguration> 四、AWS Lambda 或者 API Gateway headers: { 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Credentials': true, } 最后，AWS的ALB不支持配置CORS！！！，必须在后端的 application 中设置。 ...

公司有两个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，其它保持缺省，然后建立 ...

公司的一个公网要搬到内网的一个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 仔细看了一下，这里面有问题，卷是空的，这可不行，必须持久化到本地，改一下 ...

非常郁闷的一件事。公司的网络架构非常有意思，灵活性极大。导致我这个总在公司之外用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变更，数据变更默认审批模板的设置，我们改成我们自己的审批流即可 其他的选项都可以按需进行修改。 五、设置用户权限 如上审批流就完成了，我们要登录具体的实例列表，再更多里设置权限 注意上面是设置的实例级别的权限。 如果要设置更细级别的库、表、行权限，需要点击数据库列表 在这里面的表详情的右边更多，可以控制库、表、行的权限 这样就可以弄完整个流程了。