magento2: General error: 1836 Running in read-only mode, query was: SELECT GET_LOCK(?, ?)

Preconditions (*)

PHP v7.4.13
magento EE 2.4.1
aws aurora cluster Engine version 5.7.mysql_aurora.2.08.21 Writer & Reader

Steps to reproduce (*)

configure app/etc/env.php

'db' => [
        'connection' => [
            'default' => [
                'host' => DATABASE_HOST,
                'dbname' => DATABASE_NAME,
                'username' => DATABASE_USERNAME,
                'password' => DATABASE_PASSWORD,
                'model' => 'mysql4',
                'engine' => 'innodb',
                'initStatements' => 'SET NAMES utf8;',
                'active' => '1',
            ],
        ],
        'slave_connection' => [
            'default' => [
                'host' => DATABASE_READ_ONLY_HOST,
                'dbname' => DATABASE_READ_ONLY_NAME,
                'username' => DATABASE_READ_ONLY_USERNAME
                'password' => DATABASE_READ_ONLY_PASSWORD,
                'model' => 'mysql4',
                'engine' => 'innodb',
                'initStatements' => 'SET NAMES utf8;',
                'active' => '1',
            ],
        ],
        'table_prefix' => '',
    ],

open admin pannel, so magento.local/admin > login > pannel page

Expected result (*)

No errors!

Actual result (*)

General error: 1836 Running in read-only mode, query was: SELECT GET_LOCK(?, ?)

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

Severity: S0 - Affects critical data or functionality and leaves users without workaround.
Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

This bug does not allow us to exploit read-only instance of aws aurora cluster. Most likely it can also be reproduced on other types of clusters.

Can you help me solve this problem? Thanks!

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 9
Comments: 23 (6 by maintainers)

Most upvoted comments

We are also facing the same issue with identical configuration , Is there any work around for this issue apart from disabling the reader configuration in env.php ?

php 7.4.13 magento EE 2.4.1 Aws aurora cluster5.7.mysql_aurora.2.09.1

anoop-corra on Jan 5, 2021

I can confirm this as we have the same problem.

sven-codeculture on Dec 17, 2020

gotta love the bot noise in this thread

francescosalvi on Sep 29, 2021

Hi all, we have the same problem of @rvitaliy and @sodhancha on AWS aurora replicas with:

php 7.4.6
Magento CE (Commerce Edition) ver. 2.4.2

I report our analisys if can be useful to the problem fix.

It seems that the problem is caused by two wrong injected dependencies, for the class Magento\Framework\Cache\LockGuardedCacheLoader and member locker.

The member locker is of declared as LockManagerInterface and resolved with the proxy class Magento\Framework\Lock\Proxy. This proxy istances the right lock strategy using Magento\Framework\Lock\LockBackendFactory, which reads the configuration and should instances in our case a Magento\Framework\Lock\Backend\FileLock.

But, the lock Magento\Framework\Lock\Backend\Database is used anyway:

on the frontend
into Magento admin panel.

We found (seems) two possible wrong concrete implementations for the member Magento\Framework\Cache\LockGuardedCacheLoader::locker, in these files:

app/etc/di.xml

<type name="Magento\Framework\Cache\LockGuardedCacheLoader">
      <arguments>
          <argument name="locker" xsi:type="object">Magento\Framework\Lock\Backend\Database</argument>
      </arguments>
  </type>

vendor/magento/module-config/etc/di.xml

<virtualType name="systemConfigQueryLocker" type="Magento\Framework\Cache\LockGuardedCacheLoader">
        <arguments>
            <argument name="locker" xsi:type="object">Magento\Framework\Lock\Backend\Database</argument>
        </arguments>
    </virtualType>

These declarations force the use of Magento\Framework\Lock\Backend\Database bypassing the LockManagerInterface instanciation based on proxy. The down side is that the database lock, has done on slave connection causing the error General error: 1836 Running in read-only mode, query was: SELECT GET_LOCK(?, ?)

If we change Magento\Framework\Lock\Backend\Database with Magento\Framework\Lock\LockManagerInterface, all come back to work properly.

gianstraf on Feb 22, 2021

Magneto Support Reply: _This issue will not be fixed as it is reproduced with AWS aurora replicas only.

It is not reproducible with 2.4-develop/mysql 8.0 and replica with innodb_read_only or super_read_only ON. With this being the case, it is recommended to switch lock provider from db to zookeeper, or file._

sodhancha on Jan 29, 2021

@rvitaliy i’ve opened this issue on my ticket list with Magento Commerce Support as well.

sodhancha on Jan 26, 2021

@sodhancha rollback configuration. 😢 I hope Magento’s developers solve this problem. 🚀

rvitaliy on Jan 21, 2021