JDBC

7 月 31 2020

MySQL 8.0.20 升級後記（踩 & 拆雷記）

續前一篇，這陣子除了表訂工作之外，就是觀察 MySQL 升級後有哪些地雷被引爆，接著開始救傷。

一顆跟 Java/JDBC 有關，錯誤訊息如下圖；原因是 MySQL 8 沒有 query_cache_size 等等的參數，而解決方式是更新 MySQL Connector/J。

另外一顆的成因/故事就比較長了…

MySQL 8 之前的版本，我們習慣把 character_set_server 設為 utf8 ，而 collation_server 設為 utf8_general_ci ；升版前看到這兩個變數預設值都換掉了，就很開心的拿掉… 於是部份（年紀比較大）的 PHP web server 就爆了，錯誤訊息如下圖。

初步研判以為是 PHP 認不得 utf8mb4 ，仔細追查後發現真因是「認不得 utf8mb4_0900_ai_ci」，解決方式是把 collation_server 設為 utf8mb4_general_ci 。

附帶一提， PHP 5.3 的 ext/mysqlnd 沒這問題，僅 5.4 ~ 5.6 受影響，而 PHP 7 之後都支援 UCA Ver.9 的 collations …

By • , , 0 • Tags: , , , , , , ,

7 月 24 2019

Logstash 筆記

為了分析某些儲存在 MySQL 的 log，敝單位在兩年前（2017）導入 Logstash；當時我們用最新的 5.5.1 版，運作狀況還不錯，所以就沒什麼人理它…
最近冒出問題，救完火後寫個紀錄。

第一個問題是這個：

[WARN ][logstash.inputs.jdbc ] Exception when executing JDBC query {:exception=>#<Sequel::DatabaseError: Java::ComMysqlJdbcExceptionsJdbc4::MySQLDataException: ‘2.147483727E9’ in column ‘1’ is outside valid range for the datatype INTEGER.>}

資料的第一個欄位是 auto-increment 的 ID，看到 ‘2.147483727E9’ 就聯想到是 32 位元正整數溢位問題。
我們先換 MySQL Connector/J （& 改用 OpenJDK）；換完之後，看到的錯誤訊息變成這樣：

[WARN ][logstash.inputs.jdbc ] Exception when executing JDBC query {:exception=>#<Sequel::DatabaseError: Java::JavaSql::SQLDataException: Value ‘2147483727’ is outside of valid range for type java.lang.Integer>}

於是我們就開始升版 Logstash；目前最新的版本是 7.2.0，但 官方的 migration guide 說要先升版到 6.7。
最後我們順利升上 7.2.0，在過程中也發現 6.7.2 已無 32 位元正整數溢位問題。

第二個問題發生在升版後：
DATETIME 欄位存放的 ‘2019-07-23 14:18:59’ 抓成 ‘2019-07-23T19:18:59.000Z’。
沒人能保證系統/伺服器會跨多少時區，為免夜長夢多，我們的解決方式是轉成 UNIX timestamp。
（Year 2038 problem？ 以後再說！ XD ）

By • 0 • Tags: , ,