初心易得,始終難守
C'est la vie.© 2002 - 2026
  • 我是誰-Who Am I
  • 我在哪-Where Am I
  • 我是什麼-What Am I
  • 年鑑-YearBook
    • 二零零六年终总结
    • 一吻定情—二零零八年年终总结
    • 突如其来的明天—二零零九年年终总结
    • 人生大起大落得太快——二零一零年年终总结
    • 贰零①①年年终总结-女朋友已经成家了
    • 贰零壹贰年年终总结-奔波的肿瘤
    • 贰零壹叁年年终总结
    • 雪字怎么写-贰零壹肆年年终总结
    • 每个不曾表白的今天,都是对青春的亏欠-贰零壹伍年年终总结
    • 按部就班的IT 人生-貳零貳肆年年終總結
  • 連結
RSS
11 月 30 日, 2025 年

吵吵鬧鬧的亞細亞

Ken 随笔 0 Comments

香港大火的死亡人數看起來至少會超過200人,可能會超過300人,要是港英當局執政,恐怕是共產黨的 “群眾”早就已經上街遊行示威了。

竹子究竟易燃不易燃?

這個問題很簡單,竹子生長迅速,有些地方甚至竹滿為患,要定期砍伐以免其繼續擴張,要是易燃早就拿來當柴火用了,沒有被拿來當柴火,你說他易燃還是不易燃?

香港人可憐不可憐?但也不是沒有清醒的人,新聞里講有一戶人家的阿婆,兒子移民英國,老公也跟著兒子在英國,自己一個人住在樓里,這就怨不得別人了。

但總歸不是所有香港人都能移民英國,大多數底層的民眾什麼也不會,就圖一個混吃等死,其實蠻適合社會主義的。

香港以肉眼可見的方式衰敗,也是早有定論的事情,所以並不見得大家有多驚訝,只是這麼多人命,也沒有人要為此負責。

高市早苗步步為營,目的就是要跳脫自衛隊的框架,我看貴國這次怕是中計了,罵得那麼厲害,以為高市早苗會在壓力下下台,沒有想到支持度不減反增。

同事們紛紛下訂了日本的機票和住宿,準備去滑雪,我倒是對雪沒有什麼特別的興趣。

壽司郎的壽司品質不穩定,鮭魚和鮪魚都不穩定,常常會有帶筋咬不動的部分,肉質也不完全一樣,不過這是可以理解的,不是每條魚都長得一樣。

11 月 25 日, 2025 年

從地端 Redis server / Redis cluster 遷移到 雲端 ElastiCache 的四種方式

Ken Tech 0 Comments

通常redis 是用來做cache ,但是隨著各種應用野蠻而自由的發展,或者說濫用,redis 現在已經快要變成一個存儲everything 的database,比如wordpress 的object-cache plugin 就會把所有的posts 都丟進去,很多的遊戲廠商則有頻繁刷新的board/score ,以及各種遊戲人物的屬性。

對雲端平台而言,以AWS 為例,從地端遷移redis 大概有這樣四種方式:

  1. rdb 文件從地端server dump 出來,上傳到S3,然後再從ElastiCache 服務來調用S3 上的rdb 文件進行恢復。
  2. ElastiCache 提供了在線遷移的方式,雖然官方文件上說支持在EC2 上架設的redis server,但實際上,只要你的網速夠快,你的redis 在哪裡都沒所謂,只要是自建的redis server 都可以,或者是支持CONFIG/SYNC/PSYNC/SLAVEOF 命令的第三方服務商。
  3. RIOT 是redis 官方推出的工具,大概是遷移需求實在是呼聲太高,而總是使用第三方的工具來遷移,似乎顯得redis 官方不作為。
  4. 開源的 redis-shake ,在實時同步方面被廣泛採用。這個工具需要調用源端的 sync/psync 命令,而這些命令在AWS/Azure/GCP 中都是被禁用的,如果源在雲端,則需要開立技術支持工單來啟用他們之後,才可以使用redis-shake。
這一篇很長,Read more
11 月 22 日, 2025 年

AWS VPC 网络中基于 keepalived 的主备切换

Ken Tech 0 Comments

