https://www.percona.com/blog/attack-no-pk-replication-lag-with-mysql-percona-server-8-invisible-columns/ Wed, 26 Jan 2022 12:49:51 +0000 hourly 1 https://wordpress.org/?v=6.5.2 https://www.percona.com/blog/attack-no-pk-replication-lag-with-mysql-percona-server-8-invisible-columns/#comment-10973512 Wed, 26 Jan 2022 12:49:51 +0000 https://www.percona.com/blog/?p=79796#comment-10973512 Hi Hareesh, That is an interesting question. I think that the simplest answer is that you can’t trust on the 6byte invisible pk. You could delete or insert rows on a replica that could break the replication, and then you will have no tool to fix it. And on the other hand, MySQL will need to be aware about that hidden pk, not just the storage engine, which in this case is InnoDB. With this workaround, we are exposing the pk to MySQL and causing no performance impact to InnoDB.

]]> https://www.percona.com/blog/attack-no-pk-replication-lag-with-mysql-percona-server-8-invisible-columns/#comment-10973509 Tue, 25 Jan 2022 16:07:39 +0000 https://www.percona.com/blog/?p=79796#comment-10973509 Why cant the auto PK ( the invisible 6byte PK ) added by innodb if no PK or candidate Unique is defined be leveraged in binlogs. Yes I understand that the logging exposes this hidden PK

]]> https://www.percona.com/blog/attack-no-pk-replication-lag-with-mysql-percona-server-8-invisible-columns/#comment-10973502 Thu, 20 Jan 2022 08:57:14 +0000 https://www.percona.com/blog/?p=79796#comment-10973502 Hello
I cannot agree more with “What will be awesome is to make MySQL able to detect the missing PK, add it automatically” , so I made a feature request : https://jira.percona.com/browse/PS-8051

]]>