這是一張蠻特別的卡片，由加密貨幣交易所新創 crypto.com 發行。需要抵押 50 MCO（約新台幣 8,000）元六個月，即可取得一張「金屬」的 debit card。六個月後，可以把這 8,000 取回，可以直接刷卡花掉，或是透過 ATM 提領出來（國泰世華ATM不收手續費）。
我在 4 月申請的，因為疫情的關係，卡片五月中才到；但最近改用 DHL 寄送之後，通常兩三天就會到了。
到六月底為止，在家樂福（需用 line pay）、UberEats 消費，皆回饋 10%
你可以透過信用卡儲值（手續費1%）到卡片內，再透過卡片消費，或是將比特幣、以太幣換成法幣後再消費也可以。
如果透過我的連結申請 https://platinum.crypto.com/r/gbb3ut2h5g，當抵押完成後，我們雙方都可以獲得等值美金 50 元的 MCO 幣。你可以直接換成法幣然後在家樂福消費。
pt-stalk 是 Percona Toolkit for MySQL 裡面的其中一項工具。它會連到 MySQL Server，監控指定的數值，當超過指定的 Threshold 時，收集當時資料庫執行的資訊（包含正在進行的 transaction、vmstat、lsof，甚至 gdb stack trace），方便分析解決問題。
pt-stalk 需要以 root 權限執行。執行的方法如下：
pt-stalk --daemonize --variable Threads_connected --threshold 400 -- --defaults-file=/etc/mysql/my.cnf
當同時有 400 以上的 Threads 時，便會收集資料，存到 /var/lib/pt-stalk 內。收集的資料範例：
2014_01_13_00_25_09-df 2014_01_13_00_25_09-lock-waits 2014_01_13_00_25_09-netstat 2014_01_13_00_25_09-ps 2014_01_13_00_25_09-disk-space 2014_01_13_00_25_09-log_error 2014_01_13_00_25_09-netstat_s 2014_01_13_00_25_09-slabinfo 2014_01_13_00_25_09-diskstats 2014_01_13_00_25_09-lsof 2014_01_13_00_25_09-opentables1 2014_01_13_00_25_09-sysctl 2014_01_13_00_25_09-hostname 2014_01_13_00_25_09-meminfo 2014_01_13_00_25_09-opentables2 2014_01_13_00_25_09-top 2014_01_13_00_25_09-innodbstatus1 2014_01_13_00_25_09-mpstat 2014_01_13_00_25_09-output 2014_01_13_00_25_09-transactions 2014_01_13_00_25_09-innodbstatus2 2014_01_13_00_25_09-mpstat-overall 2014_01_13_00_25_09-pmap 2014_01_13_00_25_09-trigger 2014_01_13_00_25_09-interrupts 2014_01_13_00_25_09-mutex-status1 2014_01_13_00_25_09-processlist 2014_01_13_00_25_09-variables 2014_01_13_00_25_09-iostat 2014_01_13_00_25_09-mutex-status2 2014_01_13_00_25_09-procstat 2014_01_13_00_25_09-vmstat 2014_01_13_00_25_09-iostat-overall 2014_01_13_00_25_09-mysqladmin 2014_01_13_00_25_09-procvmstat 2014_01_13_00_25_09-vmstat-overall
然後看 InnoDB status，可以看到很多 transaction 正在等 query cache lock：
MySQL thread id 688253701, OS thread handle 0x7f6a591c9700, query id
19004545452 10.1.1.94 pixblog Waiting for query cache lock
SELECT * FROM `blogarticle` WHERE (`blogarticle_blogid` = 3835626) AND
(`blogarticle_date` < 1388605724) AND (`blogarticle_status` IN (2,3,5,7))
ORDER BY `blogarticle_date` desc, `blogarticle_id` desc LIMIT 1
---TRANSACTION 144B7B32FC, not started
MySQL thread id 688253702, OS thread handle 0x7f6a787bc700, query id
19004544621 10.1.1.191 pixblog Waiting for query cache lock
SELECT * FROM `blog` WHERE `blog_id` = 3126963
---TRANSACTION 144B7B32FD, not started
MySQL thread id 688253706, OS thread handle 0x7f6a887e2700, query id
19004544620 10.1.1.166 pixblog Waiting for query cache lock
SELECT * FROM `bloglayout` WHERE `bloglayout_id` = 3063007
---TRANSACTION 144B7B33C7, not started starting index read
mysql tables in use 1, locked 0
發生問題的當時確實有一個跑統計報表的 Slow Query 正在執行，於是要求該 Query 不使用 Query Cache1 來解決問題。
使用 IaaS 這類的服務，最方便的地方就是：當有緊急需求需要增加伺服器的時候，可以直接在網頁上點一點就完成增加的動作。但是，如果收到簡訊告警的時候，剛好在沒有網路的地方，就只好遠端電話遙控同事到網頁上操作，總覺得不是那麼方便。AWS 提供的 AutoScaling 服務，可以預先設定一些條件（例如 CPU 使用率超過多少，或是 Elastic Load Balance 的 Requests/sec 數量超過多少），當滿足這些條件時，自動增加（或減少）伺服器。原本這個功能只能透過 API 設定，今天終於有網頁版了…
使用 AutoScaling 網頁介面，除了可以開一般的 Instance 以外，還可以開 Spot Instance。對於需要大量運算資源，但是即時性要求不那麼高的服務來說，可以省下不少費用。
之前曾經提過 HandlerSocket – A NoSQL Plugin for MySQL，可以透過類似 NoSQL 的方式存取 InnoDB，效能會比普通 SQL 更好。後來 Oracle 在 MySQL 5.5 推出的時候，直接使用 Memcached Protocol，理論上應該是更方便（因為 Memcached Adapter 到處都有…）。
於是最近仔細的研究了一下，發現要使用 MySQL 5.5 的 InnoDB Memcached Plugin，要注意以下的地方：
innodb_memcache.containers 設定 key 與 column 的對應表。containers Table 裡面 name 為 default 的 Table。GET @@name 或 SET @@name 將之後的 Request 都切換到 name 這個 Table。
innodb_api_enable_binlog 這個值。大概重點就這些了，如果還有玩到別的再來補充。
先貼張圖：
我現在服務的公司 PIXNET 要徵求一名 System Administrator：
工作內容：
工作時間：9:30 ~ 18:30 (一～五)，特殊狀況時 (例如晚上處理緊急事件，或是凌晨停機等) 另外補休。
就職日：可馬上就職，或 2012 年二月到職即可。
地點：台北市中山區 (捷運行天宮站旁)，機房於台北市內湖區。
需求：熟悉 UNIX-like 系統，Script (Perl, Python 或 shell script 之一) 撰寫。熟 Cisco 網路設備操作者佳。
薪資：約 40k/month，其他技能面議另談。
有意者請聯絡 techjob@pixnet.tw。
根據 statcounter 的統計：
台灣則是在今年七月份就超過了：
於是有人在討論Google Chrome會不會是下一個IE6。配合之前 ppk 的擔憂：Mobile Safari 會不會是行動裝置上的 IE6?。
我倒是覺得 Web Developer 的堅持比以上的所有討論都重要的多。畢竟，寫出 IE only 網站的，並不是 Microsoft，而是不夠專業的開發者。
這是今年在 OSDC.TW 2011 上面分享的投影片：
根據 AWS Blog，AWS 開始提供使用者發送大量 Email 的服務 (Simple Email Service, SES)。價錢是每一萬封信 USD$1，流量費用另計。
要使用 SES 的服務是需要 Amazon 審核通過的，在未通過之前，收件者必須先使用 SES 的 API 認證過才能收到信，並且有一天最多寄出 200 封信的限制。審核通過後，任何收件者都能收到信，但是一開始一天最多只有 1000封信的Quota，隨著使用量與使用情形（例如Amazon有沒有收到 complain）而增加，最大一天可以寄出100萬封信。
另外寄信的速度也有限制。一開始是每秒鐘一封信，隨著使用狀況調整，最大可以到每秒鐘 90 封信。如果有一天寄出超過100萬封信的需求，可以向AWS提出調整要求。
另外，SES也可以整合進現有的Email Server裡面。（Postfix 範例）
