Zend et base de données : mécanisme interne

Version imprimable

20/12/2011, 10h24
eaglesnipe

2 pièce(s) jointe(s)

Zend et base de données : mécanisme interne

Bonjour,

Je développe une application à l'aide du Zend Framework et rencontre quelques "problèmes" dans la gestion de la base de données liés à l'architecture de cette dernière.

En effet, pour faire simple, cette dernière s'architecture autour d'une multitude de serveurs répliqués de la manière qui suit :

http://www.developpez.net/forums/att...1&d=1324371036

Ainsi, les Masters sont accessibles en Lecture/Ecriture, tandis que les Slaves ne le sont qu'en lecture. Des requêtes de MAJ se feront donc sur les Masters tandis que des simples requêtes de lectures se feront sur les Slaves. Un "répartiteur", permet, en fonction de la charge des machines, de répartir le flux vers tel ou tel serveur. Dès qu'une mise à jour est détectée, les Masters se synchronisent entre eux et synchronisent les Slaves de manière avoir des données homogènes et cohérentes. Voici pour l'architecture simplifiée, j'espère avoir été compréhensible... :)

Au niveau du code désormais, sont gérés des logs applicatifs. Le modèle BDD simplifié est le suivant :

http://www.developpez.net/forums/att...1&d=1324371492

Lorsqu'une requête est effectuée, son accès est loggué dans la table Requete et l'identifiant est récupéré. Les paramètres sont loggué dans la table ParametresRequete (avec la référence vers Requete grace à l'id récupéré), idem pour les éventuelles erreurs. Une série de traitement est effectuée pour créer les résultats à retourner et ces derniers sont loggués dans la table RésultatsRequete (avec la aussi la référence vers Requete).

Le problème qui se pose est le suivant. Nous avons en moyenne entre 2 et 4 requêtes à la seconde, et donc autant de logs. Parmi cs nombreux logs ressortent quelques erreurs d'insertion BDD (à hauteur de 0.015%, ce qui est ridicule je vous l'accorde, mais j'aimerais comprendre... :) ). Cette erreur d'insertion est la suivante :

Code:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`ResultatsRequete`, CONSTRAINT `fk_resultatsrequete_requete` FOREIGN KEY (`ref_id_resultats_requete`) REFERENCES `Requete` (`id_requete`) ON DELETE CASCADE ON UPDATE CASCADE)

Comme on peut le voir, ce qui plante est l'insertion dans la table de résultat en cause de la référence vers la table de requete. Il tente en effet d'insérer dans résultat une référence vers une requete qui n'existe pas, d'où l'erreur. Mais alors pourquoi donc, étant donné qu'il n'y a aucune raison à ce que la requête n'ait pas été correctement insérée ? Nos investigations nous poussent à croire, et c'est la première fois que le cas se présente, que le problème est liée à l'architecture BDD mise en place, ou au fonctionnement interne de Zend, tout dépend le point de vue :-). En effet, dans la théorie, le log de requete est bien inséré en base de données, mais sur l'un des serveur Master. L'architecture BDD fait que les masters doivent alors se synchroniser entre eux. Sauf que, les requêtes étant très nombreuses et le laps de temps entre l'insertion requête/résultats très court, il semblerait que la synchro n'est pas eu le temps de s'effectuer. Pour le peu que la répartition de la charge fasse que le log de résultat se fasse alors sur le second Master, non encore synchronisé, il tente alors en effet de référer sur une requete qu'il ne connait pas encore...

La question que nous nous posons, en ce qui concerne Zend, est alors pourquoi ce dernier créé-t-il une autre connexion BDD et ne conserve-t-il pas la même ? (si la même était conservée, il aurait alors écris sur le même serveur). A quel moment est donc effectuée la connexion vers la base de données ? Lors de la création de chacun des objets Mappers ou DbTable ? N'y a-t-il aucun moyen de lui spécifier d'encapsuler un ensemble d'opérations BDD dans une même connexion, même si cet ensemble d'opérations utilise une multitude de DbTable différents ? La mise en place d'une transaction pourrait-elle régler le problème ?

