[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:  Bootstrap/Load  |    Version:  6.7.2
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 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>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform