Tag: migration

一路從 MySQL 5.5 升級到 MySQL 8.0 的故事...

在「Migrating to MySQL 8.0 without breaking old application」這邊看到這個有趣的故事 XD 這是作者的應用程式 Drupal 從 MySQL 5.5 一路升級到 8.0 的過程記錄...

真正的問題發生在 5.7 到 8.0：

原因是 Drupal 用到關鍵字了：

In fact, this old Drupal, uses a table name that is now part of the reserved keywords. It’s always advised to verify what are the new keywords reserved for MySQL itself. New features can also mean new keywords sometimes.

修正後就好了：

話說依照「File:Drupal release timeline.png」這邊的資訊，Drupal 6.2 也十年左右了？應該是 PDO 剛開始要推廣的年代，不知道他跑哪個版本的 PHP...

另外 MySQL 的升級意外的順利？雖然是一步一步升，但沒遇到什麼大問題...

Microsoft 虛擬化的兩個消息：Azure 被打臉以及 AWS 推出轉移工具

首先是 VMware 發文打臉 Microsoft 說他們所宣稱的轉移工具 (從 VMware 轉到 Azure 上) 並沒有 VMware 原廠支援：「VMware – The Platform of Choice in the Cloud」。

然後 AWS 則是推出了從 Hyper-V 轉移到 AWS 的工具：「Migrate Hyper-V VMs to AWS with AWS Server Migration Service」，這邊倒是沒提到官方支援...

這臉不只是腫腫的而已了，有種連續技的感覺 XD

AWS 推出將 Classic Load Balancer 轉換成 Application Load Balancer 或 Network Load Balancer 的功能

AWS 應該是希望大家趕快把能換的 ELB 都換成新的 ALB 與 NLB，所以推出這個功能：「New One-step Migration Wizard to Migrate a Classic Load Balancer」。

Today, AWS announced the ability to migrate from a Classic Load Balancer to an Application Load Balancer or a Network Load Balancer in one step using a console-based migration wizard.

不過 ELB 有一些功能是目前 ALB 與 NLB 沒有的，像是一般性的 SSL offload (而非 HTTPS offload)，以及舊客戶會有的 EC2-Classic：

不知道這兩個問題之後會推出什麼樣的方案解決...

從 Cassandra 到 ScyllaDB 的轉移方式好像跟以前不太一樣了...

在「New Docs: Four Phases to Migrate from Apache Cassandra to Scylla」這邊看到 ScyllaDB 官方提供 Cassandra 轉移到 ScyllaDB 的說明，跟以前好像差蠻多的...