L'architecture BDD mise en place a été longuement pensée et réfléchie pour pouvoir gérer l'énorme charge qu'elle subit et palier les éventuels défaut d'un serveur, d'où cette réplication. Il n'est donc pas envisageable de la revoir par nos amis NAS. D'où la recherche d'une solution au niveau dev.

Merci pour toutes les suggestions que vous pourrez m'apporter.
20/12/2011, 11h58
Nighty

Bonjour,

Demande très détaillée, par contre je pense qu'on manque de quelques morceaux pour bien saisir d'où vient le problème...

Zend_Db n'est pas sensé créer plus d'une seule connexion, sauf bien sûr... si on en créé plusieurs instances.

La seule subtilité que je connaisse concernant la connexion à la base est qu'elle est temporisée jusqu'à la première requête (ou demande explicite de vérifier la connexion) : ça implique qu'instancier un objet Zend_Db ne déclenche pas la connexion immédiatement, ça se fait plus tard, lorsque le besoin se fait sentir. En gros, rien de ce qui concerne ton problème, ça pose surtout des soucis de contrôle d'erreur.

Peux-tu répondre à quelques questions :
- Quel driver est utilisé ? PDO ?
- As-tu bien une seule connexion Zend_Db, laquelle est utilisée par tous les Zend_Db_Table ?
- Dans l'idéal si tu pouvais détailler la configuration de ton appli, même sans rentrer dans les détails confidentiels savoir comment tu configures ton instance Zend_Db pourrait aider à comprendre ce qui se passe.

Bonjour Nighty, et merci de t'intéresser à mon problème... :)

Pour répondre à tes questions :

Citation:

- Quel driver est utilisé ? PDO ?

Oui. Plus précisément, voici mon adapter defini dans le .ini :

Code:

resources.multidb.xxx.adapter = "Pdo_Mysql"

Citation:

- As-tu bien une seule connexion Zend_Db, laquelle est utilisée par tous les Zend_Db_Table ?
- Dans l'idéal si tu pouvais détailler la configuration de ton appli, même sans rentrer dans les détails confidentiels savoir comment tu configures ton instance Zend_Db pourrait aider à comprendre ce qui se passe.

Là j'ai un peu plus de mal à répondre dans la mesure où je reprend cette application existante (depuis de nombreuse années) depuis peu et ne maîtrise donc pas encore toutes les subtilités du code. Ce que je peux dire d'ores et dejà :

- Est-utilisé un Zend_Db::factory pour gérer les connexions. Le mécanisme mis en place par mon/mes prédécesseur(s) est le suivant. Un exemple avec la classe Default_Model_DbTable_Requete qui gère ma table requete, mais le principe est le même pour tous les DbTable :

La DbTable :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Default_Model_DbTable_Request extends Default_Model_DbTable_Abstract
{
 
	/**
	 * Nom de l'adaptateur
	 * @var string
	 */
	protected $_adapter = 'xxx';
 
	/**
	 * Nom de la table
	 * @var string
	 */
    protected $_name = 'Request';
 
    /**
     * Clé primaire
     * @var string
     */
    protected $_primary = 'id_request';
}

La classe mère :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
abstract class Default_Model_DbTable_Abstract extends Zend_Db_Table_Abstract
{
 
	/**
	 * Adaptateur SQL.
	 *
	 * @var Zend_Db_Adapter_Abstract
	 */
	protected $_adapter = null;
 
	/**
	 * Constructeur.
	 *
	 * @param  array   $config
	 */
	public function __construct($config = array())
	{
		try {
			if($this->_adapter !== null) {
				$c  = Zend_Registry::get('config');
				$db = $c->resources->multidb->{$this->_adapter}->toArray();
				$config = array(self::ADAPTER => Zend_Db::factory($db['adapter'], $db));
			}
 
			parent::__construct($config);
 
		} catch(Zend_Db_Adapter_Exception $e) {
			throw new Exception($e->getMessage());
		}
	}
}

La ressource associée dans le .ini :

Code:

1
2
3
4
5
resources.multidb.xxx.adapter  = "Pdo_Mysql"
resources.multidb.xxx.host     = "ip_server"
resources.multidb.xxx.username = "username"
resources.multidb.xxx.password = "password"
resources.multidb.xxx.dbname   = "dbname"

