Turns out a UNIQUE KEY for each table, not having a PK, is enough for replication to work.
This of course requires, that no duplicate rows exist, for key combinations selected for creating the unique key.
But in my installation, following tables seems to have duplicate rows where they should not exist:
phpbb_acl_groups
SELECT group_id, forum_id, auth_option_id, COUNT(*) FROM phpbb_acl_groups GROUP BY group_id, forum_id, auth_option_id HAVING COUNT(*) > 1;
- > several
phpbb_acl_users
SELECT user_id, forum_id, auth_option_id, COUNT(*) FROM phpbb_acl_users GROUP BY user_id, forum_id, auth_option_id HAVING COUNT(*) > 1;
- > several
phpbb_poll_votes
SELECT topic_id, poll_option_id, vote_user_id, COUNT(*) AS duplicate_count FROM phpbb_poll_votes GROUP BY topic_id, poll_option_id, vote_user_id HAVING COUNT(*) > 1;
- > several
phpbb_topics_watch
SELECT topic_id, user_id, COUNT(*) AS duplicate_count FROM phpbb_topics_watch GROUP BY topic_id, user_id HAVING COUNT(*) > 1;
- > several
Rest of the tables without PK, have key combinations that can be used as unique key or they have a unique key.
Could this be some historical bug in the board?
(board has been running for several years)
This of course requires, that no duplicate rows exist, for key combinations selected for creating the unique key.
But in my installation, following tables seems to have duplicate rows where they should not exist:
phpbb_acl_groups
SELECT group_id, forum_id, auth_option_id, COUNT(*) FROM phpbb_acl_groups GROUP BY group_id, forum_id, auth_option_id HAVING COUNT(*) > 1;
- > several
phpbb_acl_users
SELECT user_id, forum_id, auth_option_id, COUNT(*) FROM phpbb_acl_users GROUP BY user_id, forum_id, auth_option_id HAVING COUNT(*) > 1;
- > several
phpbb_poll_votes
SELECT topic_id, poll_option_id, vote_user_id, COUNT(*) AS duplicate_count FROM phpbb_poll_votes GROUP BY topic_id, poll_option_id, vote_user_id HAVING COUNT(*) > 1;
- > several
phpbb_topics_watch
SELECT topic_id, user_id, COUNT(*) AS duplicate_count FROM phpbb_topics_watch GROUP BY topic_id, user_id HAVING COUNT(*) > 1;
- > several
Rest of the tables without PK, have key combinations that can be used as unique key or they have a unique key.
Could this be some historical bug in the board?
(board has been running for several years)
Statistics: Posted by Foxina — Mon Oct 14, 2024 6:42 pm