Alter table в percona-xtradb-cluster

[Vladimir Ermolov]

  Добрый день.

Развернут Percona-xtradb-cluster
5.6.21-70.1-56-log, 4 ноды.

Крутится две базы - два разных проекта, суммарно 2.2к запросов в сек.

Наткнулся на странный эффект.

Понадобилось добавить в таблицу  одной из баз, дополнительный ключ.

В таблице 1.4М записей.

При добавлении ключа (операция заняла 30 сек на одной ноде),
на две минуты зависли запросы к базе соседнего проекта.

С чем может быть связано подобное поведение?

Конфиг my.cnf
-----

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /dev/shm
lc-messages-dir = /usr/share/mysql
skip-external-locking
low-priority-updates
character-set-server            = utf8
skip-name-resolve
net_read_timeout=120
net_write_timeout=240
thread_pool_idle_timeout=120
explicit_defaults_for_timestamp=TRUE
bind-address=db-node0
binlog_format=ROW
log_bin = galera.bin
binlog_cache_size=256M
back_log = 100
max_binlog_files = 10
max_binlog_size = 1G

key_buffer_size         = 80M
max_allowed_packet      = 64M
thread_stack            = 512K
thread_cache_size = 1000
innodb_thread_concurrency=400
max_connections        = 2000
tmp_table_size         = 256M
max_heap_table_size    = 256M
max_prepared_stmt_count=500000
max_connect_errors = 30
sort_buffer_size = 4M
join_buffer_size = 4M
read_rnd_buffer_size = 128M
default_storage_engine = InnoDB
query_cache_type=1
query_cache_size = 128M
query_cache_strip_comments = 'ON'
query_cache_limit = 10M
optimizer_search_depth=10
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
slow_query_log_always_write_time = 2
slow_query_log = 'ON'
max_slowlog_files = 7
max_slowlog_size = 100M
log_error                = /var/log/mysql/error.log
innodb_buffer_pool_size = 64G
innodb_lock_wait_timeout = 100
innodb_file_per_table = true
innodb_log_files_in_group = 2
innodb_log_file_size = 4G
innodb_flush_log_at_trx_commit = 1
innodb_read_io_threads = 32
innodb_write_io_threads = 16
innodb_io_capacity = 4000
innodb_buffer_pool_populate = 1
innodb_autoinc_lock_mode=2
read_buffer_size = 1M
bulk_insert_buffer_size = 8M
myisam_sort_buffer_size = 8M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_provider_options="gcache.size=32G;gcache.page_size=1G;"
wsrep_cluster_name="galera"
wsrep_cluster_address=gcomm://172.17.3.31,172.17.3.33,172.17.3.47,172.17.3.30
wsrep_node_name="db-node0"
wsrep_node_address=db-node0
wsrep_node_incoming_address=db-node0
wsrep_slave_threads=64
wsrep_certify_nonPK=1
wsrep_convert_LOCK_to_trx=0
wsrep_retry_autocommit=1
wsrep_auto_increment_control=1
wsrep_sst_method=rsync
wsrep_sst_receive_address=db-node0
wsrep_sst_auth=uname:pass
wsrep_sst_donor=db-nodex
wsrep_log_conflicts=ON

-----

--

С уважением, Владимир Ермолов.
e-mail: vladimi...@gmail.com

[Konstantin Osipov]

* Vladimir Ermolov <vladimi...@gmail.com> [15/05/12 17:32]:

> Добрый день.
> Развернут Percona-xtradb-cluster
> 5.6.21-70.1-56-log, 4 ноды.
>
> Крутится две базы - два разных проекта, суммарно 2.2к запросов в сек.
> Наткнулся на странный эффект.
> Понадобилось добавить в таблицу одной из баз, дополнительный ключ.
> В таблице 1.4М записей.
>
> При добавлении ключа (операция заняла 30 сек на одной ноде),
> на две минуты зависли запросы к базе соседнего проекта.
> С чем может быть связано подобное поведение?

Вообще ничего не знаю про Percona XtraD 5.6, но подозреваю что
Galera может лочить весь кластер на DDL. Цена моему подозрению,
впрочем, 3 копейки, надо чтобы гуру из Перконы отписались.


--
http://tarantool.org - a NoSQL database in a Lua script

[nasre...@gmail.com]

Ну, учитывая, что galera является синхронной репликацией, это не сильно удивительно, что DDL тоже будет синхронным

--

---
Вы получили это сообщение, поскольку подписаны на группу Moscow MySQL User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[nasre...@gmail.com]

А висят запросы к той же таблице или к другой? Если к другой, то сорри, неправильно вас понял

[Vladimir Ermolov]

Вообще, висят запросы к базе соседнего проекта, никак не связанной с таблицей для которой выполнялся alter table.

А понимал, что alter table - заблокирует таблицу в кластере, на время Кол_нод * время выполнения на одной ноде.

Но был неприятно удивлен, что зависли запросы к базе другого проекта на этом же кластере.

Вот,  к примеру в slow log попало в в тот период (запуск alter table был в 13:22:49)

SET timestamp=1431080750;
insert `tokens` values("", 'eb4561e44fe5cfb363db2398e745c2e2', CURRENT_TIMESTAMP, '60', '0', 'js-token');
# User@Host: prod[prod] @  [172.17.3.30]  Id: 271328162
# Schema: projectan  Last_errno: 1366  Killed: 0
# Query_time: 180.424347  Lock_time: 0.000321  Rows_sent: 0  Rows_examined: 0  Rows_affected: 2
# Bytes_sent: 11

Это запрос к базе, живущей на том-же кластере, в момент когда проходил alter table для таблицы соседней

базы. Время совпадает:

