Who doesn't like beautiful women and cats

Data Middleware - MyCat2 Configuration File Description

The content of this chapter is based on the MyCat2 version. It will introduce the function of the configuration file in Mycat and some concepts combined with Mycat. Compared with starting the operation blindly at the beginning, and then encountering various problems, it is better to understand the overall situation first to improve efficiency. helpful.

The configuration files of MyCat are stored in conf the path.

server.json server configuration

server.json It is the configuration of Mycat Server. ip, port, mycatId and the like.

users user configuration

users The path stores the configuration of Mycat Server users. That is, which accounts can access MyCat Server, similar to MySQL accounts. There will be a root.user.json configuration file by default. ip The value configured will limit the access IP. transactionType It is the transaction type, and the default is proxy (only supported local transactions) , also supports XA transactions.

{
	"dialect":"mysql",
	"ip":null,
	"password":"123456",
	"transactionType":"proxy",
	"username":"root"
}

datasources data source configuration

datasources The data source configuration file is stored under the path, multiple data sources can be configured, and the name needs to be unique. By default, there will be a prototypeDs.datasource.json prototype data source configuration.

{
	"dbType":"mysql",
	"idleTimeout":60000,
	"initSqls":[],
	"initSqlsGetConnection":true,
	"instanceType":"READ_WRITE",
	"maxCon":1000,
	"maxConnectTimeout":3000,
	"maxRetryCount":5,
	"minCon":1,
	"name":"prototypeDs",
	"password":"root",
	"type":"JDBC",
	"url":"jdbc:mysql://127.0.0.1:3306/mycat?useUnicode=true&serverTimezone=Asia/Shanghai&characterEncoding=UTF-8",
	"user":"root",
	"weight":0
}

partition consists of three parts targetName , schema , table , targetName it can be a cluster or a data source (cluster will be discussed later), schema it is at the physical library level schema , table it is at the physical level table . A simple understanding of this diagram is that the MyCat side partitions the logical tables, and accesses the tables in the physical library through clusters or data sources.

clusters cluster configuration

clusters The cluster configuration is stored under the path. By default there will be a prototype.cluster.json configuration file. A cluster is a data source cluster composed of multiple data sources. In the cluster, you can do failover, load balancing, etc. Higher availability than data sources. masters Multiple master nodes and multiple slave nodes can be configured in the cluster replicas . where the configured value is datasource the name of the . Looking at the above picture here, you can understand why targetName it can be cluster or datasource , and their functions are used to access the physical library.

{
	"clusterType":"MASTER_SLAVE",
	"heartbeat":{
		"heartbeatTimeout":1000,
		"maxRetry":3,
		"minSwitchTimeInterval":300,
		"slaveThreshold":0
	},
	"masters":[
		"prototypeDs"
	],
        "replicas":[//配置多个从节点
		"xxxx"
	],
	"maxCon":200,
	"name":"prototype",
	"readBalanceType":"BALANCE_ALL",
	"switchType":"SWITCH"
}

The mapping relationship between schemas logical tables and physical tables

schemas The mapping relationship between logical tables and physical tables is stored under the path. Let's first understand what is a logical table and what is a physical table.

What the MyCat end exposes to the client is the logical table, because the data is split horizontally, and the data written to the logical table will be written into the corresponding real physical table through the fragmentation strategy.

For example, we now have such a table (logical table and physical table structure should be consistent)

CREATE TABLE employee (
  id INT PRIMARY KEY,
  name VARCHAR(100) NOT NULL
);

Now we have two physical libraries, each with two physical tables, we execute an insert statement on the client

INSERT INTO employee (id, name) VALUES (1, 'DevX');

We use the modulo (%) sharding algorithm based on the id value. At this time, the sharding process is like this

1 % 2 = 1 select the corresponding physical library
1 % 2 = 1 Select the corresponding physical table

So this piece of data will eventually be written to the physical table database_1 in employee_1 .

Example with information_schema.schema.json file

schemaName Physical database name
targetName Cluster or data source name
customTables Define custom table mapping rules, which can map custom SQL statements to physical tables. This configuration is generally used for some special query requirements, such as multi-table association query, view query, stored procedure, etc. Through custom table mapping rules in MyCAT, these special requirements can be converted into standard SQL statements, so as to realize data query. queries and operations.
globalTables Define global table rules, a global table is a special table that can share data between different logic libraries, that is, you can insert, update, and delete data in one logic library, and query these in another logic library data. By defining globalTables, tables in multiple logic libraries can be defined as global tables, thereby realizing the function of data sharing.
normalProcedures Define common stored procedure rules. Ordinary stored procedures are SQL scripts that can be executed on the MyCAT server, and the efficiency of SQL execution can be improved through precompilation and caching operations. By defining normalProcedures, multiple normal stored procedures can be defined as common stored procedures in a logic library, which facilitates the calling and execution of SQL statements.
normalTables Define common table rules. A common table is a virtual table corresponding to a physical table in a MySQL instance, and performs routing and forwarding operations on the MyCAT server.
shardingTables Define the table that needs to be sharded.

