[Mycat expansion plan personal design]

Whether it is Mycat's new data node expansion or reduction, it involves data redistribution. The following picture is the actual hypothetical data distribution.



2. Expansion plan

1) Expansion scheme 1: Add a redundant flag bit field to the table, the default is 0

If I encounter migration data, I first send an SQL statement to change the redundancy flag to 1, indicating that this data needs to be redistributed.

Then expand the capacity, reload the configuration file, and the rest is to process the data whose redundancy flag is 1.

2) Expansion plan 2

<table name="t_gaojs" dataNode="dn1,dn2,dn3" rule="mod-long" />

Split the name attribute into

<table virtualName="t_gaojs" realName="t_gaojs" dataNode="dn1,dn2,dn3" rule="mod-long" />

virtualName corresponds to the table name queried by the sql statement in the program, and realName corresponds to the real name of the data in the database

An important step in the routing process is to replace the virtualName of the query with realName

By default, virtualName and realName="t_gaojs" are equal, so maybe one day the baby is not happy, no need for mycat, if they are not equal, you will be miserable.

Now I encounter a migration situation. After I change the dataNode, I point the realName to another new table realName="t_gaojs_bak"

The new table creation statement can directly copy the old table, and then execute the table creation statement on port 8066 of mycat, and the application is successfully switched over. The remaining situation is to re-insert the historical data to calculate the route, and the historical data needs to be re-inserted.

 Option 2 Advantages:

1) The real table name can be hidden from the application

2) It is not necessary to change the name of the old table one by one. Of course, you can also change the name of the table through mycat8066, and then create a new table, but at this time, you may encounter the situation of locking the table when changing the name of the table, because the application is not stopped, just There are cases where links are swarming.

3) Historical data and new data are temporarily separated, and they can not affect each other, and subsequent rerouting is required by human intervention.

 

 

3. Historical data rerouting

The rest of the work is to re-take the data for routing,

If a reduced node is encountered, the data of the reduced node must be re-routed, similar to the expansion plan 2.

If a new node is encountered, then the retrieved data may still be routed to this node, and no processing is required at this time.

On the contrary, it is necessary to route the data to the new node first, and then delete the piece of data. The whole process should be one thing

 

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326889062&siteId=291194637