Mysql – MariaDB uses all /tmp space

1 - Yes, Galera takes care of auto increments for you, but you will get lots of missed ids, so make sure your fields are big enough (e.g. you might need a smallint somewhere whereas without missing ids you could have got away with a tinyint).

2 - Yes, no changes should be needed to the application, except for occasionally you might get deadlocks. You should come up with a system to check error messages automatically and if you get errors like Deadlock found when trying to get lock; try restarting transaction and Lock wait timeout exceeded; try restarting transaction then redo the query and it should go through ok. The data will remain consistent. There is also a Galera setting for automatic retries, but we found it was better to try them again yourself. Obviously you shouldn't be using mysql_query() at all, but for the purposes of a simple to follow example, you could swap your queries to use something like this instead of your usual query function

function vio_mysql_query_deadlock_safe($query, $db = null) {
    $deadlock_retries_done = 0;
    $deadlock_retries_max = 10;
    while ($deadlock_retries_done < $deadlock_retries_max) {
        if (is_null($db)) {
            $q = mysql_query($query);
        } else {
            $q = mysql_query($query, $db);
        }
        if ($q === false) {
            $error = mysql_error();
            if ($error == 'Deadlock found when trying to get lock; try restarting transaction' || $error == 'Lock wait timeout exceeded; try restarting transaction') {
                $deadlock_retries_done++;
                continue;
            } else {
                throw new Exception($error . '. Query: ' . $query);
            }
        }
        return $q;
    }
    throw new SQLException($error . '. Re-tried with deadlock ' . $deadlock_retries_done . ' times. Query: ' . $query);
}

You don't provide much information, so I am inferring it from what you say and matching it with a common Galera/Percona XtraDB Cluster/MariaDB Cluster misconception and mistake:

"shutdown the cluster for maintenance and tried to start it again, only the first node will start"

When you stop the cluster fully (something that shouldn't happen under normal circumstances), you need to start the cluster in reverse order. This means: the last node to be down must be the first to start. Why? Because if you are making changes on all nodes, the last one to go down is the one that will get more ahead of the other regarding the transaction UUID. When you shutdown a node normally, the other nodes survive and continue receiving updates. If you now start and create what it is essentially a new cluster from scratch, galera cannot know that the first node that you start is not the "freshest", because you are bootstraping it.

So in short, always check that you do not bootstrap the cluster on a node that is not the last to get shutdown. If you do not know it, here it is a guide on how to do it (along with other useful information on restarting a Galera cluster and other gotchas).

Hope this helps.