Explication détaillée du code de schéma du cluster distribué MySQL MyCAT (2)-tutoriel mysql-php.cn

Dans la première partie, il y a une brève introduction à la situation de base des fichiers de construction et de configuration MyCAT. Cet article détaille certains paramètres spécifiques du schéma et sa fonction réelle
Post. en premier Dans le fichier de schéma pour mes propres tests, la barre oblique inverse avant le guillemet double ne sera pas éliminée. Faisons comme si elle n'existait pas...

<?xml version=\"1.0\"?>
<!DOCTYPE mycat:schema SYSTEM \"schema.dtd\">
<mycat:schema xmlns:mycat=\"http://org.opencloudb/\">
    <schema name=\"mycat\" checkSQLschema=\"false\" sqlMaxLimit=\"100\">
        <!-- auto sharding by id (long) -->
        <table name=\"students\" dataNode=\"dn1,dn2,dn3,dn4\" rule=\"rule1\" />
        <table name=\"log_test\" dataNode=\"dn1,dn2,dn3,dn4\" rule=\"rule2\" />
        <!-- global table is auto cloned to all defined data nodes ,so can join 
            with any table whose sharding node is in the same data node -->
        <!--<table name=\"company\" primaryKey=\"ID\" type=\"global\" dataNode=\"dn1,dn2,dn3\" />
        <table name=\"goods\" primaryKey=\"ID\" type=\"global\" dataNode=\"dn1,dn2\" />
            -->
        <table name=\"item_test\" primaryKey=\"ID\" type=\"global\" dataNode=\"dn1,dn2,dn3,dn4\" />
        <!-- random sharding using mod sharind rule -->
        <!-- <table name=\"hotnews\" primaryKey=\"ID\" dataNode=\"dn1,dn2,dn3\"
            rule=\"mod-long\" /> -->
            <!-- 
        <table name=\"worker\" primaryKey=\"ID\" dataNode=\"jdbc_dn1,jdbc_dn2,jdbc_dn3\" rule=\"mod-long\" />
 -->
        <!-- <table name=\"employee\" primaryKey=\"ID\" dataNode=\"dn1,dn2\"
            rule=\"sharding-by-intfile\" />
        <table name=\"customer\" primaryKey=\"ID\" dataNode=\"dn1,dn2\"
            rule=\"sharding-by-intfile\">
            <childTable name=\"orders\" primaryKey=\"ID\" joinKey=\"customer_id\"
                parentKey=\"id\">
                <childTable name=\"order_items\" joinKey=\"order_id\"
                    parentKey=\"id\" />
            <ildTable>
            <childTable name=\"customer_addr\" primaryKey=\"ID\" joinKey=\"customer_id\"
                parentKey=\"id\" /> -->
    </schema>
    <!-- <dataNode name=\"dn\" dataHost=\"localhost\" database=\"test\" /> -->
    <dataNode name=\"dn1\" dataHost=\"localhost\" database=\"test1\" />
    <dataNode name=\"dn2\" dataHost=\"localhost\" database=\"test2\" />
    <dataNode name=\"dn3\" dataHost=\"localhost\" database=\"test3\" />
    <dataNode name=\"dn4\" dataHost=\"localhost\" database=\"test4\" />
    <!-- 
    <dataNode name=\"jdbc_dn1\" dataHost=\"jdbchost\" database=\"db1\" />
    <dataNode name=\"jdbc_dn2\" dataHost=\"jdbchost\" database=\"db2\" />
    <dataNode name=\"jdbc_dn3\" dataHost=\"jdbchost\" database=\"db3\" />
 -->
    <dataHost name=\"localhost\" maxCon=\"100\" minCon=\"10\" balance=\"1\"
        writeType=\"1\" dbType=\"mysql\" dbDriver=\"native\">
        <heartbeat>select user()<beat>
        <!-- can have multi write hosts -->
        <writeHost host=\"localhost\" url=\"localhost:3306\" user=\"root\" password=\"wangwenan\">
            <!-- can have multi read hosts -->
            <readHost host=\"hostS1\" url=\"localhost:3307\" user=\"root\" password=\"wangwenan\"/>
        </writeHost>
        <writeHost host=\"localhost1\" url=\"localhost:3308\" user=\"root\" password=\"wangwenan\">
            <!-- can have multi read hosts -->
            <readHost host=\"hostS11\" url=\"localhost:3309\" user=\"root\" password=\"wangwenan\"/>
        </writeHost>
    </dataHost>
        <!-- <writeHost host=\"hostM2\" url=\"localhost:3316\" user=\"root\" password=\"123456\"/> -->
    <!-- 
        <dataHost name=\"jdbchost\" maxCon=\"1000\" minCon=\"1\" balance=\"0\" writeType=\"0\" dbType=\"mongodb\" dbDriver=\"jdbc\">
        <heartbeat>select user()<beat>
        <writeHost host=\"hostM\" url=\"mongodb://192.168.0.99/test\" user=\"admin\" password=\"123456\" ></writeHost>
    </dataHost>    
    -->
     <!-- 
    <dataHost name=\"jdbchost\" maxCon=\"1000\" minCon=\"10\" balance=\"0\"
        dbType=\"mysql\" dbDriver=\"jdbc\">
        <heartbeat>select user()<beat>
        <writeHost host=\"hostM1\" url=\"jdbc:mysql://localhost:3306\"
            user=\"root\" password=\"123456\">
        </writeHost>
    </dataHost>
     -->