Au niveau insertion, le code ressemble à ceci. Avant tout, chaque appel de fonction par un client (il s'agit d'un service web) est loggué. Une exemple de traitement avec l'une des fonctions :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
/****************/
/* Fonctions du WS**/
/****************/
public function maFonction($param1, $param2) {
 
        // Enregistrement de l'appel à la méthode dans les logs.
        $idLogsRequest = $this->_logAccess(
                __FUNCTION__, array('param1' => $param1, 'param2' => $param2)
        );
 
       // Requete BDD pour récupérer les résultats
 
       // Construction des résultats
 
 
       // Construction des données de logs puis log
       $data = array(
                //Mes données de logs
       );
       $this->_logResults($idLogsRequest, $data);
 
     // On retourne la réponse
 }
 
 
/****************************/
/* Fonctions de traitements des logs */
/****************************/
public function logAccess($methodName, array $args = array()) {
 
        //...
 
        // On prepare les données de log
        $dataRequest = array(
            'execution_date' => date('Y-m-d H:i:s'),
            'remote_addr' => $request->getServer('REMOTE_ADDR'),
            'remote_port' => $request->getServer('REMOTE_PORT'),
        );
 
        $logsRequest = new Default_Model_DbTable_Request();
        try {
            $idRequest = $logsRequest ->insert($dataRequest);
        } catch (Exception $e) {
            // Gestion exception
        }
 
            // On constuit correctement le tableau de paramètres pour insertion
            $dataRequestParameters = array(
                'ref_id_request' => $idRequest,
            );
 
            // On créé le tableau de paramètres
            $parameters = array();
            foreach ($args as $id => $value) {
                    $parameters[$id] = $value;
            }
 
            $dataRequestParameters = array_merge($dataRequestParameters, $parameters);
 
            // On créé le DbTable paramètre qui permettra l'insertion
            $logsRequestParameters = new Default_Model_DbTable_RequestParameters();
 
            try {
                $logsRequestParameters->insert($dataRequestParameters);
            } catch (Exception $e) {
                // Traitement de l'exception
            }
        }
 
        return $idLogsRequest;
    }
 
 
public function logResults($idLogsRequest, array $data) {
 
         //...
 
        // On créé le tableau de données.
        $dataLogsRequestResult = array();
        $dataLogsRequestResult['ref_id_request'] = (int) $idLogsRequest;
        $dataLogsRequestResult[...] = $data[...]
 
 
        // On créé le DbTable abstrait qui permettra l'insertion
        $logRequestResult = new Default_Model_DbTable_RequestResults();
 
        try {
            // On insère
            $logRequestResult->insert($dataLogsRequestResult);
        } catch (Exception $e){
            //Gestion des exceptions
        }
    }

Voici de manière simplifiée la procédure de logs. Je dis "simplifiée" car toutes les fonctions de logs sont en fait appelées via un objet du modèle afin de ne pas faire ces traitements dans le coeur du web service, ce qui n'aurait pas de sens, mais le traitement n'est ni plus ni moins que celui-ci.

Point de vue du problème, la difficulté est rencontrée uniquement lors d'une insertion d'un log de résultat (dans moins de 1% des cas) où j'obtiens l'erreur énoncée dans mon premier post, traitement qui se fait donc dans une autre fonction : la requete qu'il cherche à référencer n'existe pas (encore) [lié à la synchronisation Master dont j'ai parlé plus haut].

La question que je me posais donc : à quel moment précis la connexion à la BDD est-elle effectuée, puis relâchée ?

J'espère ne pas t'avoir assommé avec tout ce texte.. :-)

20/12/2011, 16h26
Nighty

Merci pour tes retours.

Réponse à prendre avec des réserves, je n'ai jamais expérimenté des connexions à des serveurs de base de données multiples. Par contre, je doute de me tromper en répondant à tes questions :

Citation:

à quel moment précis la connexion à la BDD est-elle effectuée

Lors du premier appel à _connect(), c'est une méthode protected appelée par Zend_Db_Adapter_Abstract dés que le besoin se présente (premier appel à getConnection(), ou tout autre appel qui nécessite que la connexion se fasse).

Citation:

puis relâchée ?

Lors d'un appel explicite à closeConnection(), ou à la fin du script.

