Outage issues

A SQL broker stops

Nothing is lost: the clients connect another SQL broker and send again their select, describe and show. A statement that changes data is not sent again by the client: it tells the user that it may or may not have been executed. Start synsqld again on the machine.

A data broker stops

• A table with several copies goes on working on the other copies. The copy that missed writes is marked out of date: when the data broker is back, lock the table and run repair table T;.
• A table with one copy is unavailable: statements on it fail with One partition of this table is unavailable. When the data broker is back with its data, alter table T set segments up; makes the segments usable again.
• alter databroker NAME set offline; tells the cluster to stop using a broker that you know is down or being maintained. set online puts it back.

A master broker stops

The other master brokers keep the dictionary. The statements that change the dictionary succeed with a warning that says on how many master brokers they failed. Put the broker back, or replace it with create masterbroker.

A deployment ends in error

Statements to create the first segment fail: the table stays as before, correct the cause and deploy again. If a later segment fails, the table is locked and the answer says so. Do not use it. Either drop it and create it again, or fix the data brokers and run deploy table T retry;.

The license expired

A broker stops when its license has expired. Download the new one with download license; from a broker that is still running, or copy license.txt into the etc directory of every SQL broker (see download), and start the brokers again.

Messages about signatures or time

The brokers sign what they say to each other, with the time. If a broker's clock is more than two minutes off, its messages are refused. Check NTP.

The log

Each synsqld writes to nohup.out. alter server set log level N; changes its detail level.