This happens when you have a Spider table defined that does not point to an existing table on a data node.
myisam-recover=FORCE,BACKUP
This is used by Spider monitoring to ask other monitoring nodes the status of a table.
Not having a primary key will generate errors for resynchronizing tables via spider_copy_table().
Yes, XA transactions can be disabled from Spider. Until Galera 4.0 fully supports xa transactions, spider can point to a maxscale proxy that can manage transparent node election in case of failure inside a shard group. Note that disabling XA will break cross shard WRITES in case of transaction ROLLBACK. This architecture need to be used with care if you have a highly transactional workload that can generate cross shard deadlocks.
Delegation of shard node replication using asynchronous replication and slave election with GTID.
Delegation of shard node replication via active passive HA solutions.
Shard builds via replication into Spider tables is interesting when you can route READS to a pool of Spider nodes reattaching the shards.
Map reduce in Spider is limited to a single table. Building spider on top of some views can eliminate the need to use joins.
Replication to universal tables to every shard is commonly used to enable the views on each shard.
When using MRR and BKA (and you do so with network storage), when Spider needs to create temporary tables on the backends, use the CREATE TEMPORARY TABLES privilege. Spider can still switch to a lower performance solution using spider_bka_mode=2, or Query push down or range predicate using spider_bka_mode=0
This page is licensed: CC BY-SA / Gnu FDL