Home » Posts tagged "lock"

AWS 推出了 S3 Object Lock,保護資料被刪除的可能性

AWS 推出了 S3 Object Lock,可以設定條件鎖住 S3 上的 object,以保護資料不被刪除:「AWS Announces Amazon S3 Object Lock in all AWS Regions」。


You can migrate workloads from existing write-once-read-many (WORM) systems into Amazon S3, and configure S3 Object Lock at the object- and bucket-levels to prevent object version deletions prior to pre-defined Retain Until Dates or Legal Hold Dates.

AWS 提供有兩種模式,一個是 Governance mode,這個模式下可以設定某些 IAM 權限可以移除 S3 Object Lock。另外一個是 Compliance mode,這個模式下連 root account 都不能刪除:

S3 Object Lock can be configured in one of two modes. When deployed in Governance mode, AWS accounts with specific IAM permissions are able to remove object locks from objects. If you require stronger immutability to comply with regulations, you can use Compliance Mode. In Compliance Mode, the protection cannot be removed by any user, including the root account.

Percona XtraDB Cluster 裡各種與 LOCK 相關的指令會產生的效果

在「FLUSH and LOCK Handling in Percona XtraDB Cluster」這邊看到在 Percona XtraDB Cluster 內各種不同形式的 LOCK 指令會有不同的效果。有些跟一開始用的印象已經不太一樣了...

FLUSH TABLE WITH READ LOCKFLUSH TABLE <tablename> (WITH READ LOCK|FOR EXPORT) 都會直接讓整個 node 卡住,但 LOCK TABLE <tablename> READ/WRITE 就只會卡對應的表格,另外 GET_LOCK 本來應該是完全不支援,現在似乎變成 experimental 的功能了 (參考「PXC Strict Mode」這邊),這樣一來 MogileFS 的資料庫部分就可以在上面跑了嗎?(當初就是因為這個問題而另外弄一組 DRBD + HeartbeatMySQL 起來跑 XD)



2013 的時候提過「加州的手機防竊提案...」,後來在 2015 年生效:

In a press release sent to reporters on Thursday, George Gascón said that since the law went into effect on July 1, 2015[,]


Such a kill switch has become standard in all iPhones ("Activation Lock") and Android phones ("Device Protection") since 2015.

而執行到現在已經兩年了,手機的失竊率下降不少:「San Francisco DA: Anti-theft law results in huge drop in stolen phones」。

[S]martphone-related robberies have fallen 22 percent from 2015 to 2016. When measured from the peak in 2013, "overall robberies involving smartphones have declined an astonishing 50 percent."


MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫:「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明:

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale,很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法,將 cache 放到 client 的效能比較好:

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了:「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話,透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。

Google 弄出來的 Grumpy:把 Python 2.7 的程式碼轉成 Go...

Google 放出 Grumpy,可以把 Python 2.7 的程式碼轉成 Go:「Grumpy: Go running Python!」。


This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)

回到原文,這次的需求主要是出自 YouTube 的需求:

The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.

然後 Python 的 GIL 又被拿出來鞭屍:

除了 C extension 不支援外,還是有些「過於動態」的語法不支援:

exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.

這樣可用的範圍少不少,這個專案可以當作 YouTube 這種規模的網站所做的改善,而不是什麼可以拿來用的工具 :o

關閉 MySQL 的 Query Cache

MySQL 的 Query Cache 是目前已知效能不好的主要因素之一 (global mutex lock 的緣故),在正式環境裡的 best practice 一般都是關閉,之前測過也是一開下去效能就會狂掉...

Percona 的人在討論要怎麼樣才能完全關閉 MySQL 的 Query Cache:「Is Your Query Cache Really Disabled?」,而他們發現只有在 query_cache_typequery_cache_size 都設為 0,而且重開 MySQL 才能完全避免 global mutex lock:

[W]e can see it is not possible to fully disable the query cache on the fly by changing query_cache_type or/and query_cache_size to 0. Based on the code and the tests, if you want to make sure the query cache is fully disabled, change query_cache_size and query_cache_type to 0 and restart MySQL.

應該是要再修正 my.cnf 的 template 了...

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue,難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue:「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做:

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題,就如同 Netflix 提到的:

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上:

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 RedisMemcached 的系統,可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」,也就是有可能會有多次的情況,用 Dyno Queues 系統的人必需要考慮進去:

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆,但實際看起來還是很厚重... 暫時還是不會用吧 :o

Composer 出現 lock file out of date 的解法

之前也有遇到,結果 Lorna Jane Mitchell 寫了一篇「Handling Composer "lock file out of date" Warning」給了不少解法。

第一種是 composer upgrade,直接全部升級。

第二種是先用 composer update --dry-run 看看是不是有人加到 composer.json 後忘記更新,如果是的話再用 composer update [package] 處理。

第三種是用 composer update nothing 閉上眼睛更新 hash 值,當作什麼都沒看到 XDDD

Sometimes this is the right answer so it's a handy trick to know!. I seem to see these kinds of issues in people's projects quite often (I'm a consultant, I see a lot of projects) so I thought I'd share my usual tactics for getting things sorted - if you have any tricks of your own to share, I'd love to hear them :)

該說很「實用」嗎 XDDD

Berkeley DB 的介紹

在滿滿都是 NoSQL 的世代中,意外在「Berkeley DB: Architecture」這邊看到 Berkeley DB 的介紹...

2006 年 Berkeley DB 的公司 SleepycatOracle 收購。在收購後 Oracle 改變了 open source 授權部份,從之前的 Sleepycat License 改成了 AGPLv3

Berkeley DB 算是早期功能很完整的 database library,由於 page level locking、crash-safe 加上有 transaction,也曾經被 MySQL 拿去當作 engine,不過在 MySQL 5.1 被拔掉:「14.5 The BDB (BerkeleyDB) Storage Engine」。

文章裡講了很多底層設計上的想法 (而非單純只說明「做了什麼」),以四個面向來討論。Buffer、Lock、Log 以及 Transaction,並且圍繞著 ACID 需求討論。

算是懷念的考古文?Google 弄出來的 LevelDBFacebook 接著改善的 RocksDB 的走向也不太一樣了,現在大家對 ACID 需求因為 NoSQL 盛行的關係又重新在檢視...

MySQL InnoDB 遇到 Deadlock 時的判讀

Percona 的「How to deal with MySQL deadlocks」這篇文章裡面提到了 MySQL InnoDB Deadlock 的判讀與處理。

在支援 transaction 的 engine 裡 deadlock 是不可避免的常態。

在 MySQL 5.5 以及之前的版本,可以透過 Percona 的 pt-deadlock-logger 這隻 script,每固定幾秒鐘就跑一次 SHOW ENGINE INNODB STATUS 記錄下來。在 MySQL 5.6 之後,可以直接使用 innodb_print_all_deadlocks 這個參數,遇到 deadlock 時就寫到 error log 裡。

有了 log 後,接下來就可以判讀 deadlock 的情況,得知是什麼樣的情況造成 deadlock。

文章最後面則是對減少 deadlock 的方法給了一些建議,都是比較一般性。一般還是要靠 bussiness logic 的分析來切割降低 deadlock 的情況。

不過這篇文章需要一些背景知識,像是 InnoDB Lock Modes 與維基百科上的「Multiple granularity locking」,對解讀會有更多幫助。