Eventbrite 的 MySQL 升級計畫

在 2021 年看到 EventbiteMySQL 升級計畫:「MySQL High Availability at Eventbrite」。

看起來是 2019 年年初的時候 MySQL 5.1 出問題,後續決定安排升級,在 2019 年年中把系統升級到 MySQL 5.7 (Percona Server 版本):

Our first major hurdle was to get current with our version of MySQL. In July, 2019 we completed the MySQL 5.1 to MySQL 5.7 (v5.7.19-17-log Percona Server to be precise) upgrade across all MySQL instances.

然後看起來是直接在 EC2 上跑,不過這邊提到的空間問題就不太確定了,是真的把 EBS 的空間上限用完嗎?比較常使用的 gp2gp3 上限都是 16TB,不確定是不是真的用到接近爆掉了:

Not only was support for MySQL 5.1 at End-of-Life (more than 5 years ago) but our MySQL 5.1 instances on EC2/AWS had limited storage and we were scheduled to run out of space at the end of July. Our backs were up against the wall and we had to deliver!

另外在升級到 5.7 的時候,順便把本來是 INT 的 primary key 都換成 BIGINT

As part of the cut-over to MySQL 5.7, we also took the opportunity to bake in a number of improvements. We converted all primary key columns from INT to BIGINT to prevent hitting MAX value.

然後系統因為舊版的 Django 沒辦法配合 MySQL 5.7,得升級到 Django 1.6 (要注意 Django 1 系列的最新版是 1.11,看起來光是升級到 1.6 勉強會動就升不上去了?):

In parallel with the MySQL 5.7 upgrade we also Upgraded Django to 1.6 due a behavioral change in MySQL 5.7 related to how transactions/commits were handled for SELECT statements. This behavior change was resulting in errors with older version of Python/Django running on MySQL 5.7

然後採用了 GitHub 家研發的 gh-ost 當作改變 schema 的工具:

In December 2019, the Eventbrite DBRE successfully implemented a table ALTER via gh-ost on one of our larger MySQL tables.

看起來主要的原因是有遇到 pt-online-schema-change 的限制 (在「GitHub 發展出來的 ALTER TABLE 方式」這邊有提到):

Eventbrite had traditionally used pt-online-schema-change (pt-osc) to ALTER MySQL tables in production. pt-osc uses MySQL triggers to move data from the original to the “duplicate” table which is a very expensive operation and can cause replication lag. Matter of fact, it had directly resulted in several outages in H1 of 2019 due to replication lag or breakage.

另外一個引入的技術是 Orchestrator,看起來是先跟 HAProxy 搭配,不過他們打算要再換到 ProxySQL

Next on the list was implementing improvements to MySQL high availability and automatic failover using Orchestrator. In February of 2020 we implemented a new HAProxy layer in front of all DB clusters and we released Orchestrator to production!

Orchestrator can successfully detect the primary failure and promote a new primary. The goal was to implement Orchestrator with HAProxy first and then eventually move to Orchestrator with ProxySQL.

然後最後題到了 Square 研發的 Shift,把 gh-ost 包裝起來變成有個 web UI 可以操作:

2021 還可以看到這類文章還蠻有趣的...

GitHub 拿掉所有非必要的 Cookie 了

GitHub 家的老大宣佈拿掉 cookie banner 了,因為他們直接把所有非必要的 cookie 都拿掉了:「No cookie for you」。

會有 cookie banner 主要是因為歐盟的規定:

Well, EU law requires you to use cookie banners if your website contains cookies that are not required for it to work. Common examples of such cookies are those used by third-party analytics, tracking, and advertising services. These services collect information about people’s behavior across the web, store it in their databases, and can use it to serve personalized ads.

然後他們的解法是拔掉:

At GitHub, we want to protect developer privacy, and we find cookie banners quite irritating, so we decided to look for a solution. After a brief search, we found one: just don’t use any non-essential cookies. Pretty simple, really. ?

是個「解決製造問題的人」的解法 XDDD (但是是褒意)

GitHub 的 Dark Mode 辨識度太低的問題

GitHub 推出 Dark Mode 後我就馬上切過去,但用了兩天後覺得辨識度太差就換回來了,剛剛在 Hacker News Daily 上看到不只我抱怨這個問題:「GitHub Dark Mode is Too Dark」,在 Hacker News 上的討論也可以翻翻:「 GitHub Dark Mode is too Dark (karenying.com)」。

裡面分析了 SpotifyFacebookYouTube 以及 GitHub 的配色盤,然後算出對比度,可以看到 GitHub 的配色上的確是差了不少...

目前 GitHub 上的 Theme 功能是掛 beta,應該還是有機會改,看看會不會修的好一點...

youtube-dl 的恢復與後續 GitHub 的處理模式

youtube-dl 被下架的事情後續又有不少進展了 (先前寫過「youtube-dl 被 RIAA 用 DMCA 打下來的事件」這篇),主要是 GitHub 恢復了 youtube-dl 的 Git Repository,然後丟出了一篇文章解釋過程,以及後續的作法:「Standing up for developers: youtube-dl is back」。

要注意這次的事件完全是法律戰,所以裡面發生的敘述都是各自的說法,大家可以自己解讀...

