Home » Posts tagged "sql" (Page 3)

MySQL GTID Replication 的惡搞修復

Percona 的「Database Daily Ops Series: GTID Replication」這篇在講當 MySQL 的 GTID Replication 爛掉時可能的修法,算是頗惡搞的方法,修好後還是要跑 pt-table-checksum 確認兩邊的資料是否一致,如果有狀況的話還是得拿出 pt-table-sync 同步。

第一招是用 pt-slave-restart,跳過會造成問題 SQL,讓他強制同步 (唔):

This passes the master’s UUID and it skips all global transactions breaking replication on a specific slave server[.]

第二招是 mysqlslavetrx,也是類似的作法,只是拿的是 MySQL 官方的工具來惡搞...

第三招是 Inject a Fake Transaction,其實就是手動自己做 XDDD

所以不管是哪招,做完後還是要記得跑 pt-table-{checksum,sync} 收尾,不然還是會爛掉...

Amazon Athena:直接在 S3 上進行分析

Amazon Athena 提供另外一種選擇,讓分析的便利性增加了許多:「Amazon Athena – Interactive SQL Queries for Data in Amazon S3」。

以往都需要開 server 起來分析,這個新的服務直接使用就好:

Athena is based on the Presto distributed SQL engine and can query data in many different formats including JSON, CSV, log files, text with custom delimiters, Apache Parquet, and Apache ORC.

果然是用 Presto 改出來的... XDDD

指定好各種資料來源之後直接下 SQL query 分析,然後依照分析的量來算錢... 而 FAQ 的地方也有提到可以透過 JDBC 接上去,這樣看起來跑報表的場合直接丟給他處理了:

Amazon Athena can be accessed via the AWS management console and a JDBC driver. You can programmatically run queries, add tables or partitions using the JDBC driver.

隔壁 Amazon Redshift 的立場變得很尷尬啊,Amazon Athena 不需要養機器而且又可以直接從 Amazon S3 拉資料,如果之後把 Presto 對 RDBMS 的部分再補上來的話就更棒了... (應該是下一階段的任務,把 RDS 補上)

MySQL 8.0 將會實作「真正的」Descending Indexes

在「MySQL 8.0 Labs – Descending Indexes in MySQL」這邊看到 MySQL 打算在 8.0 時實作出真正的 Descending Indexes。在 5.7 以及之前的版本,可以從「14.1.14 CREATE INDEX Syntax」看到這個參數是~假~的~XDDD

An index_col_name specification can end with ASC or DESC. These keywords are permitted for future extensions for specifying ascending or descending index value storage. Currently, they are parsed but ignored; index values are always stored in ascending order.

所以當 8.0 建立了 a_desc_b_asc (a DESC, b ASC) 這樣的 index,可以看到對於不同 ORDER BY 時效能的差異:(一千萬筆資料)

有些變快可以理解,但有些結果不太清楚造成的原因...

Anyway,對於變慢的兩個 query,他提了一個不算解法的解法,就是加上對應的 index XDDD:

If user wants to avoid filesorts for Query 5 and Query 6, he/she can alter the table to add a key (a ASC, b ASC) . Further to this, if the user wants to avoid backward index scans too, he/she can add both ( a ASC, b DESC) and (a DESC, b DESC).

這樣就會變快,但寫入的 overhead 會增加啊... XD

但不管怎樣,總算是把這個功能生出來了...

PostgreSQL 上,直接將 SSD 的內容送到 GPU 上,加速讀取速度

PostgreSQL 上針對讀取檔案到 GPU 上的成果:「GpuScan + SSD-to-GPU Direct DMA」(日文版)、「(EN) GpuScan + SSD-to-GPU Direct DMA」(英文版)。

主要的原因在於雖然已經有 PGStorm 讓 PostgreSQL 把運算丟到 GPU 上加速,但從 disk 讀到 GPU 這段還是有改善的空間:

PG-Strom that is an extension of PostgreSQL to off-load multiple SQL workloads on GPU devices, transparently. It has been developed for four years, and now supports simple scan, tables join, aggregation and projection.
Its prime focus is CPU intensive workloads, on the other hands, it didn't touch storage subsystem of PostgreSQL because the earlier version of PG-Strom assumes all the data set shall be pre-loaded onto physical memory. No need to say, we had a problem when we want to process a data-set larger than physical RAM.

這是成果,可以看到速度快了一倍以上:

這對資料量超過 RAM 大小時的處理會非常有幫助 (因為會有大量的 disk i/o 發生)。

MySQL 8.0 的 performance_schema 加上 index 了...

MySQL 8.0 是 MySQL 5.7 的後續版本,中間的 6.0 與 7.0 都有一些故事,就被跳過去了,跟 PHP 的情況有點像。

