Bad replication packet after 23-Oct-23 maintenance?

Hi all,

I’m seeing an error for my musicbrainz replica following the 23rd October 2023 scheduled maintenance. The message from logs is as follows.

Mon Oct 23 16:12:01 2023 : Downloading https://metabrainz.org/api/musicbrainz/replication-162718-v2.tar.bz2 to /tmp/replication-162718-v2.tar.bz2
...
Mon Oct 23 16:12:03 2023 : This packet was produced (or begins) at 2023-10-23 16:03:16.672738+00
...
Mon Oct 23 16:12:04 2023 : Processing replication changes
     XIDs     Stmts est%  XIDs/sec  Stmt/sec
     2368     18606  62%        48       378Failed query:
	'INSERT INTO musicbrainz.tag (id, name, ref_count) VALUES (?, ?, ?)'
	(259975 girl group 0)
23505 DBD::Pg::st execute failed: ERROR:  duplicate key value violates unique constraint "tag_idx_name"
DETAIL:  Key (name)=(girl group) already exists. [for Statement "INSERT INTO musicbrainz.tag (id, name, ref_count) VALUES (?, ?, ?)" with ParamValues: 1='259975', 2='girl group', 3='0']
 at /musicbrainz-server/admin/replication/../../lib/Sql.pm line 122.
	Sql::catch {...} (MusicBrainz::Server::Exceptions::DatabaseError=HASH(0x55b6e0c962b0)) called at /root/perl5/lib/perl5/Try/Tiny.pm line 123
	Try::Tiny::try(CODE(0x55b6e0c8e620), Try::Tiny::Catch=REF(0x55b6e0c968e8)) called at /musicbrainz-server/admin/replication/../../lib/Sql.pm line 123
	Sql::do(Sql=HASH(0x55b6e0838b70), "INSERT INTO musicbrainz.tag (id, name, ref_count) VALUES (?, "..., 259975, "girl group", 0) called at /musicbrainz-server/admin/replication/ProcessReplicationChanges line 507
	main::dbmirror2_insert(Sql=HASH(0x55b6e0838b70), "musicbrainz.tag", HASH(0x55b6e0c96400)) called at /musicbrainz-server/admin/replication/ProcessReplicationChanges line 328
	main::dbmirror2_command(Sql=HASH(0x55b6e0838b70), ARRAY(0x55b6e03f9b58)) called at /musicbrainz-server/admin/replication/ProcessReplicationChanges line 177

If I query the tag table manually I do see there’s already a “girl group” row with a different id. So I think the unique constraint is working correctly.

musicbrainz_db=# SELECT * FROM musicbrainz.tag WHERE name='girl group';
 id  |    name    | ref_count 
-----+------------+-----------
 655 | girl group |       929
(1 row)

So could the replication packet be bad?
Or otherwise did I miss a packet which should have deleted the old id=655 row?
Or am I too out-of-date for something, and the newer scripts know to skip this bad row?

Any help/comment appreciated. Thanks!

1 Like

Hi @Hitobat, this is a known issue currently under investigation, see [MBS-13333] Replication is blocked by tag duplicates - MetaBrainz JIRA for follow-up, sorry for the inconvenience.

Thanks for the quick reply and ticket link.
I will watch for the updates on JIRA.

There’s a fix now, see our blog post.

4 Likes