以前 ScyllaDB 可以直接加入到 Cassandra 的 cluster (一時間沒找到資料，但在「can not add node with cassandra ami · Issue #107 · scylladb/scylla-cluster-tests」可以看到當時的痕跡)，現在給的方法是在資料庫不相容時的轉移方式 (像是從 MySQL 轉換到 PostgreSQL 這種)，是暗示已經沒辦法這樣做了嗎？

不過從 GitHub 上的 wiki page 看起來，底層資料與 protocol 應該還是相容的，才能做直接複製資料的 offline migration：「Migrating Cassandra data to Scylla」。

也有可能這篇只是寫手隨意寫的文章，沒有把 ScyllaDB 的優勢展現出來...

About John Hammink
John Hammink is a writer and content creator at ScyllaDB. With more than 20 years in technology, he's also a touring/studio musician, digital artist and speaker.

Dropbox 的 IPv6 轉移過程

Dropbox 描述了他們目前將整個服務轉移到 IPv6 的過程 (看起來是進行式，而不是完成式)：「Deploying IPv6 in Dropbox Edge Network」。

看到比較有趣的是這幾幾張圖：

IPv6 request percentage across all Dropbox services

IPv6 request percentage increased as we enabled IPv6 for more services

Countries ranked by IPv6 Request Percentage

差不多有 1/6 的量了，這樣其實不算少，是個開始...

Netflix 對 Landing Page 的效能改善計畫...

幹掉 React (噗)：

官方帳號丟戰文出來... 後面就有人開始亂 XDDD

不過先拉回來看... 依照說明，其他頁面都還是跑 React，只有 Landing Page 被改寫，看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI，所以就被拿出來另外處理了...

當然也有可能有其他的陰謀論 (而且我覺得可能性是在的)：因為之前 React 的專利問題，變成之後 Facebook 如果真的出手提出告訴，會以惡意侵權來告 (因為鬧這麼大以後，沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗)，後續再換內頁...

Yandex.Mail 從 Oracle 搬移到 PostgreSQL 上的故事

在 Hacker News Daily 上看到 Yandex.Mail 從 Oracle 搬到 PostgreSQL 的故事：「Yandex.Mail success story」。

首先是在 Oracle-based 的系統上遇到的問題：

除了技術類的問題外，這個「Not very responsive support」可以看到對 Oracle 的服務很不滿意。

另外下一張投影片只講 shop.oracle.com 是主要原因... 我猜是 Oracle 在開始提供 cloud service 後把售價都拉高。在最後的 Summary 看起來也有點像：

雖然沒有講明換 PostgreSQL 的理由，但注意到「3x more hardware」這點，這表示是原來的四倍。在這樣的情況下還是要換，可以猜測 Oracle 的授權費用在 web-scale 服務上的問題。

另外如果仔細品投影片，可以發現其實 migration 成功的原因是 DBA team 的能力夠強大，以及充足的時間修正問題 (可以看到作者在 mailing list 上一直提問也一直修正問題)。如果當初評估後決定要換到 MySQL，我相信也是會順利完成...

Netflix 把金流相關的系統轉移到 AWS 上跑 MySQL 的故事...

這次要提的是「Netflix Billing Migration to AWS」、「Netflix Billing Migration to AWS - Part II」與「Netflix Billing Migration to AWS - Part III」這三篇。

Netflix 先前的金流相關系統跑的是 Oracle 的資料庫：

然後換成 MySQL：

系統上是採用 DRBD，然後底層是 5 個 4TB 的 EBS 組成的 RAID 0，跑 LVM：

High performance with respect to reads and writes was achieved by using RAID0 with EBS provisioned IOPS volumes. To get more throughput per volume, 5 volumes of 4TB each were used, instead of 1 big volume. This was to facilitate faster snapshots and restores.

LVM to manage two Logical Volume’s (DB and DRBD Metadata) within single Volume Group.

可以看到裡面用的都是很經過時間考驗的技術，像是 DRBD、標準的 Replication 架構...

最近討論 Uber 的 MySQL 換 PostgreSQL 後又換回 MySQL 的文章...

先把兩份連結丟出來，一份是 PyPgDay 2013 時由 Uber 的 Evan Klitzke 給的「Migrating Uber from MySQL to PostgreSQL」，原 PDF 連結已經失效 (看起來已經被刪除)，但這個網路年代什麼都可以找到備份... 可以在「Migrating Uber from MySQL to PostgreSQL」取得，但這個網站怪怪的，我另外丟了一份到 Google Docs 上。

另外一份則是同一個人 Evan Klitzke 在 2016 年發表於公司的官方網站上：「Why Uber Engineering Switched from Postgres to MySQL」。

2013 年描述了從 MySQL 換到 PostgreSQL，2016 年同一個人出來則描述了從 PostgreSQL 換到 MySQL 的理由，有種臉腫腫的感覺。

先抓 2013 年的重點，當時分享的目標是要用 PostGIS：

在 2016 年的文章絕口不提 PostGIS，而是提到各種效能問題：花了很長的篇幅講 Non-clustered Index 與 Clustered Index 的設計，以及 Replication 時的頻寬效能差異。

先不管 PostGIS，如果真的是 UPDATE 造成效能問題，那麼不是要朝 sharding 解決嗎，怎麼是換成 MySQL？換到 MySQL 後還是會遇到效能問題啊，你還是要在 application 層上面找出方案啊。

這篇文章看起來更像是內部技術與政治問題掛勾在一起談，因為政治原因而換 MySQL，然後找出技術原因說明換的理由 XDDD

AWS Database Migration Service

AWS 正式向所有使用者開放「AWS Database Migration Service」了：「AWS Database Migration Service」。

AWS 把前置作業 (setup & initial backup) 與 replication 的部份都包好，讓使用者可以很輕鬆的轉移。

支援的來源資料庫種類包括了這五種：

Supported database sources include: (1) Oracle, (2) SQL Server, (3) MySQL, (4) Amazon Aurora and (5) PostgreSQL. All sources are supported on-premises, in EC2, and RDS except Amazon Aurora which is available only in RDS.

支援的目的資料庫種類也包括了這五種：

Supported database targets include: (1) Amazon Aurora, (2) Oracle, (3) SQL Server, (4) MySQL, and (5) PostgreSQL. All Oracle, SQL Server, MySQL and Postgres targets are supported on-premises, in EC2 and RDS.

所以不只可以搬進 AWS，也透過在 EC2 instance 上架 Proxy 的方式搬出 AWS。比較特別的是可以不同 database 互轉？這好像可以玩玩看...

轉移的機器包括 t2.* 與 c4.* 兩種，一般來說 t2 系列的機器應該夠用，但如果要拼轉移速度的話可以拿 c4 出來撐場面。