Home » Posts tagged "mariadb"

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

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 全系列的安全性漏洞

包含 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;

這下苦了...

MariaDB 讀寫分離的工具:MaxScale

MariaDBMaxScale 軟體提供 MySQL 相容的 proxy interface,可以將後端一群 MySQL server 架構隱藏起來,讓應用程式不需要處理這部份。

Percona 的人則介紹 MaxScale 作為讀寫分離的工具:「High availability with asynchronous replication… and transparent R/W split」。

如果你是用有支援讀寫分離的 ORM (像是 Laravel 中的 Illuminate::Database),由於 ORM library 幫你處理好了,你可以省掉這個工作。

但在其他的情況,像是應用程式沒有原始程式碼,或是只能設一組 server,你就必須透過像 MaxScale 這種軟體來幫你打散負荷量。

Percona 給的範例提供了很多設定檔,應該是改一改就可以動 (當然效能調校是另外要花功夫的事情了),對於有興趣的人應該可以丟人研究?

Amazon RDS 提更完整的監控機制

這次 Amazon RDS 發表了更細的監控機制,包括了 MySQL 5.6、MariaDBAurora 這幾個產品線:「New – Enhanced Monitoring for Amazon RDS (MySQL 5.6, MariaDB, and Aurora)」。

rds_full_metrics_list_2

差不多是 SmokePing 可以提供的範圍,算是補的更齊全,讓找問題時的資料更多。不過顆粒細度可以到一秒鐘:

rds_enable_enhanced_monitoring_2

不過要注意的是,t1.micro 與 m1.small 不支援:

It works for MySQL 5.6, MariaDB, and Amazon Aurora, on all instance types except t1.micro and m1.small.

繼續學 Isolation...

在「測試 MariaDB 上 Galera Cluster 的 Isolation」這邊與「從頭學一次 Isolation level 的 REPEATABLE-READ 與 SERIALIZABLE」對應了 Stripe 的「Call me Maybe: MariaDB Galera Cluster」以及 Percona 的「Clarification on “Call me Maybe: MariaDB Galera Cluster”」這兩篇文章,兩邊在空中交火...

而「Call me Maybe: Percona XtraDB Cluster」這篇是目前最新的一篇 (文章日期有點怪怪的,不應該是 2015/09/04)。

畢竟 Galera Cluster 是目前現在在用的產品,雖然跑起來也沒什麼大問題,但預先多了解一點總是比較保險。而要參與這場 Isolation 戰爭,又花了不少時間看幾份資料。(包括重頭讀的)

第一個當然是 1992 年發表的 SQL-92:「ISO/IEC 9075:1992, Database Language SQL」,在 SQL-92 定義了四個 Isolation 的層級,分別是 SERIALIZABLEREPEATABLE READREAD COMMITTEDREAD UNCOMMITTED

另外一篇常被拿出來討論的是 1995 年由微軟帶頭發表的「A Critique of ANSI SQL Isolation Levels」,主要是提出 Snapshot Isolation 的定義。

後來讀到覺得真的很怪的時候到 Stack Exchange 上的 Database Administrators 問:「Does SQL92's REPEATABLE-READ preclude Write Skew (A5B)?」,確認了我的想法。

這篇算是讀書心得吧,留給自己用的 :p

首先是 REPEATABLE READ 的定義是透過「現象」定義,只要符合這些條件就可以被稱作 REPEATABLE READ,這包括了保證不會出現 P1 ("Dirty read"):

1) P1 ("Dirty read"): SQL-transaction T1 modifies a row. SQL-transaction T2 then reads that row before T1 performs a COMMIT. If T1 then performs a ROLLBACK, T2 will have read a row that was never committed and that may thus be considered to have never existed.

以及保證不會出現 P2 ("Non-repeatable read"):

2) P2 ("Non-repeatable read"): SQL-transaction T1 reads a row. SQL-transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted.

並且保證 Atomicity 以及 no updates will be lost:

The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost.

只要做到這些條件,就可以說符合 SQL-92 的 REPEATABLE READ 要求。


另外一方面,在「A Critique of ANSI SQL Isolation Levels」定義的 SQL-92 認為 REPEATABLE READ 是透過 locking 機制實作的 (整篇的寫法的確是朝這個方向走),並且基於 locking mechanism 來推論後續的行為,所以這篇 paper 裡面很多說明是帶著這個大前提的。

而當時已經有資料庫是使用 MVCC 架構在實作,可以透過 read snapshot 的方式找出另外一條路。

舉例來說,InnoDB 對 REPEATABLE READ 實作的方式是透過 snapshot 實作:(出自「MySQL :: MySQL 5.6 Reference Manual :: 13.3.6 SET TRANSACTION Syntax」)

For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other.

這樣避開了 P1、P2 (甚至多做避開到了 P3,不過這邊不重要),並且 Atomicity。而 Update Lost 問題則再透過 lock 機制避免。所以 InnoDB 的 REPEATABLE READ 其實比 SQL-92 的要求多做到了很多事情...


到這邊再回頭看原來的討論文章,才會發現 Isolation 裡有滿滿的地雷可以採 XD

Archives