L'envoi de données est asynchrone : une réponse OK confirme uniquement la réception, et non le succès du traitement. Vérifiez toujours les résultats du traitement dans la console OpenSearch après l'envoi des données.
Fonctionnement
Toutes les commandes d'écriture suivent le même flux : soumettez une requête d'envoi, recevez une réponse OK, puis attendez le traitement asynchrone. En cas d'échec du traitement, l'erreur s'affiche dans la console OpenSearch. Consultez-la rapidement pour éviter toute perte de données.
Les trois commandes diffèrent par leur gestion des documents existants :
| Commande | Si le document existe | Comportement des champs |
|---|---|---|
add |
Suppression puis ajout | Tous les champs sont écrasés ; les champs absents prennent la valeur vide par défaut |
update |
Suppression puis ajout | Seuls les champs spécifiés sont mis à jour ; les champs absents conservent leurs valeurs d'origine |
delete |
Suppression | S'exécute même si l'ID de clé primaire n'existe pas |
Pour les envois de données incrémentiels, les documents ayant des valeurs de clé primaire en double sont écrasés.
Limites
| Ressource | Limite |
|---|---|
| Taille du corps HTTP POST | 2 Mo par requête |
| Taux d'envoi | Limité par le quota de l'application |
| Taux de synchronisation ApsaraDB RDS for MySQL | Voir Limites |
| Taille de synchronisation ApsaraDB RDS for MySQL | Voir Limites |
Envoyer des données via l'API ou le SDK
Regrouper les envois
Regroupez les documents en lots avant de les envoyer. Cela réduit le nombre de requêtes et optimise l'utilisation de votre quota. Si la taille totale des documents envoyés lors d'une seule requête dépasse 2 Mo, le serveur rejette la requête.
Vérifier les valeurs de retour après chaque envoi
Après chaque envoi, vérifiez systématiquement les valeurs de retour. Une réponse OK confirme uniquement la réception ; elle ne garantit pas le succès du traitement. Consultez la console OpenSearch pour détecter les erreurs de traitement. Portez une attention particulière au code d'erreur 3007 : résolvez le problème selon le code d'erreur, puis réessayez.
Gérer les erreurs et les limites de débit
Les erreurs suivantes nécessitent une nouvelle tentative :
| Message d'erreur | Cause typique | Action |
|---|---|---|
connection timed out |
Problème réseau | Réessayez |
1000 :system error |
Problème système | Réessayez |
push rate exceeds app quota |
Les documents dépassent 2 Mo par requête (le plus courant) ou la fréquence des requêtes est trop élevée | Réessayez ; réduisez la taille du lot si l'erreur persiste |
request too frequently |
Le nombre d'envois dépasse la limite supérieure | Réessayez ; regroupez les documents pour réduire le nombre de requêtes |
Encoder vos requêtes HTTP POST
Appliquez l'encodage URL à l'URL et au corps des requêtes HTTP POST. Sans encodage, le serveur peut échouer à analyser la requête ou la rejeter avec une erreur de signature.
Synchroniser les données depuis ApsaraDB RDS for MySQL
Le débit et la taille de la synchronisation des données depuis ApsaraDB RDS for MySQL sont limités. Pour plus de détails, consultez Limites.
Éviter le débordement des journaux binaires
Un journal binaire est généré chaque fois qu'une table d'une base de données ApsaraDB RDS for MySQL est mise à jour. Si la génération de journaux binaires dépasse la limite supérieure, les données s'accumulent et la synchronisation est retardée.
Pour réduire le volume des journaux binaires :
Déplacez les tables fréquemment mises à jour vers des bases de données distinctes afin de répartir la génération des journaux binaires.
Activez la synchronisation automatique des données pour la table principale, puis utilisez les opérations API pour les tables secondaires.