</mycat:schema>

Copier après la connexion

Première ligne de paramètres<nom du schéma ="mycat" checkSQLschema="false" sqlMaxLimit= "100"/>
Dans cette ligne de paramètres, le nom du schéma définit le nom de la base de données logique qui peut être affiché sur le front-end de MyCAT ,
Lorsque le paramètre checkSQLschema est False, cela indique que MyCAT ignorera automatiquement le nom de la base de données avant le nom de la table. , mydatabase1.test1 sera considéré comme test1;
sqlMaxLimit spécifie la limite du nombre de lignes renvoyées par l'instruction SQL;
🎜>

À titre de capture d'écran, cette limite permettra à mycat d'ajouter automatiquement une LIMIT lors de la distribution de l'instruction SQL, limit Comme vous pouvez le voir dans le coin supérieur droit, MyCAT lui-même est mis en cache
; Donc, si l'instruction que nous exécutons renvoie plus de lignes de données, que fera MyCAT sans modifier cette limite ?                                                          >, Ainsi, si une grande quantité de données doit être renvoyée dans l'application réelle, vous devrez peut-être le faire manuellement changer la logique

Dans la version 1.4 de mycat, le paramètre Limit de l'utilisateur couvrira le paramètre MyCAT par défaut
> ----- ------------------------------------------------ ------- ------------------------------------------------ ------- ------------------------------------------------ ------- ---------------------------                                                                   >tableau nom
="étudiants" dataNode

=
"dn1,dn2,dn3,dn4" règle="rule1" /> Cette ligne représente laquelle les noms de table seront affichés sur le front-end de MyCAT ? Les lignes similaires signifient toutes la même chose. L'accent est mis ici sur la table, et MyCAT ne définit pas la structure de la table dans le fichier de configuration Si vous utilisez show create table sur. le front-end, MyCAT affichera normalement les informations sur la structure de la table, observez le journal de débogage,    On peut voir que MyCAT distribue la commande à la base de données représentée par dn1, puis renvoie le résultat de la requête de dn1 au front-end
On peut juger que certaines instructions de requête similaires au niveau de la base de données peuvent être distribuées à un certain nœud séparément.Renvoyez ensuite les informations d'un certain nœud au front-end;dents Stratégie de segmentation spécifique, actuellement MyCAT ne prend en charge que la segmentation selon une colonne spéciale et en suivant certaines règles spéciales, telles que modulo, énumération, etc. plus tard