雲端並沒有什麼場景一定需要用keepalived,只不過是一些傳統企業地端思維揮之不去,當然,ELB 要花錢,省錢也是重要的因素,特別是業務沒有那麼重要,卻就是需要HA。

但是,AWS VPC 並不支持VRRP multicast,這讓很多在地端運行的商業 Firewall/LB 廠商上雲之後都要做修改,比如F5/Radware/A10/深信服 等等,然而,並沒有官方文件說明AWS VPC 支持或是不支持,官方blog 文章在某種程度上可以視作你可以自己做,但是我們不會為你進行官方的技術支持,可就是有人看不懂。

當然,官方blog 語焉不詳也是一個問題,SA們寫出許多不在官方支持範圍內但又可以在AWS 平台上運行的blog,但他們又沒有講得很清楚,你不去理解blog 而是完全照著去做,是會失敗的。

這一篇很長,Read more
11 月 17 日, 2025 年

中小企業如何出海-從中國境內流暢的訪問美國網路

Ken Tech 0 Comments

眾所周知中國的經濟依賴於基建和外貿,比如修到圖博的高鐵和出口到NewYork 醜陋的Labubu。

在這期間眾多的中小企業在Amazon,Tiktok 上開店,如何從中國境內流暢的訪問美國網路,就成為一個很重要的課題。

這些開店多年的商戶,有如下的選擇:

1)使用所謂的“電信海外加速寬帶”,使用CN2,擁有出海的優勢。但是,这个服务只在少数的地区提供,例如上海。
2)直接使用相對昂貴的香港運營商漫遊來更新商品清單以及使用WhatsApp 和海外的分銷商聯繫。
3)使用一些公司提供的國際加速SD-WAN,我一直不清楚他們的運營模式,應該是有後台才對。他們會部署一台設備在本地,並進行流量分流( 是不是聽起來就很像openwrt 裝個plugin )。
4)自建openvpn,這就是我今天想要說的坑。

在擁有shadowsocks/v2ray/wireguard/ipsec 的今天,幾乎沒有人會使用openvpn 來做這件事情,因為大概十年前他就不能穿越GFW了,但是,總是有一些曾經在中國境內大規模部署openvpn 的客戶,以為可以順利的穿越GFW。

畢竟,當你在10個省份的辦事處都部署了免費的openvpn 並且已經運行了數年之久,和那些買了深信服SSL-VPN 設備的公司比起來你為公司省下了不止一百萬人民幣的費用,你絕對不會以為你的配置有問題。

或許,這些客戶的想法是:“我使用的是正規的openvpn ,又不是翻牆工具,怎麼會有問題呢。”

問題不在於你使用的工具是不是正規,問題在於他可以達成什麼樣的目的。

吶,一個問題供思考,openvpn 的官方網站 https://openvpn.net/ 在中國可以訪問嗎?

大概是從2021年起,限流成為GFW 使用的最重要手段,我想這代表著GFW 的數據處理能力上了一個新台階,因為比起來,似乎發送一個RST 更簡單,更省資源才對吧?

現在,GFW 通常會將第一次建立連接的加密流量 進行極端限流,然後當你發現慢慢的,沒速度了,斷開嘗試第二次連接的時候,你就會發現無法建立連接,無論你是從中國境內向境外發起連接,還是從中國境外向境內發起連接,WireGuard 也會遇到相同的情形,而IPSec 則是驗證失敗,即使密鑰和加密算法沒有問題,雖然有人認為是GFW 識別出了他們的協議特徵,但是識別特徵是一個很耗費資源的事情,而對不能快速識別的加密流量進行限流,則是一個通用的方式,無論是shadowsocks/v2ray/wireguard/ipsec 還是openvpn。

這個問題我在大約十年前使用openvpn 的時候就已經發現,一度讓我懷疑我的智商,因為那個時候shadowsocks 還沒有經過歷史的考驗,我並不相信任何一個新的工具,我預估所有新出現的工具都是有後門和風險的。

在第一次遇到這個問題的時候,你沒有辦法將他和GFW 聯繫起來,但那個時候對於openvpn 是直接進行阻斷,會收到RST ,和現在的表現很像但又略有不同,看起來像是openvpn 建立連接的時候送出的證書被檢測到,理論上來說是可以看到證書內容的,但隨機化證書的內容並不能改善這個情況。

