# Errors in the process of installing Magento 2 on Percona XtraDB Cluster

**URL:** <https://forums.percona.com/t/errors-in-the-process-of-installing-magento-2-on-percona-xtradb-cluster/26897>\
**Category:** Percona XtraDB Cluster 8.x\
**Created:** [December 1, 2023, 11:14am UTC](https://forums.percona.com/t/errors-in-the-process-of-installing-magento-2-on-percona-xtradb-cluster/26897 "2023-12-01T11:14:58Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![cks](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/cks/32/18388_2.png) [@cks](https://forums.percona.com/u/cks)\
**Post date:** [October 6, 2024, 3:02am UTC](https://forums.percona.com/t/errors-in-the-process-of-installing-magento-2-on-percona-xtradb-cluster/26897/3 "2024-10-06T03:02:54Z")

</div>

Thanks @daniil.bazhenov . I ran into the exact same issue as you. Thought about using `SET GLOBAL pxc_strict_mode=PERMISSIVE;` as well, but are concerned about the implications outlined in this Percona document.

> **[How Missing Primary Keys Break Your Galera Cluster](https://www.percona.com/blog/how-missing-primary-keys-break-your-galera-cluster/)**
>
> Any Galera documentation states that missing primary keys are not properly supported. What is the actual risk, and what are the symptoms?

The recommendation from that blog post is to ensure every table, and in this case, Magento’s `magento3.queue_poison_pill` has a primary key. So by setting the permission as `PERMISSIVE` during installation, I am concerned about data integrity issues in the Magento day-to-day operation post-installation, especially given the comment by @vadimtk [here](https://forums.percona.com/t/dml-command-rejected-when-pxc-mode-set-to-enforcing/5390/2).

Do you set the pxc\_strict\_mode back to `ENFORCING` post-installation?

In a Github ticket in the Magento repo about this issue:  
`https://github.com/magento/magento2/issues/33822`

the Magento dev said

> The **queue\_poison\_pill** table will always have a single version entry, which is basically just a random hash. If some configuration value gets changed using the Magento backend, the poison pill version is changed. The running consumer processes check on this version, but only when a new message is in the queue. So in this case we have a natural key **version** that hold the single unique entry.  
> In code base the **version** is treated as the **idFieldName**.  
> `protected function _construct()`  
> ` {`  
> ` $this->_init(self::QUEUE_POISON_PILL_TABLE, 'version');`  
> ` }`

In my somewhat limited DB vocabulary, it feels that they are saying a primary key isn’t needed since there is only one row/ entry in the table. But I want to share this in case your read is different. Thanks.

I don’t know yet if any other tables in Magento is missing the primary key. I will check tonight. Does `PERMISSIVE` affect the data integrity of other tables that already have primary keys?

---

_[View the full topic](https://forums.percona.com/t/errors-in-the-process-of-installing-magento-2-on-percona-xtradb-cluster/26897)._