InnoDB 引擎在使用页面压缩时，严重依赖于文件系统对稀疏文件的支持。InnoDB 页面压缩。
它提出了一个问题，mariabackup/xtrabackup 将如何处理那些 InooDB 稀疏文件
--backup--prepare--copy-back操作？
假设我们总共有 100G InnoDB 表，（ls报告 100G 但du报告 0.5G）。提出以下问题：
当我--backup使用 mariabackup/xtrabackup 时，备份本身会在目标目录中稀疏吗？
当我--prepare使用 mariabackup/xtrabackup 时，结果会很稀疏吗？
当我--copy-back使用 mariabackup/xtrabackup 时，结果将是稀疏的
说 mariabackup/xtrabackup 不处理稀疏文件。（悲剧）。我可以用 using cp --sparse=alwaysinstead of来纠正这种行为吗，mariabackup --copy-back ...或者这不是那么简单......
在下面的 MariaDB 官方博客Getting Started with MariaDB Galera and MariaDB MaxScale中，作者在三节点 Galera 集群上配置了 MaxScale 主机，并使用了 Galer 监视器（OK）和读写分离路由器，
我不清楚，如果我在所有节点上平均（或可选地加权）分布所有事务，包括写入，为什么我还要费心拆分读取和写入？这种增加的复杂性有什么好处？
在性能方面，首选 MaxScale 路由器是什么？
在第一个用例的官方文档Galera Use Cases中，我阅读了以下内容：
“传统的 MariaDB 主从拓扑，但对于Galera，所有“从属”节点在任何时候都是有能力的主节点——只是将它们视为从属节点的应用程序。Galera 复制可以保证此类安装的零从属滞后，并且由于并行从属节点应用，集群的吞吐量要好得多。”
不清楚，为什么任何应用程序都应将除一个节点以外的所有节点都视为从节点？它需要额外的努力来拆分读取和写入 SQL 命令，如果可能的话，我的意思是取决于应用程序开发风格。（我确实知道 MaxScale readwritesplit，但这不是这里的主题）
问题
为什么任何应用程序都应将除一个节点之外的所有节点都视为 Galera 集群中的从属节点？
我试图了解时间点恢复的确切工作流程，或者更一般地使用二进制日志进行备份/恢复（意思是：使用二进制日志文件）这很重要，不仅因为mysqlbinlogPITR，而且使用二进制日志如果数据文件丢失，但不会丢失上次备份的二进制日志，这种情况下我可以从备份中恢复，然后“应用”未丢失的当前二进制日志文件中的剩余更改。
我确实理解从可用备份中离线恢复的主要概念，然后使用 mysqlbinlog 从二进制日志应用进一步的更改。
有两件事我不清楚：
当我到处看到mysqlbinlog <files>.... | mysql -u ...它时，它表明服务器必须运行并在线。我如何确保在我离线恢复某些状态后，服务器保持该状态并且我的管道 SQL 语句是服务器上唯一独占执行的语句？
另一件我找不到答案的事情是，我如何从应该执行的 binlog 语句中确定和应用这个 lsn？我知道我可以从服务器查询当前的 lsn 例如SHOW MASTER STATUS;，假设我从上次备份中恢复了一些离线状态，然后以某种方式设法专门连接我的服务器（如何？），然后询问当前的 lsn。现在我如何参数化 mysqlbinlog 从那个位置开始？它的命令行开关似乎可以从日期或行号开始......