然而,如同一些研究⬇︎人員指出的,GFW 對流量的檢測和阻斷並不是廣泛針對所有的境外IP地址,而是一些熱門的雲服務商,例如AWS,Azure,GCP,Linode,DigitalOcean,Vultr 等等。

當然,還是有很多方法是可以穿越GFW 的,

比如v2ray+websocket+tls+CDN,取決於你到CDN 的速度。

比如ipsec+GRE,能用就是慢了點。

比如還有一些我沒試過的方法,我想其中應該也是有可用的方案:https://guide.v2fly.org/advanced/advanced.html

只不過大多數人都只會使用一鍵安裝包。

其實最簡單的方式是,你只要使用一些不熱門的雲服務就可以了,只要足夠冷門,上面的協議都可以使用。

至於一直提供CN2 線路的搬瓦工 https://bandwagonhost.com/ , 擁有優秀的美中跨境能力,讓人不得不懷疑他背後的資本組成,特別是在美國註銷中國電信美洲公司和中國聯通美洲公司在美國的運營執照之后。

當然,GFW 的一切行為都是黑箱,我們都只能猜測到底發生了什麼。

對於大公司來說,直接使用跨境專線,通過中國電信和中國聯通的正規路徑出海,也是一個不錯的選擇,貴是貴了點。


參考文件:中國的防火長城是如何檢測和封鎖完全加密流量的 – https://gfw.report/publications/usenixsecurity23/zh/

11 月 14 日, 2025 年

mysql-server v8.0 升級v8.4 的bug – [ERROR] [MY-013379] [Server] Server upgrade started with version 80400, but server upgrade of version 80044 is still pending.

Ken Tech 0 Comments

以前mysql-server 升級都很簡單,先升級binary 然後手動進去mysql_upgrade,現在他改成自動upgrade ,反而產生了很多問題:

bug https://bugs.mysql.com/bug.php?id=96696

Home server 上的docker container 裡面有一個mysql-server 用來給zabbix 和grafana 使用,因為最近很多雲端服務商都提醒升級到 v8.4 ,因為v8.0 在2026年4月要EOL。

然後我就想來升級一下,理應是一個很簡單的步驟,不就是改一下tag ,重新pull image,自動 upgrade 不就好了嗎?然後他就卡住了,一直在upgrade 的地方loopback。

既然卡住了,我想可以起一個臨時的container 然後手動來執行mysql_upgrade,然後發現這個command 已經在新的image中被刪掉了。

然後我又想,是不是從v8.0.44 到v8.4.7 跨度太大?改成v8.4.0 的tag 試試,還是卡住:

docker logs -f mysql-temp
2025-11-14 01:17:04+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.0-1.el9 started.
2025-11-14 01:17:04+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-11-14 01:17:04+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.0-1.el9 started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2025-11-14T01:17:05.064977Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-11-14T01:17:05.323886Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.0) starting as process 1
2025-11-14T01:17:05.338396Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-11-14T01:17:05.737981Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-11-14T01:17:05.753945Z 1 [ERROR] [MY-013379] [Server] Server upgrade started with version 80400, but server upgrade of version 80044 is still pending.
2025-11-14T01:17:05.754547Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2025-11-14T01:17:05.754608Z 0 [ERROR] [MY-010119] [Server] Aborting
2025-11-14T01:17:06.284102Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.4.0)  MySQL Community Server - GPL.
2025-11-14T01:17:06.284134Z 0 [System] [MY-015016] [Server] MySQL Server - end.

檢索了一下,這是個bug https://bugs.mysql.com/bug.php?id=96696

根據這個bug 的說明,解決方法如下:

使用 --upgrade=MINIMAL 啟動一個臨時的container, 看起來可以啟動:

docker run -d --name mysql-temp \
  -v /mnt/APP/mysql-server-data:/var/lib/mysql \
  mysql:8.4 --upgrade=MINIMAL

