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.
662254	Multiplex coordinator could deadlock with insufficient SA worker threads to service freelist requests – If you use IQ multiplex with DQP, the default setting of -gn is not enough to guarantee that some worker threads will always be available to service this request. Workaround – Set the -gn server startup flag. Calculate `GNn` considering the number of multiplex servers (`Sn`), the INC connection pool size on each secondary server (see database option `Mpx_Max_Connection_Pool_Size`, which defaults to 10 (`INCPn`)), and the number of user connections (`GMn`). The formula is: GNn = (Sn * INCPn) + GMn + 5 For example, if you have 20 multiplex servers with a `Mpx_Max_Connection_Pool_Size` of 10 and -gm is set to 50, then you set -gn to 255. If you are running the coordinator on a host that has greater than 32 cores, then you must set -iqmt. Make sure that the value of -iqmt is less than `(4000 - (GNn + 200))` to ensure that the total number of threads spawned by IQ does not exceed 4000.
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.