[wp-trac] [WordPress Trac] #62964: WordPress Master-Master Replication Conflicts Caused by Gutenberg Blocks

[WordPress Trac]

#62964: WordPress Master-Master Replication Conflicts Caused by Gutenberg Blocks
--------------------------+------------------------------
 Reporter:  copytrans     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  6.7.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by dd32):

 * component:  Bootstrap/Load => Editor


Old description:

> Our company uses a WordPress setup with two servers behind a load
> balancer, and we rely on master-master MySQL replication. To prevent
> replication conflicts, cron jobs are configured to run only on a single
> server. This setup has worked seamlessly for several years, but we
> started encountering weekly replication conflicts around two months ago.
>
> The conflict occurs with the following SQL queries:
>
> ```sql
> ### DELETE FROM `fr_wp`.`wp_sitemeta`
> ### WHERE
> ###   @1=385338
> ###   @2=1
> ###   @3='_site_transient_wp_theme_files_patterns-
> 39b075616449d092b365a81b6f9d3e6d'
> ###   @4='a:2:{s:7:"version";s:0:"";s:8:"patterns";a:0:{}}'
>
> ### DELETE FROM `fr_wp`.`wp_sitemeta`
> ### WHERE
> ###   @1=385336
> ###   @2=1
> ###   @3='_site_transient_timeout_wp_theme_files_patterns-
> 39b075616449d092b365a81b6f9d3e6d'
> ###   @4='1737837003'
> # at 150934730
> ```
>
> Upon reviewing the WordPress source code, I identified that these
> conflicts are caused by the WordPress function
> {{{_register_theme_block_patterns}}} being executed at the exact same
> time on both servers.
>
> Since our site does not use Gutenberg blocks, we resolved the issue by
> preventing this function from being executed:
>
> {{{#!php
> <?php
> remove_action('init', '_register_theme_block_patterns');
> }}}

New description:

 Our company uses a WordPress setup with two servers behind a load
 balancer, and we rely on master-master MySQL replication. To prevent
 replication conflicts, cron jobs are configured to run only on a single
 server. This setup has worked seamlessly for several years, but we started
 encountering weekly replication conflicts around two months ago.

 The conflict occurs with the following SQL queries:

 {{{#!sql
 ### DELETE FROM `fr_wp`.`wp_sitemeta`
 ### WHERE
 ###   @1=385338
 ###   @2=1
 ###   @3='_site_transient_wp_theme_files_patterns-
 39b075616449d092b365a81b6f9d3e6d'
 ###   @4='a:2:{s:7:"version";s:0:"";s:8:"patterns";a:0:{}}'

 ### DELETE FROM `fr_wp`.`wp_sitemeta`
 ### WHERE
 ###   @1=385336
 ###   @2=1
 ###   @3='_site_transient_timeout_wp_theme_files_patterns-
 39b075616449d092b365a81b6f9d3e6d'
 ###   @4='1737837003'
 # at 150934730
 }}}

 Upon reviewing the WordPress source code, I identified that these
 conflicts are caused by the WordPress function
 {{{_register_theme_block_patterns}}} being executed at the exact same time
 on both servers.

 Since our site does not use Gutenberg blocks, we resolved the issue by
 preventing this function from being executed:

 {{{#!php
 <?php
 remove_action('init', '_register_theme_block_patterns');
 }}}

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62964#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform