Multiplex Environment

Descriptions of known issues and workarounds for the multiplex environment.

Multiplex issues
CR#	Description
666417	Secondary node unresponsive after emergency shutdown – When a secondary node is not able to resolve a dynamic collision, an emergency shutdown may be necessary. In some circumstances, the server may become unresponsive during this emergency shutdown. Workaround – Kill the server process, resynchronize, and restart the server.
666312, 666038	When DQP is enabled and all servers are participating in DQP there are some known problems you may encounter – When the multiplex coordinator participates in distributed query processing (DQP) under stress conditions, the server may become unresponsive. If a query is using a table which was modified in the same transaction, and has uncommitted data, and if the worker nodes are heavily loaded, there is a small timing window in which the leader node may abort. Workaround – To avoid these issues, Sybase recommends you create logical servers to control which servers within the multiplex can participate in DQP. Sybase recommends that the coordinator does not participate in DQP and is not a part of the logical server. In addition, do not run batch loads or transactions that deal with read-write operations like LOAD, INSERT, UPDATE or DELETE in IQ base tables on a logical server that contains more than one physical server. The write batches should run on a single physical machine. By ensuring that all your read-write transactions are done on a single server with the use of logical servers, you will not run the risk of hitting this timing window. The issue can also be prevented by temporarily disabling DQP by calling set temporary option dqp_enabled= 'off' before starting your read-write transaction, or batch load, and setting it back to 'on' only after a commit or rollback.
665069	Multiplex reader may become unresponsive trying to access a shared temporary dbspace. – If you add a new file to IQ_SHARED_TEMP that is not visible to a secondary server that is already participating in DQP, it may cause that secondary server to fail. Workaround – Drop this file from the coordinator and add it back with the file path that is visible to all nodes. Synchronize and restart the secondary nodes.
611990	Emergency shutdown on secondary servers after CREATE TEXT INDEX – A secondary server goes into emergency shutdown, when: It is started with the -sf external_library_full_text flag, which disables loading of external libraries, and The user issues a CREATE TEXT INDEX statement on the coordinator with a text configuration that uses external libraries. All other servers replay the DDL successfully. Workaround – Start secondary nodes in the multiplex without the -sf external_library_full_text flag.
557714	Emergency shutdown on secondary servers after creating a proxy table – A timing problem may cause an emergency server shutdown when a user accesses a new proxy table on a secondary server. Workaround – Either reconnect or wait for some time and start another transaction, before trying to use a newly-created proxy table.