maria-discuss team mailing list archive

[Artem Russakovskii <archon810@xxxxxxxxx>]

Hi,

I haven't received a reply to this one. Is someone on the team with
knowledge of the cluster able to comment?

Thanks.

Sincerely,
Artem

--
Founder, Android Police <http://www.androidpolice.com>, APK Mirror
<http://www.apkmirror.com/>, Illogical Robot LLC
beerpla.net | @ArtemR <http://twitter.com/ArtemR>


On Tue, Apr 21, 2020 at 4:15 PM Artem Russakovskii <archon810@xxxxxxxxx>
wrote:

> Hi,
>
> On this page
> https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/, a
> user in 2017 pointed out the following:
>
>
> 3 years, 3 months ago Björn Schneider
> <https://mariadb.com/kb/user/id/4916>
> Schema changes of large tables in Galera
> <https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/#comment_2704>
>
> You should be warned that every DDL statement executed on a Galera cluster
> will per default BLOCK the complete cluster (not only the table, or even
> just the database the table resides in)! This is the default "Total Order
> Isolation" (TOI) mode.
>
> The DDL statements can't be killed - once issued, it will run until
> completed or an error occurs.
>
> Issuing e.g. a column-altering DDL statement on a large table will take
> the complete cluster out of commission until every node has completed the
> migration. Only some operations (e.g. changing DEFAULT values) are always
> short-timed and won't interefere with the cluster's opperations.
>
> Long-running, cluster-blocking DDL are of course a no-go on a productive
> system. To resolve this issue, there are several resulutions; Percona, for
> example, provides a script to "online" migrate a table
> (pt-online-schema-change), or you can use the "Rolling Schema Upgrade"
> (RSU) for data-compatible changes. More about that in the Galera
> documentation.
>
> In my opionion, this behaviour should definitely added as "observation" to
> this page - it's definitely not something you'd expect coming from a
> "normal" MariaDB/MySQL system.
>
>
> We're considering moving to a cluster environment from a 1 master - 3
> slave configuration that has proven inflexible, but such a severe
> limitation seems unusable in production.
>
> Is this still the case in 2020? What is the reasoning behind such an
> architectural decision, if so?
>
> Thank you.
>
> Sincerely,
> Artem
>
> --
> Founder, Android Police <http://www.androidpolice.com>, APK Mirror
> <http://www.apkmirror.com/>, Illogical Robot LLC
> beerpla.net | @ArtemR <http://twitter.com/ArtemR>
>