{
  "customTables": {},
  "globalTables": {},
  "normalTables": {
    "ROUTINES": {
      "createTableSQL": "CREATE TABLE information_schema.ROUTINES (\n\tSPECIFIC_NAME varchar(192),\n\tROUTINE_CATALOG varchar(192),\n\tROUTINE_SCHEMA varchar(192),\n\tROUTINE_NAME varchar(192),\n\tROUTINE_TYPE varchar(27),\n\tDATA_TYPE varchar(1024),\n\tCHARACTER_MAXIMUM_LENGTH  bigint(21),\n\tCHARACTER_OCTET_LENGTH bigint(21),\n\tNUMERIC_PRECISION bigint(3),\n\tNUMERIC_SCALE bigint(3),\n\tDATETIME_PRECISION bigint(3),\n\tCHARACTER_SET_NAME varchar(12),\n\tCOLLATION_NAME varchar(12),\n\tDTD_IDENTIFIER varchar(255),\n\tROUTINE_BODY varchar(255),\n\tROUTINE_DEFINITION varchar(255),\n\tEXTERNAL_NAME varchar(255),\n\tEXTERNAL_LANGUAGE varchar(255),\n\tPARAMETER_STYLE varchar(255),\n\tIS_DETERMINISTIC varchar(255),\n\tSQL_DATA_ACCESS char(64),\n\tSQL_PATH varchar(255),\n\tSECURITY_TYPE varchar(255),\n\tCREATED datetime,\n\tLAST_ALTERED datetime,\n\tSQL_MODE varchar(80),\n\tROUTINE_COMMENT varchar(12),\n\tDEFINER varchar(64),\n\tCHARACTER_SET_CLIENT varchar(64),\n\tCOLLATION_CONNECTION varchar(64),\n\tDATABASE_COLLATION varchar(64)\n)",
      "locality": {
        "schemaName": "information_schema",
        "tableName": "ROUTINES",
        "targetName": "prototype"
      }
    },
    "PARAMETERS": {
      "createTableSQL": "CREATE TABLE information_schema.parameters (\n\tSPECIFIC_CATALOG varchar(64),\n\tSPECIFIC_SCHEMA varchar(64),\n\tSPECIFIC_NAME varchar(64),\n\tORDINAL_POSITION bigint(11) UNSIGNED,\n\tPARAMETER_MODE varchar(5),\n\tPARAMETER_NAME varchar(64),\n\tDATA_TYPE longtext,\n\tCHARACTER_MAXIMUM_LENGTH bigint(21),\n\tCHARACTER_OCTET_LENGTH bigint(21),\n\tNUMERIC_PRECISION int(10) UNSIGNED,\n\tNUMERIC_SCALE bigint(11),\n\tDATETIME_PRECISION int(10),\n\tCHARACTER_SET_NAME varchar(64),\n\tCOLLATION_NAME varchar(64),\n\tDTD_IDENTIFIER mediumtext,\n\tROUTINE_TYPE enum('FUNCTION', 'PROCEDURE')\n)",
      "locality": {
        "schemaName": "information_schema",
        "tableName": "PARAMETERS",
        "targetName": "prototype"
      }
    },
    "CHARACTER_SETS": {
      "locality": {
        "targetName": "prototype"
      }
    },
    "COLLATIONS": {
      "locality": {
        "targetName": "prototype"
      }
    },
    "COLLATION_CHARACTER_SET_APPLICABILITY": {
      "locality": {
        "targetName": "prototype"
      }
    }
  },
  "schemaName": "information_schema",
  "shardingTables": {}
}

sequences serial number configuration

sequences The configuration of the rules for generating serial numbers is stored under the path.

If you do not need to use the auto-increment sequence of mycat, but use the auto-increment primary key function of mysql itself, you need to change the corresponding table-building sql in the configuration, and do not set the AUTO_INCREMENT keyword, so that mycat does not think that this table has an auto-increment primary key function, the global serial number of mycat will not be used.

The table-building SQL can be automatically obtained from the physical table of the logical table corresponding to the prototype library. If the table-building SQL of the logical table does not correspond to the table-building SQL of the physical table, you need to configure the table-building SQL in the configuration file.

DevX I will continue to share interesting technologies and insights. If you think this article is helpful to you, I hope you can share it with more friends. This article will be synchronized on the WeChat public account [DevXJava], which is convenient for reading on the WeChat client.

DevX is more than technology

DevXJava