MySQL 的 audit log

在「Auditing login attempts in MySQL」這篇文章裡討論 MySQL 登入的 audit log,其中第一個方法是 full log (包含 SELECT 這類指令),看起來可以活用...

打開 General Query Log 後,幾乎所有的行為都會被記錄下來,照這個設計應該可以寫到 FIFO 裡丟到 log server 上?不知道會增加 log server 多少負荷...

使用 Percona Toolkit 管理 MySQL...

Percona 在前幾天辦了 Webniar 解釋 Percona Toolkit 要怎麼用 (並且宣傳有多好用 XD):「10 Percona Toolkit Tools Every MySQL DBA Should Know About」。

依照慣例,Percona 在結束後會把投影片與錄影整理後放出來 (也就是上面的連結),如果沒時間的話可以看投影片留個印象,有時間的話可以實際操作看看到底有多好用。

另外在 MySQL Performance Blog 上主講者也整理了 Q&A 的部份也很值得看一看:「Percona Toolkit Webinar followup Q&A」。

Wikipedia 把英文版資料庫的其中一個 slave 從 MySQL 5.1 換到 MariaDB 5.5...

維基百科的 mailing list 上丟出的消息,英文版 Wikipedia 資料庫的 slave server 目前已經在 MariaDB 5.5 上了:「mariadb 5.5 in production for english wikipedia」。

之前跑的版本是 MySQL 5.1 + Facebook patchset 版本,整體大約快了 8%:

Taking the times of 100% of all queries over regular sample windows, the average query time across all enwiki slave queries is about 8% faster with MariaDB vs. our production build of 5.1-fb. Some queries types are 10-15% faster, some are 3% slower, and nothing looks aberrant beyond those bounds. Overall throughput as measured by qps has generally been improved by 2-10%. I wouldn't draw any conclusions from this data yet, more is needed to filter out noise, but it's positive.

然後計畫在接下來一兩個月觀察,沒問題就全換:

MariaDB has some nice performance improvements that our workload doesn't really hit (better query optimization and index usage during joins, much better sub query support) but there are also some things, such as full utilization of the primary key embedded on the right of every secondary index that we can take advantage of (and improve our schema around) once prod is fully upgraded, hopefully over the next 1-2 months.

效能不是最主要考量,而是政治面的原因,官方說法是支持 open source 社群:(沒有講的就是「我們對 Oracle 不怎麼信任...」)

The main goal of migrating to MariaDB is not performance driven. More so, I think it's in WMF's and the open source communities interest to coalesce around the MariaDB Foundation as the best route to ensuring a truly open and well supported future for mysql derived database technology. Performance gains along the way are icing on the cake.

另外參考:「on wikipedia and mariadb」。

從 MySQL (單機) 轉到 Galera Cluster 的前置作業...

codership (Galera Cluster 背後的公司) 剛剛發了一篇文章,說明將 MySQL 轉換到 Galera Cluster 有哪些事情要先處理:「5 Tips for migrating your MySQL server to a Galera Cluster」。

純粹技術上的事情大致上是這樣:

  • 先轉到 InnoDB
  • 每個 Table 都加上 Primary Key。
  • 檢查 Event,確認在 Galera Cluster 裡面會怎麼跑,或是直接拆到 cron server 跑...

另外幾點不是技術上的問題,而是 policy 應該規劃的事情... 把事情列出來,多隻眼睛檢查後再一步一步照表操課。

PS:對於 Galera Cluster 不熟的人可以先去看官方網站以及 Percona 的說明,看不懂就不要用,這樣會比較安全...

Percona XtraDB Cluster (Galera Cluster) 的教學

Percona 將在台灣時間 9/20 清晨 (當地 9/19 10:00AM) 舉辦 Percona XtraDB Cluster (Galera Cluster) 的教學:「Upcoming Percona XtraDB Cluster – Installation and Setup webinar」。

這是偏向營運方面的 Web conference:除了安裝與設定以外,還準備試爆與修復,另外使用 HAProxy 達到 HA 目的... (我是偏好 Heartbeat + 自製的小 script 達到 HA)

有興趣的人可以報名,如果時間上不能配合的人,照慣例事後應該也有 video 與投影片可以看... (不是很確定)

PostgreSQL 9.2 出版...

PostgreSQL 9.2 放出來了:「PostgreSQL 9.2 released」。

其中一個重要的功能是直接支援 JSON 資料型態。之前看到「Building a MongoDB Clone in Postgres: Part 1」與「Building a MongoDB Clone in Postgres: Part 2」這兩篇,用 PostgreSQL 9.2 (當時還在 beta) 去堆 MongoDB 提供的功能。

另外一個對於效能會有幫助的新特性是 covering index,可以避免額外的 disk access。