Home » Computer » Software » Database » Archive by category "MariaDB"

KPTI (Meltdown Mitigation) 對 MyISAM 的痛點

MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字,這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」),說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大:

Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).

他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速,在新版應該可以改善不少。但即使如此,文章內還是在實體機器上看到了 40% 的效能損失:

A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.

然後後面就在推銷 MariaDB 的 Aria Storage Engine 了,不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的,因為接下來五年應該都還是愈的到 KPTI,應該還是有人在用 MyISAM...

Amazon RDS 支援更大的硬碟空間與更多的 IOPS

Amazon RDS 的升級:「Amazon RDS Now Supports Database Storage Size up to 16TB and Faster Scaling for MySQL, MariaDB, Oracle, and PostgreSQL Engines」。

空間上限從 6TB 變成 16TB,而且可以無痛升。另外 IOPS 上限從 30K 變成 40K:

Starting today, you can create Amazon RDS database instances for MySQL, MariaDB, Oracle, and PostgreSQL database engines with up to 16TB of storage. Existing database instances can also be scaled up to 16TB storage without any downtime.

The new storage limit is an increase from 6TB and is supported for Provisioned IOPS and General Purpose SSD storage types. You can also provision up to 40,000 IOPS for Provisioned IOPS storage volumes, an increase from 30,000 IOPS.

不過隔壁的 Amazon Aurora 還是大很多啊 (64TB),而且實際上不用管劃多大,他會自己長大:

Q: What are the minimum and maximum storage limits of an Amazon Aurora database?

The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance. There is no need to provision storage in advance.

RDS (MySQL/MariaDB) 支援 t2、r4 以及 m4 的新機種

這個大家等好久了,尤其 MySQL 常遇到需要用記憶體換效能的情境:「Amazon RDS for MySQL and MariaDB Supports R4, T2 and M4 Instance Types」。

先前 t2 最大只能開到 t2.large (8GB RAM),對於需要大量記憶體運算的 SQL query,就有機會被 MySQL 使用 filesort 寫到硬碟裡面暫存了。這次支援這些 instance type,開發環境至少有選擇可以開到 t2.2xlarge (32GB RAM) 跟他拼。

r4 應該是正式環境期待已久的 instance type 了。r3 最大是 r3.8xlarge (244GB),跟 r4 最大的 r4.16xlarge (488GB) 剛好差了一倍。

m4 就比較微妙了,順便補上去的感覺... 不過應該還是會有應用會剛好用到。

不過還是期待前陣子出來的 c5,對於寫出很驚人的 SQL query,在 MySQL 內跑大量運算的應用會有幫助,就繼續等吧... :o

Amazon RDS 的 RI 也支援彈性計價了

AWS 宣佈 RDS 的 RI 也支援彈性計價了:「Amazon RDS Reserved Instances Offer Instance Size Flexibility」。

也就是說跟 EC2 的 RI 方式切齊,買 db.m4.2xlarge 的 RI 後,可以用在兩台 db.m4.xlarge 上:

For example, let’s say you purchased a db.m4.2xlarge MySQL RI in US East (N. Virginia). The discounted rate of this RI can automatically apply to 2 db.m4.xlarge MySQL instances without you needing to do anything.

包括了相當多種類的 RDS,主要是沒有 license fee 的類型都包括在內了:

Amazon RDS Reserved Instance size flexibility is offered in all regions for the MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines, as well as the “bring your own license” (BYOL) edition of the Oracle database engine. To learn more about flexible RIs, please visit the Amazon RDS Reserved Instances Page.

但不包括要另外收 license fee 的 SQL Server 與 Oracle LI edition:

Size flexibility does not apply to Microsoft SQL Server and the License Included (LI) edition of Oracle.

Percona 比較 MySQL 與 MariaDB 預設值的差異

Percona 的人花了些時間整理 MySQL 5.7 與 MariaDB 10.2 在預設值上的差異:「MySQL and MariaDB Default Configuration Differences」。

整體可以感覺到 MariaDB 10.2 相較於 MySQL 5.7 還是頗偏 MyISAM 的設計,可能跟 Monty (Michael Widenius) 的偏好有關吧... 不過技術面上來說,MariaDB 10.2 是基於 5.5 分支出來一路改出來的,當時的 InnoDB 跟現在的版本比起來的確沒那麼強...

不過這畢竟只是預設值,看過留個印象就好...

Heimdall Data:自動 Cache RDBMS 資料增加效能

看到 AWS 的「Automating SQL Caching for Amazon ElastiCache and Amazon RDS」這篇裡面介紹了 Heimdall Data – SQL caching and performance optimization 這個產品。

從官網的介紹也可以看出來是另外疊一層 proxy,但自動幫你處理 cache invalidation 的問題:

But what makes Heimdall Data unique in industry is its auto-cache AND auto-invalidation capability. Our machine learning algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.

看起來支援了四個蠻常見的 RDBMS:

Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB).

看起來是一個花錢直接買效能的方案... 不過 cache invalidation 的部分不知道要怎麼跨機器做,在 FAQ 沒看到 cluster 情況下會怎麼解決。

MySQL 上 sharding 的方案

Percona 的人剛好針對 database sharding 的事情整理了一篇文章,專門講 SaaS 服務時對 sharding 的規劃:「MySQL Sharding Models for SaaS Applications」。

我主要是看這段:

When sharding today, you have a choice of rolling your own system from scratch, using comprehensive sharding platform such as Vitess or using a proxy solution to assist you with sharding. For proxy solutions, MySQL Router is the official solution. But in reality, third party solutions such as open source ProxySQL, commercial ScaleArc and semi-commercial (BSL) MariaDB MaxScale are widely used. Keep in mind, however, that traffic routing is only one of the problems that exist in large scale sharding implementations.

也就是說,除了在 application 上自己實作外,目前能用的方案 (堪用的方案) 大概就這些了,而且這些方案主要是解 routing 問題,對於跨 database server 的 join 都還是要自己小心實作。

後面提到的 sharding model 也是個蠻重要的主題,切割的方法與使用的方法有關,切的好效能就會好。

另外文章沒有提到要怎麼 balancing (甚至是 auto-balancing),這點應該也是比較需要注意的地方...

MySQL 全系列的安全性漏洞

包含 MySQL 本家與所有從 MySQL 改出去的分支都中了,引用 Percona 的通報:「Percona Server Critical Update CVE-2016-6662」。

This is a CRITICAL update, and the fix mitigates the potential for remote root code execution.

原始的 security advisory 在「CVE-2016-6662 - MySQL Remote Root Code Execution / Privilege Escalation ( 0day )」這邊,雖然是標 0day,但發現的人在七月時就有先通報給 vendor 們讓他們有時間修正:

The vulnerability was reported to Oracle on 29th of July 2016 and triaged by the security team. It was also reported to the other affected vendors including PerconaDB and MariaDB.

Oracle 還沒修正,也就是 upstream 目前仍然是有問題的,目前得靠其他 vendor 修正:

Official patches for the vulnerability are not available at this time for Oracle MySQL server.

其中 Percona 與 MariaDB 都已經先推出修正版本了:

The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August.

然後看了一下這個漏洞,從 SQL 指令可以做檔案操作一路打出來... 可以看到範例:

mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
    '> 
    '> ; injected config entry
    '> 
    '> [mysqld]
    '> malloc_lib=/tmp/mysql_exploit_lib.so
    '> 
    '> [separator]
    '> 
    '> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;

這下苦了...

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 出來撐場面。

Archives