Puisque le problème se présente ponctuellement sur la relation entre Default_Model_DbTable_RequestResults et Default_Model_DbTable_Request, es-tu sûr que les deux DbTable utilisent le même adapter ?

Si non, ils partagent effectivement une connexion différente ce qui pourrait amener à ce problème de synchro.

Si ce n'est pas le cas et qu'ils partagent bien la même connexion c'est curieux, tu devrais essayer si une transaction règle le problème.
20/12/2011, 17h23
eaglesnipe

Merci pour tes précisions.

Je suis en train d'adapter le code afin de justement que le tout soit encadré par une transaction.

Dès que j'aurai pu tester la nouvelle version, je ferai un retour ici, en espérant que le problème soit résolu... :-)

(En ce qui concerne l'adapter, il n'y a aucune raison que les deux DbTable n'utilisent pas le même... Je me penche donc sur la transaction avec l'espoir que ça apportera une solution..)

Encore merci !!
21/12/2011, 11h17
Nighty

Citation:

Envoyé par eaglesnipe

(En ce qui concerne l'adapter, il n'y a aucune raison que les deux DbTable n'utilisent pas le même... Je me penche donc sur la transaction avec l'espoir que ça apportera une solution..)

Je me permet de réagir, selon ton code il est tout à fait possible que les deux DbTable utilisent deux connexions différentes : il suffit que leur propriété $_adapter n'ait pas la même valeur. Je ne dis pas que c'est le cas, mais ça reste une possibilité :D

Parfaitement d'accord avec toi. Mais pour le coup, leur propriété $_adapter permet d'aller chercher l'info de l'adapter dans le .ini :

Code:

protected $_adapter = 'xxx';
Code:

1 2 3 4 5 if($this->_adapter !== null) { $c = Zend_Registry::get('config'); $db = $c->resources->multidb->{$this->_adapter}->toArray(); $config = array(self::ADAPTER => Zend_Db::factory($db['adapter'], $db)); }
Code:

1 2 3 4 5 resources.multidb.xxx.adapter = "Pdo_Mysql" resources.multidb.xxx.host = "ip_server" resources.multidb.xxx.username = "username" resources.multidb.xxx.password = "password" resources.multidb.xxx.dbname = "dbname"
Et il n'y en a qu'un de défini dans le .ini. Donc si un $_adapter différent est spécifié, l'info ne pourra pas être récupérée dans le .ini et une jolie exception sera levée... :)

Dans ce cas précis, les $_adapter ont donc bien la même valeur. :)

Merci pour la précision toutefois, ça me permet de mieux appréhender les méandres du Zend Framework ! ^^

22/12/2011, 09h18
eaglesnipe

Bonjour bonjour,

Un petit retour sur les modifications apportées et... ce n'est pas très concluant... :(

Le problème semble finalement plus complexe et l'ajout d'une transaction et la factorisation du code ne le résout pas.... Un peu plus d'explications seront utiles je pense.

L'adresse IP spécifiée dans la configuration

Code:

resources.multidb.xxx.host = "aaa.bbb.ccc.030"

est en fait une IP virtuelle. Lorsqu'une tentative de connexion est faite sur cette dernière, le Load Balancer va, en fonction de la charge machines, basculer le flux effectif sur une des adresses réelles qui lui sont liées, soit aaa.bbb.ccc.031 ou bien aaa.bbb.ccc.032.

Visiblement, il se passerait alors ceci :
Lorsqu'un appel de fonction du Web Service est effectué, je log immédiatement ce dernier via le dbtable DbTable_LogsRequest (l'objet étant construit conformément au code montré plus haut). Les paramètres sont ensuite logués dans la foulée via DbTable_LogsRequestParameters. Le tout s'effectue successivement au sein d'une même fonction : la requête suivi de ces paramètres avec une référence sur celle-ci.

Sont ensuite traitées différentes données en vue de construire un résultat. Je log alors ce dernier via DbTable_LogsRequestResults, le travail étant effectué par une autre fonction. Est à nouveau utilisé pour ce log l'identifiant de requête retourné lors de la première insertion (la requete) afin de satisfaire les dépendances de clef étrangère (cf le MCD).

Voici pour le contexte.