select FROM_UNIXTIME(1431080750 - 180) \G
*************************** 1. row ***************************
FROM_UNIXTIME(1431080750 - 180): 2015-05-08 13:22:50

Он никогда не попадал в slow log (да и не должен был). И такого насыпало очень много.

Фактически, получается, что кластер рассчитан на применение только для одного проекта.

Ибо работы с соседней базой могут *положить* ничего не подозревающий проект.

Сейчас рассматриваю вариант с несколькими инстансами (или контейнерной изоляцией), ибо кластер

нужен, а вот взаимовлияние проектов надо максимально исключить.

12 мая 2015 г., 22:48 пользователь nasre...@gmail.com <nasre...@gmail.com> написал:

Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Alexey Kopytov]

Привет, Владимир!

On Wed, 13 May 2015 09:50:59 +0300, Vladimir Ermolov wrote:
> Вообще, висят запросы к базе соседнего проекта, никак не связанной с
> таблицей для которой выполнялся alter table.
> А понимал, что alter table - заблокирует таблицу в кластере, на время
> Кол_нод * время выполнения на одной ноде.
> Но был неприятно удивлен, что зависли запросы к базе другого проекта на
> этом же кластере.

В Galera кластере DDL операции выполняются в режиме Total Order
Isolation по умолчанию (wsrep_OSU_method='TOI'). Это значит, что каждая
DDL операция выполняется в одинаковом порядке по отношению к другим
транзакциям на каждом узле. А значит все коммиты блокируются до
завершения текущей DDL операции.

Это связано с ограничениями в реализации DDL в MySQL и вряд ли будет
исправлено в ближайшем будущем.

Возможны следующие решения:

- использовать rolling schema upgrade (wsrep_OSU_method='RSU'). В этом
случае DDL выполняется отдельно на каждом узле, а сам узел временно
"выключается" из репликации.

- использовать утилиту pt-online-schema-change из пакета Percona
Toolkit. Утилита выполняет ALTER TABLE путём создания временной таблицы
и копирования данных туда. С точки зрения сервера длинный DDL заменяется
на серию коротких DDL + DML запросов, а значит Galera кластер не
блокируется на долгое время независимо от размеров таблицы.

Подробное описание проблемы:

https://bugs.launchpad.net/galera/+bug/928919
https://bugs.launchpad.net/codership-mysql/+bug/1257069

Подробно про возможные решения:

http://www.severalnines.com/blog/online-schema-upgrade-mysql-galera-cluster-using-toi-method
http://www.severalnines.com/blog/online-schema-upgrade-mysql-galera-cluster-using-rsu-method

/Алексей

> <mailto:nasre...@gmail.com> <nasre...@gmail.com
> <mailto:nasre...@gmail.com>> написал:

>
> А висят запросы к той же таблице или к другой? Если к другой, то
> сорри, неправильно вас понял
>
>
> On Tuesday, May 12, 2015, nasre...@gmail.com

> <mailto:nasre...@gmail.com> <nasre...@gmail.com

> <mailto:moscow-mysql-user...@googlegroups.com>.

> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.
>
>
>
>
> --
> С уважением, Владимир Ермолов.

> e-mail: vladimi...@gmail.com <mailto:vladimi...@gmail.com>

>
> --
>
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее
> сообщения, отправьте письмо на электронный адрес
> moscow-mysql-user...@googlegroups.com

> <mailto:moscow-mysql-user...@googlegroups.com>.

[Vladimir Ermolov]

  Добрый вечер,  Алексей.

Большое спасибо за развернутый ответ!

Будем менять привычные методы работы, с учетом этих особенностей.

14 мая 2015 г., 23:47 пользователь Alexey Kopytov <akop...@gmail.com> написал:

[Ivan Usachev]

Добрый вечер!

Спустя год. есть ли надежда что в PXC 5.7 что то изменится в лучшую сторону с alter в кластере?

четверг, 14 мая 2015 г., 23:47:27 UTC+3 пользователь Alexey Kopytov написал:

[Alexey Kopytov]

Привет,

On Wed, 30 Mar 2016 10:24:58 -0700 (PDT), Ivan Usachev wrote:
> Добрый вечер!
> Спустя год. есть ли надежда что в PXC 5.7 что то изменится в лучшую
> сторону с alter в кластере?
>

Да, изменение в лучшую сторону будет выпущено в Galera 4.0 под названием
"non-blocking DDL".

Но так как я уже не работаю в Percona и не слежу за планами Codership,
не могу сказать, когда будет выпущена Galera 4.0 и будет ли она включена
в PXC 5.7.

Думаю, лучше всего задать этот вопрос в списке рассылки Percona:
https://groups.google.com/forum/#!forum/percona-discussion

/Алексей

> четверг, 14 мая 2015 г., 23:47:27 UTC+3 пользователь Alexey Kopytov написал:
>
> Привет, Владимир!
>
>
> On Wed, 13 May 2015 09:50:59 +0300, Vladimir Ermolov wrote:
> > Вообще, висят запросы к базе соседнего проекта, никак не связанной с
> > таблицей для которой выполнялся alter table.
> > А понимал, что alter table - заблокирует таблицу в кластере, на
> время
> > Кол_нод * время выполнения на одной ноде.
> > Но был неприятно удивлен, что зависли запросы к базе другого
> проекта на
> > этом же кластере.
>
> В Galera кластере DDL операции выполняются в режиме Total Order
> Isolation по умолчанию (wsrep_OSU_method='TOI'). Это значит, что каждая
> DDL операция выполняется в одинаковом порядке по отношению к другим
> транзакциям на каждом узле. А значит все коммиты блокируются до
> завершения текущей DDL операции.
>
> Это связано с ограничениями в реализации DDL в MySQL и вряд ли будет
> исправлено в ближайшем будущем.
>
> Возможны следующие решения:
>
>