GitHub 的這篇文章是由 Abby Vollmer 發表的,從 LinkedIn 上的資料也可以看到他以前的經歷都是法律相關,現在在 GitHub 的頭銜是「Director of Platform Policy and Counsel」,而這篇的用字也可以看出來很小心。

首先 GitHub 認為下架的原因是 Section 1201:

Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.

而 GitHub 後續恢復 youtube-dl 的原因是收到 EFF 代表 youtube-dl 開發者所做的 counter notice:「2020-11-16-RIAA-reversal-effletter.pdf」。

照以往這種把事情搞超大的慣例,RIAA 應該是不會有後續的動作,所以就 youtube-dl 這件事情來說應該是差不多告一段落。

GitHub 後續針對 Section 1201 提出了兩個改善措施,一個是重新設計 Section 1201 的處理方式,另外一個是 GitHub 自己投入資金,降低 developer 的負擔。

但整件事情背後的問題主要是在 DMCA 的設計,讓濫發 takedown notice 的人很難受罰,在這點沒有改善之前,同樣的劇碼應該都還是會繼續上演。

youtube-dl 被 RIAA 用 DMCA 打下來的事件

youtube-dl 的這件事情的後續影響意外的大 (引發了 Streisand effect),除了這算是 RIAA 的最新力作以外,還發生了好幾個首次出現的過程 (而且有些事情還在進行),值得花一些時間挑出幾個比較有趣的地方記錄。

在英文版維基百科的「youtube-dl」與中文版維基百科的「youtube-dl」上面也陸陸續續把發生的經過都記錄起來了,有興趣的人也可以去看看。

RIAA 的動作不算太意外,比較特別的是這次的 takedown notice 不是常見的 DMCA 512 侵權宣告,而是宣稱 youtube-dl 故意繞過 YouTube 的「保護機制」的工具:「The RIAA’s fraudulent attack on youtube-dl is not a DMCA §512 infringement/safe-harbour, and the reality is weird」,除了本身的文件以外,大家發現在 test case 裡面試著下載 YouTube 上的版權影片也可能是個明顯的問題。

另外是 GitHub 現在的 CEO,Nat Friedman,親自跑到 youtube-dl 的 IRC 上面「討論」後續可能的作法,這點也是讓大家愣住的地方:「RIAA’s YouTube-DL Takedown Ticks Off Developers and GitHub’s CEO」。

不過最近 GitHub 又警告了使用者不要重新上傳 youtube-dl 的程式碼,這有可能會被 ban XDDD:「GitHub Warns Users Reposting YouTube-DL They Could Be Banned」,對應的修改在「add statement about reposting and tos violating content」這邊。

這齣戲還在演...

用 GitHub Actions 記錄 API 資料的變化

Hacker News Daily 上看到的方式,Simon Willison 利用了 GitHub Actions 定時去抓資料更新 git repository:「Git scraping: track changes over time by scraping to a Git repository」。

文章裡面測試了 JSON 檔案的變化:

這個方式利用了 GitHub 自家的架構做完所有的事情,因為他的範例是拉加州政府的資料,感覺 g0v 裡應該有些專案也用這個方式搞,翻了一下 Telegram 上的記錄,果然翻到記錄了:「零營運費用開源開發」。

另外我猜用 free-for.dev 這邊的資源應該也有機會堆出類似的東西...

GitHub 擴大免費版功能,以及付費版降價

GitHub 宣佈了提昇免費版的功能,以及付費版的降價消息:「GitHub is now free for teams」。

昨天是這樣:(從這邊撈的,然後發現好像有人寫了個機器人,每天都叫 web.archive.org 去撈一份...)

現在變成:

本來付費的個人方案 (Pro) 的功能都直接下放到免費版本了,而一般公司用的 Team 版本從 $9/m/user 降到 $4/m/user。有個富爸爸之後就可以任性...

GitHub 推出自己的 CI/CD 方案

GitHub 推出自家的 CI/CD 方案:「GitHub Actions now supports CI/CD, free for public repositories」。

這個功能是搭在 GitHub Actions 下面的功能,目前支援的語言還是以熱門的為主:

GitHub Actions now makes it easier to automate how you build, test, and deploy your projects on any platform, including Linux, macOS, and Windows. Run your workflows in a container or in a virtual machine. Actions also supports more languages and frameworks than ever, including Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android, and iOS. Testing multi-container apps? You can now test your web service and its database together by simply adding some docker-compose to your workflow file.

公開的 Repository 可以直接用,私人的 Repository 則是每個月有 2000 分鐘 (Free)、3000 分鐘 (Pro)、10000 分鐘 (Team) 以及 50000 分鐘 (Enterprise) 的額度可以用,另外超過的部份則是另外以分計費,換算成小時的話是 USD$0.48/hr (Linux)、USD$0.96/hr (Windows) 與 USD$4.8/hr (Mac)。

不過還是得等:

We’re excited to make this new version of Actions available. Learn more and sign up for the beta, which is free now until we make Actions generally available at GitHub Universe on November 13.

CD 的部份主要因為會跟架構有關,衝擊應該還好,但可以預期現有一堆 CI 服務應該會很辛苦了...