Le problème serait alors le suivant. Supposons que le Load Balancer ait ouvert une connexion effective sur l'IP aaa.bbb.ccc.031 lors de la première insertion (LogsRequest). Je récupère alors un identifiant de requête qui est présent sur ce serveur. Un tas de traitement est effectué et arrive le moment du log des résultats (ou paramètres, le cas s'est nouvellement présenté). Si le Load Balancer rend la main à aaa.bbb.ccc.031, alors pas de soucis. En renvanche, si la main est donnée à aaa.bbb.ccc.032 et que la synchro des 2 masters (031 et 032) n'a pas encore eu le temps de s'effectuer, alors on va tenter de référer vers une requête qui n'existe pas encore, puisqu'en effet elle a été insérée sur l'autre serveur. D'où la belle erreur MySql de violation de clef étrangère.

Code:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`LogsRequestResults`, CONSTRAINT `fk_logsrequestresults_logsrequest` FOREIGN KEY (`ref_id_logs_request`) REFERENCES `LogsRequest` (`id_logs_request`) ON DELETE CASCADE ON UPDATE CASCADE)

Alors pourquoi ouvre-t-il une seconde connexion et ne réutilise-t-il pas celle ouverte pour l'insertion dans LogsRequest, mystère. Est-ce parce que Zend ne verrait que l'IP virtuelle 030 et que lors d'une nouvelle insertion toute la démarche d'ouverture de connexion est à nouveau réalisée (ce qui serait bien étrange) ce qui entraînerait donc inévitablement l'intervention du Load Balancer (et donc potentiellement un nouvelle IP) ? Comment l'empêcher alors d'ouvrir une autre connexion ? N'y a-t-il aucun moyen de le forcer à utiliser la même IP effective que celle utilisée lors de la toute première insertion (et donc la même connexion) ?

Je peux mettre le code relatif aux traitements des logs si ça peut aider...

J'avoue pour le coup être un peu perdu et ne plus savoir vers quelle solution m'orienter...

Merci d'avance pour toutes les suggestions que vous pourriez faire..

Solution pour l'insertion en BDD avec clefs étrangères et contrôle par Load Balancer (IP virtuelle)

Pour aider mon prochain, voici la solution que j'ai mise en place pour régler le problème. Le problème étant tellement spécifique, je ne suis pas sûr que beaucoup s'y reconnaîtront, mais sait-on jamais ! :)

Les modifications tournent actuellement en production et tout semble parfaitement fonctionnel.

L'astuce a été de modifier totalement la gestion de la connexion à la base de données. Comme mes précédents posts le montrent, les connexions étaient "effectuées" via l'appel aux objets DbTable de chacune des tables :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $dataRequest = array( //... ); $logsRequest = new Default_Model_DbTable_Request(); $idRequest = $logsRequest ->insert($dataRequest); //... $dataRequestParameters = array( 'id_request' => $idRequest , //... ); $logsRequestParameters = new Default_Model_DbTable_RequestParameters(); $logsRequestParameters->insert($dataRequestParameters); //etc.
Pour régler ce problème de Load Balancer et d'IP virtuelle qui donnait la main à l'un ou l'autre serveur suivant la charge, j'ai finalement géré ma connexion totalement à mano :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 $dbc = $this->_config->resources->multidb->xxx->toArray(); $this->_db = Zend_Db::factory($dbc['adapter'], $dbc); $this->_db->getConnection(); //... $this->_db->insert('logsRequest', $dataRequest); $this->_idRequest = $this->_db->lastInsertId(); //... $this->_db->insert('logsRequestParameters', $dataRequestParameters); //.. $this->_db->closeConnection(); $this->_db = null;
Bien évidemment le code n'est pas si simple, j'ai juste présenté l'idée :D

Ainsi, la connexion n'est ouverte qu'une unique fois (en réalité lors de la construction de l'objet) ainsi l'insertion se fait toujours sur le même serveur octroyé par le Load Balancer. Les insert se font alors sans problème (plus d'erreurs de clefs étrangères, puisque les données sont cette fois ci bel et bien présentes) et la déconnexion s'effectue à la destruction de l'objet...

Voili Voilou ! En espérant que ça puisse en aider d'autres !