Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wikibase DB remains empty in Kubernetes #617

Closed
eloiferrer opened this issue Jan 31, 2025 · 5 comments
Closed

Wikibase DB remains empty in Kubernetes #617

eloiferrer opened this issue Jan 31, 2025 · 5 comments

Comments

@eloiferrer
Copy link
Member

I have managed to set up the mariaDB in the Kubernetes cluster with write and read replicas.

The only change I have introduced in LocalSettings is this (with the right credentials).

$wgDBservers = [
    [
        'host' => "mysql.svc:3306",
        'dbname' => "my_wiki",
        'user' => "sqluser",
        'password' => "change-this-sqlpassword",
        'type' => "mysql",
        'flags' => DBO_DEFAULT,
        'load' => 0,
    ],
    [
        'host' => "mysql-replica.svc:3306",
        'dbname' => "my_wiki",
        'user' => "sqluser",
        'password' => "change-this-sqlpassword",
        'type' => "mysql",
        'flags' => DBO_DEFAULT,
        'load' => 1,
    ],
];

The connection with the database is properly established and whenever I create a wikibase Item I can see it in the page table of the my_wiki database and correctly replicated. For instance:

select * from page;
+---------+----------------+------------+------------------+-------------+----------------+----------------+--------------------+-------------+----------+--------------------+-----------+
| page_id | page_namespace | page_title | page_is_redirect | page_is_new | page_random    | page_touched   | page_links_updated | page_latest | page_len | page_content_model | page_lang |
+---------+----------------+------------+------------------+-------------+----------------+----------------+--------------------+-------------+----------+--------------------+-----------+
|       1 |              0 | Main_Page  |                0 |           1 | 0.466554419997 | 20250131141039 | 20250131141039     |           1 |      755 | wikitext           | NULL      |
|       2 |            120 | Q1         |                0 |           1 | 0.275154333331 | 20250131141327 | 20250131141328     |           2 |      213 | wikibase-item      | NULL      |
+---------+----------------+------------+------------------+-------------+----------------+----------------+--------------------+-------------+----------+--------------------+-----------+

However, all the specific tables from Wikibase remain empty. Such as:

select * from wbt_text;
Empty set (0.000 sec)

Normally, the wbt_text table should show the labels of the items, in this case for item Q1.

@eloiferrer
Copy link
Member Author

eloiferrer commented Jan 31, 2025

Does Wikibase require some additional configuration parameter? Or maybe does this have something to do with our cache or jobrunner configuration? Any idea what might be going on @physikerwelt ?

@physikerwelt
Copy link
Member

Sorry, I never used $wgDBservers. See https://github.com/MaRDI4NFDI/portal-compose/pull/428/files for the way I think this should be done. In your change there is no indication which server is the main and which one is the replica. Thus, it might be that wikibase writes by chance to the replica.

@eloiferrer
Copy link
Member Author

As far as I understand, the 'load' parameter indicates what is the main and what is the replica, similarly to what you do in the code you attach with 'sectionLoads'. I will try using $wgLBFactoryConf instead to see if it helps. In any case, the replica is configured itself as read-only, so it is not possible for wikibase to write there.

@physikerwelt
Copy link
Member

I looked at the manual of wgDbServer. The first one is the master. It's hard to believe that one table behaves differently than the other. I would encourage you to double-check if the observation is correct.

@eloiferrer
Copy link
Member Author

For documentation, it was indeed the case that both tables were behaving differently.
The problem has been solved after applying:

GRANT BINLOG MONITOR ON *.* TO 'sqluser'@'%';

to the main node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants