分布式事务:

分布式事务需要在多个不同的数据库实例上保证事务的一致性，这在传统的主从复制架构中是一个挑战。PXC通过同步复制和多主复制提供了强一致性，理论上可以简化分布式事务的处理。但由于PXC集群中所有节点都必须参与事务的认证过程，这可能导致在大事务或高并发写入场景下的性能问题。

分库分表:

分库分表是将一个大型的数据库表分割成多个小表的过程，以提高性能和可管理性。在使用PXC时，分库分表可以帮助减轻单个节点的压力，但同时也需要注意，分库分表可能会引入额外的复杂性，尤其是在保证分布式事务一致性方面。PXC集群的强一致性特性能确保分库分表后的数据同步，但在实施分库分表策略时，需要考虑如何有效地管理和维护数据的一致性。

MySQL PXC提供了一种强一致性的解决方案，适合对数据一致性要求极高的业务场景。尽管如此，它在分布式事务和分库分表方面的应用可能会受到性能和复杂性的挑战。在实际应用中，需要仔细评估PXC是否能满足特定业务的需求，并根据实际情况调整分库分表策略以最大化收益。

应该是这门课程吧，https://coding.imooc.com/class/274.html

continue有没有

有异常的信息吧，

解耦、削峰、异步

这个问题，要从底层说起吧，

跨时区的机房，要注意时差问题吧。3地5中心是常用的。

老师, 我项目上跟客户端连的是 虚拟机的ip(192.168.1.104): 5001/5002/5003/5004/5005/5006,但是就是连不上

看起来是网络原因，检查一下服务器和客户端是否有访问控制策略？

可以，跟操作 MySQL 一样

主要看你使用的数据库集群方案和数据库引擎。

看一下你的node的版本

PXC集群中其它节点正常运行时，以从节点的方式将node1重新加入集群。

是的，复制结构

第二个节点闪退，启动不起来

   进入第一个节点容器，查看日志

docker exec -it node1 bash

more /var/lib/mysql/innobackup.backup.log

   查看配置 检查连接的密码

cat /etc/mysql/node.cnf

   发现是用户的问题:没有xtrabackup用户

进入第一个节点，连接mysql 创建xtrabackup用户，授权远程访问，刷新，

 create user xtrabackup identified by 'abc123';

mysql -u root

grant all on *.* to 'xtrabackup'@'%' identified by 'abc123';

flush privileged;

再次启动第二节点，成功！

这些问题不是数据库本身的事务隔离级别处理的吗？PXC数据强一致性方式保证事务在各个节点上要么都执行成功，要么都执行失败。

我也想知道?

单个集群不会出现这种情况，节点过多可以集群分片

补充: docker虚拟机下，pxc集群的数据库配置文件在哪个位置？