我想在我们的生产环境中使用Galera集群，但我有一些顾虑;
每个表必须至少定义一个显式主键。
每个表必须在InnoDB或XtraDB存储引擎下运行。
批量整理您的大交易。例如，不是让一个事务插入100,000行，而是将其分解成更小的块，例如，每个事务插入1000行。
您的应用程序可以容忍非连续的自动增量值。
架构更改的处理方式不同。
通过向单个节点发送写入来处理热点/ Galera死锁。
我想对上述所有要点做一些澄清。我们还有600多个数据库正在制作中，galera能否在这个环境中工作？
答案 0 :(得分：0)
一次性处理 LOT 。有两个问题，表创建（invloves Schema ，请参阅第5点）和使用这些表的应用程序。我会尝试：
1）每个表必须至少定义一个显式主键。
创建表格时，您不能拥有不会拥有主键的表格。使用字段和INDEXES创建表。其中一个索引必须声明为PRIMARY KEY。
2）每个表必须在InnoDB或XtraDB存储引擎下运行。
创建表格时，必须有ENGINE=InnoDB或ENGINE=XtraDB。 Galera不处理默认的MyISAM类型表
3）批量整理您的大交易。例如，而不是 让一个事务插入100,000行，将其分解为更小的行 例如，每个事务插入1000行。
这与您的架构无关，而与您的应用程序无关。尽量不要在INSERT中拥有transaction大量数据的应用程序。 注意这会起作用，但风险很大。这是 NOT 一项要求，但建议。
4）您的应用程序可以容忍非连续的自动增量值。
使用群集，您可以更新多个服务器。如果字段自动递增，则每个集群成员可能尝试递增相同的字段。您的应用程序永远不会假设下一个ID与之前的ID相关。对于自动增量字段，请不要强制一个值，让数据库处理它。
5）模式更改的处理方式不同。
Schema 是表和索引的描述，而不是添加，删除或检索信息的事务。您有多个服务器，因此必须小心处理架构更改，以便所有服务器都能赶上。
6）通过向单个节点发送写入来处理热点/ Galera死锁。
这与应用程序和数据库相关。死锁是一个应用程序的2个不同部分试图获取值（ValueA）的条件，因为数据库要锁定它以便可以更改它，然后尝试获取另一个值（ValueB）用于相同的用途。如果另一部分尝试使用First Lock ValueB，然后是ValueA，我们就会遇到死锁，因为每个应用都锁定了另一个应用的 next 值。为避免这种情况，最好只写入群集中的一台服务器，并使用其他服务器进行读取。请注意，您的应用程序中仍然可能存在死锁。但你可以避免Galera创造这种情况。