13fb5f920e59c49dee18b5966a983572f18c4bcd0f3740c53489b5871b2dcb5a
root@truenas[/mnt/APP/mysql-server-data]# docker logs mysql-temp
2025-11-14 01:21:45+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.7-1.el9 started.
2025-11-14 01:21:46+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-11-14 01:21:46+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.7-1.el9 started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2025-11-14T01:21:46.486026Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-11-14T01:21:46.767991Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.7) starting as process 1
2025-11-14T01:21:46.786566Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-11-14T01:21:47.098789Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-11-14T01:21:48.674335Z 0 [Warning] [MY-013378] [Server] Server upgrade is required, but skipped by command line option '--upgrade=MINIMAL'.

InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 1002025-11-14T01:21:51.271019Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2025-11-14T01:21:51.271083Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2025-11-14T01:21:51.275790Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2025-11-14T01:21:51.331885Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.4.7'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.
2025-11-14T01:21:51.332177Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock

然後,

  1. SET GLOBAL innodb_fast_shutdown = 0;
    設置 InnoDB 完全關閉模式,確保所有dirty page 都寫入磁盤,不會有數據丟失。
  2. FLUSH TABLES WITH READ LOCK;
    刷新所有表到磁盤,對所有表加讀鎖,防止寫入操作。
  3. UNLOCK TABLES;
    釋放表鎖。
docker exec mysql-temp mysql -uYOU-USER-NAME -pYOUR-PASSWORD -e "
SET GLOBAL innodb_fast_shutdown = 0;
FLUSH TABLES WITH READ LOCK;
UNLOCK TABLES;"
mysql: [Warning] Using a password on the command line interface can be insecure.

重啟試試:

ocker run -d --name mysql-temp \
  -v /mnt/APP/mysql-server-data:/var/lib/mysql \
  mysql:8.4
9388c2b2f4bcf09ae2a63c73e81d7f796faf4273b94ed00aa66ebeb98559c921
root@truenas[/mnt/APP/mysql-server-data]# docker logs -f mysql-temp
2025-11-14 01:23:11+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.7-1.el9 started.
2025-11-14 01:23:12+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-11-14 01:23:12+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.7-1.el9 started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2025-11-14T01:23:12.698238Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-11-14T01:23:12.952908Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.7) starting as process 1
2025-11-14T01:23:12.967501Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-11-14T01:23:13.281082Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-11-14T01:23:14.582439Z 4 [System] [MY-013381] [Server] Server upgrade from '80044' to '80407' started.
2025-11-14T01:23:20.682007Z 4 [System] [MY-013381] [Server] Server upgrade from '80044' to '80407' completed.
2025-11-14T01:23:20.872102Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2025-11-14T01:23:20.872183Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2025-11-14T01:23:20.876381Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2025-11-14T01:23:20.906537Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2025-11-14T01:23:20.906596Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.4.7'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.


root@truenas[/mnt/APP/mysql-server-data]# docker exec mysql-temp mysql -uYOU-USER-NAME -pYOUR-PASSWORD -e "SELECT VERSION();"
mysql: [Warning] Using a password on the command line interface can be insecure.
VERSION()
8.4.7

看起來升級完成了:

2025-11-14T01:23:14.582439Z 4 [System] [MY-013381] [Server] Server upgrade from ‘80044’ to ‘80407’ started.
2025-11-14T01:23:20.682007Z 4 [System] [MY-013381] [Server] Server upgrade from ‘80044’ to ‘80407’ completed.

‹ 1 2 3 4›»

過 客

  1. R2 on 卷進了美商5 月 15 日, 2024 年

    终于回来了,好。

  2. Ken on Mommy最後的樣子11 月 6 日, 2023 年

    也沒有很久吧,最近終於閒下來

  3. R2 on Mommy最後的樣子10 月 26 日, 2023 年

    好久不见

  4. Ken on 天朝Loli控组曲(带歌词,修正版)10 月 12 日, 2023 年

    哈哈哈,祝福你,好人一生平安

  5. liu on 天朝Loli控组曲(带歌词,修正版)10 月 12 日, 2023 年

    hello,我在找天朝lolicon组曲时发现了你的博客,感谢你十四年前做出的贡献,祝一切安好

December 2025
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031  
« Nov    

Spam Blocked

101,956 spam blocked by Akismet

↑

© 初心易得,始終難守 2025
Powered by WordPress • Themify WordPress Themes