---------- -------------------------------------- ------------ -------------------------------------- ------------ -------------------------------------- ------------ ----------
                                                                                                                                                                 nom

=

"item_test" clé primaire="ID" type ="global" dataNode="dn1,dn2,dn3,dn4" /> Cette ligne représente la table globale, ce qui signifie que la table item_test aura des copies complètes des données dans les quatre dataNodes, puis sera-t-elle distribuée à toutes les bases de données lors de la requête ?                                                                                                                                                                                                                                                                                       La requête de la table ne sera distribuée qu'à un certain nœud La clé primaire configurée n'est pas utilisée, alors ignorez-la pour l'instant, je l'ajouterai si je la trouve plus tard ---------- ------------------------------------------ ------------- ----------------------------------------- ------------- ----------------------------------------- ------------- -------------Je n'ai pas réellement utilisé childtable dans le test, mais il a été mentionné dans le document de conception de MyCAT que childtable est une structure qui dépend de la table parent
Cela signifie que la clé de jointure de childtable suivra la stratégie parentKey de la. table parent. Divisez-les ensemble. Lorsque la table parent est connectée à la table enfant et que la condition de connexion est childtable.joinKey=parenttable.parentKey, la connexion entre bases de données ne sera pas effectuée. --------------------------------------------- ---------- --------------------------------------------- ---------- --------------------------------------------- ---------- -------------

Les paramètres de dataNode ont été introduits dans le chapitre précédent, alors passez ici~

--------- ----------------------------------------- --------- ----------------------------------------- --------- ----------------------------------------- --------- -----------------

dataHost configure le cluster de base de données back-end réel. La plupart des paramètres sont simples et faciles à comprendre. Voici ce que je ne présenterai pas. les un par un. Je ne présenterai que les deux paramètres les plus importants, writeType et balance. Configuration du cluster à partir de

Le processus de test ici est plus compliqué, je publierai donc la conclusion directement :
)
2. Lorsque balance=1, les opérations de lecture seront dispersées de manière aléatoire sur localhost1 et deux hôtes de lecture (lorsque localhost échoue, les opérations d'écriture seront sur
localhost1, si
Si localhost1 échoue à nouveau, les opérations d'écriture ne seront pas possibles
) 3. Lorsque balance=2, les opérations d'écriture seront sur localhost et les opérations de lecture seront dispersées aléatoirement sur LocalHost1, LocalHost1 et deux Readhost (les mêmes ci-dessus)
4.writeType = 0, les opérations d'écriture seront sur LocalHost Passer à localhost1 Après. localhost est restauré, il ne reviendra pas à localhost pour les opérations d'écriture Sur
localhost et localhost1, le point de défaillance unique n'affectera pas l'opération d'écriture du cluster. Cependant, la bibliothèque esclave back-end ne pourra pas obtenir les mises à jour de la bibliothèque principale défaillante et échouera en cas d'incohérence de lecture des données
.                                                                                                                                                                                                   , mais la bibliothèque esclave de localhost ne peut pas obtenir de mises à jour de localhost. cohérence avec d'autres bibliothèques -------- ----- --------------------------------------------- ----- --------------------------------------------- ----- --------------------------------------------- ----- -------------En fait, La séparation en lecture et en écriture de MyCAT elle-même est basée sur la synchronisation du cluster back-end, et MyCAT elle-même fournit des fonctions de distribution d'instructions. La restriction sqlLimit amène également MyCAT à avoir un certain impact sur la logique de la couche d'application frontale
La configuration du schéma à la table montre que la structure logique de MyCAT elle-même inclut la fonctionnalité de sous-base de données et de sous-table (peut Spécifiez que différentes tables existent dans différentes bases de données sans avoir à les diviser dans toutes les bases de données)