i have a question.
@1116 This is expected as per the documented Production considerations for transactions in sharded clusters.
Arbiters are not supported for multi-shard transactions:
On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.
The reasoning behind this is that arbiters help maintain a quorum of voting members if a voting secondary is unavailable, but cannot contribute to acknowledging majority write concern since they do not store any data. Without majority write acknowledgement, data could potentially be rolled back which would go against one of the guarantees of transactions (all-or-nothing commit semantics).
The solution for this would be to replace your arbiters with data-bearing secondaries, which will provide more resilience and consistent majority write behaviour in the event a voting member of a replica set is unavailable.
Regards,
Stennie
2 Likes