在 8.0 版將會把 performance_schamea 加上 index,讓查詢的速度變快:「MySQL 8.0: Performance Schema, now with indexes!」:

In MySQL 8.0, performance_schema tables are now indexed to speed up data retrieval.

A total of 115 indexes have been added in the performance schema in MySQL 8.0.0, to support better data access patterns in general.

有用過 performance_schema 的人都會有種「這好慢啊」的感覺,總算要改善了... 而且這幾乎是沒什麼成本的改善:

Question: How much overhead was just added by this new feature?
Answer: Absolutely zero

並不是用 index 加快速度,而是加了一些資訊,修正 optimizer 的行為:

It does — not — maintain a physical index internally, be it on file or memory.
It does, however, — pretend — to the optimizer that it has indexes, so that the optimizer is coerced into using the most efficient access pattern.

在有些情況下可以看到會快非常的多:

The performance improvements from indexes can be very easily seen in many of the sys schema queries. With 1000 idle threads, the query SELECT * FROM sys.session drops from 34.70 seconds down to 1.01 seconds (a 30x improvement!):

不知道 Percona 會不會 backport 回來,這看起來對於爆炸中的 server 找問題會很有幫助,可以在短時間翻出是哪個部份爆炸...

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;

這下苦了...

Scylla 1.3

看到 Scylla 正式公告 1.3 版的消息了:「Scylla release: version 1.3」。

Scylla 是用 C++ 重寫 Java 版本的 Cassandra 所有東西 (包括資料結構與 Protocol),目標是做到可以完全相容替換現有 Cassandra Cluster。(號稱可以一台一台移除 Cassandra 的程式,裝上 Scylla 後就可以無痛換過去)

而 Scylla 另外一個重點是效能的提昇,官方宣稱在完整最佳化的情況下是 10x 以上的效能提昇,之前拿 AWS 實測 (沒有完整最佳化) 也可以看到 2x 到 4x 的數字,對於目前的 Cassandra 應用來說極為重要。

1.3 版最重要的功能就是對 Thrift 的支援:

Thrift support. Many Cassandra users are still using Thrift, and they can now continue doing so while benefiting from Scylla’s performance. Built on top of Scylla CQL internal implementation, Scylla Thrift provides similar throughput and latency to Scylla CQL. Users of projects like KairosDB and Titan can now migrate to Scylla while maintaining full protocol compatibility .

本來在 roadmap 上的計畫是用兩個版本支援 Thrift:(從 Google Cache 拉出來的,CSS 看起來有些問題,不過意思有到就好)

剛剛發現 1.4 的 roadmap 已經沒有列 Thrift 了:

這應該是暗示已經實作完了?透過 Thrift 界面跟 Cassandra 溝通的應用程式都可以使用 Scylla 了...

先前在「Facebook Presto · Issue #1139 · scylladb/scylla」這邊跟 ScyllaDB 的人花了不少時間,總算是給出一份 data set 可以讓他們重製 bug,也算是有代價了 XD

Yelp 對 MySQL 更新的資料送到 Kafka 的作法

Apache Kafka 是個 pub-sub 系統:

Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.

Yelp 的人想要將 MySQL 的更新資訊送一份到 Kafka 就可以做很多應用。文章前面介紹了很多原理以及理論,像是講 MySQL 的 replication:

但讀這篇文章發現重點在於他介紹了 GitHub 上的「noplay/python-mysql-replication」這個專案:

Our stream reader is an abstraction over the BinLogStreamReader from the python-mysql-replication package.

這個專案可以解析 MySQL 的 replication protocol:

Pure Python Implementation of MySQL replication protocol build on top of PyMYSQL. This allow you to receive event like insert, update, delete with their datas and raw SQL queries.

馬上就感覺到可以透過這個 library 做不少事情,像是直接接到 worker,再更新 Elasticsearch 上的資料,這樣就是 100% 確保不會漏更新...

MySQL 5.7 的 Pipeline 查詢加速

在「MySQL 5.7.12 – Part 2: Improving the MySQL Protocol」這邊看到介紹 MySQL 的 Asynchronous API,藉由 pipeline 加速查詢。

本來的:

res_1 = conn.query("DO 1");
res_2 = conn.query("DO 2");

會產生這樣的 flow:

而 Asynchronous API 可以這樣寫,先把兩個 SQL query 都丟出去,然後等結果:

hndl_1 = conn.query_send("DO 1");
hndl_2 = conn.query_send("DO 2");

# wait for completion
res_1 = conn.query_recv(hndl_1);
res_2 = conn.query_recv(hndl_2);

也就是產生這樣的 flow:

感覺 PHP 上只要 PDO 改善這塊後,各家 ORM library 就可以支援受益...

Archives