How to find the appropriate column for the Sharding Key depends on the query of your application. It is mainly set as a commonly used join key or a condition key in the where clause. If you use a composite sharding key, the desired performance may not be achieved.

No, you can use it as an Active-Standby just by setting up the Client. The Goldilocks Cluster is enabled by default as Active-Active. You can use it as an Active-Standby if you collect clients that perform DML only to one side In addition, if you are using Global Connection, you can adjust the A-A/A-S with the 'LOCALITY_MEMBER_POLICY' property.

Control files, data files, and log files are stored on each cluster member. Backup files vary depending on site policy, but typically each group stores a backup file.

Primary Key, Unique Constraints, and Unique Index for Shared Tables must include the Sharding Key

GOLDILOCKS allows online Scale In/Out. When a new cluster group is added, the shard data is redistributed accordingly, and this redistribution time varies greatly depending on the amount of data and hardware specifications. Moving a shard or synchronizing data may cause CPU and network load on the corresponding node. Also, when processing the last journal data (default 10MB) during the rebalancing process, a table lock is acquired, so it is recommended to perform the work during a time when there are relatively few transactions.

No LOCK is placed on the table on which data rebalancing is being performed. When a transaction occurs on the table, the transaction Recorded to disk through journaling, and after rebalancing is completed This is how journaled transactions are performed. However, when reflecting the last Journal data (default 10MB), a lock is placed on the table. Also, depending on the amount of data or table Since it is not possible to completely avoid system overload, We recommend that you perform this task during times of relatively low transaction volume.

If all members of a Group are disabled, the data in that Group becomes inaccessible. It is only possible to perform queries on data excluding the group in question.

In Goldilocks' Cluster environment, all members within a Group have the same data, Because it is a Shared Nothing structure, continuous operation is possible through other nodes in case of node failure. For example, in an environment configured as 1by2, even if a G1N1 device fails, Failover occurs to G1N2 with the same data. This is done by gmaster's Failover Thread. It handles failover, including offline processing for failed nodes and selection of a coordinator. Coordinator is a concept that ensures data consistency within a cluster system. It can be viewed as a Master concept responsible for commit/rollback processing.

Provides automatic failover/failback when configuring a cluster. In an environment where there are two members for one group (called G1N1 and G1N2), While establishing a connection/session with G1N1, If a G1N1 node fails, the glocator or location file is defined A connection to G1N2 is made using alternative information (G1N2 information). Also, when recovering G1N1, connections to G1N2 are not automatically moved to the G1N1 node. In case of a failure of G1N2, the connection to G1N1 proceeds in the same way. Therefore, atlernative information usually records information about all nodes. DB service can be operated without interruption.

Backup methods include Hot (Online) Backup and Cold (Offline) Backup. Among them, Hot Backup is the most used. This is a method of backing up during DB operation. This is a method that uses the commonly used ALTER DATABASE BEGIN / END BACKUP commands. It must be in archive log mode and tablespace and datafile related operations cannot be performed.

The point in time when it is flushed to the disk is the point in time when it is written to the Redo Log File. Gmaster's Page Flusher Thread distributes/controls dirty pages. The Log Flusher Thread periodically flushes the online Redo Log File. It is performed in the background so it does not affect the service.

• GOLDILOCKS's memory allocation is as follows: 1. TABLESPACE size A. It uses the same amount of memory as the sum of each TABLESPACE. i. DICTIONARY Tablespace ii. UNDO Tablespace iii. DATA Tablespace iv. TEMP Tablespace 2. SSA(SHARED STATIC AREA) area A. This is the memory area where information shared across all sessions in the system is stored. (Among these, Log buffer and Plan cache can be controlled using properties) i. Log buffer ii. Plan cache iii. Dictionary cache iv. Session pool v. Lock pool vi. Transaction pool 3. PSA ( PRIVATE STATIC AREA ) area A. This is a heap memory area used independently for each session. 4. gserver A. Memory occupied by the ggserver process B. Allocate about 13~15MB per gserver.

The DML autocommit related part is a setting at the connection level, not at the DB level. Both ODBC/JDBC have a default autocommit mode as a standard. Because our Goldilocks follows these DBC standards: The default is autocommit. When using commit & rollback explicitly You can turn off autocommit like this: <ODBC> SQLSetConnectAttr( sDbc,                    SQL_ATTR_AUTOCOMMIT,                    (SQLPOINTER)SQL_AUTOCOMMIT_OFF,                    SQL_IS_UINTEGER ); <JDBC> con.setAutoCommit(false);

You can log by setting the TRACE_LOG_ID value in the manual. Whether successful SQL queries are output, whether failed SQL queries are output, whether execution plans are output, whether execution types (direct/prepare) are output, whether Bind values are output, whether execution times are output by section Typically, GOLDILOCKS trace log records the contents along with the occurrence time, process name, thread ID, etc. The server properties related to logs are as follows: - TRACE_ALTER_SYSTEM: Records contents related to alter system statements in the trace file, which does not affect DML performance. - TRACE_DDL: Records SQL statements for DDL statements in a trace file, and this also does not affect DML performance. - TRACE_LOG_ID: Determines the output information according to the flag according to the information written above.

You can set it with the following gsql/gsqlnet options: \SET AUTOTRACE ON

In gsql/gsqlnet, you can check with \ddl_* syntax such as \ddl_table \ddl_procedure In external tools, you can check with the command below. SELECT * FROM ALL_SOURCE ; SELECT * FROM ALL_SOURCE WHERE 1 = 1 AND NAME = ;

If FAILOVER_TYPE is set to Session in ODBC and JDBC, transactions in progress on the failed node will be automatically processed on the normal node when a DB node fails. However, if an error like the one below occurs, you can add logic to perform execute without performing prepare. In case of ODBC - 19068 (Retry the transactional operations) In case of JDBC - 21047 (Retry the transactional operations again)