Data push is asynchronous — an OK response confirms receipt, not successful processing. Always verify processing results in the OpenSearch console after pushing data.
How it works
All write commands share the same flow: submit a push request, receive an OK response, and then wait for asynchronous processing. If processing fails, the error appears in the OpenSearch console. Check promptly to avoid data loss.
The three commands differ in how they handle existing documents:
| Command | If the document exists | Field behavior |
|---|---|---|
add | Delete then re-add | All fields overwritten; absent fields default to blank |
update | Delete then re-add | Only specified fields updated; absent fields retain original values |
delete | Delete | Runs even if the primary key ID does not exist |
For incremental data pushes, documents with duplicate primary key values are overwritten.
Limits
| Resource | Limit |
|---|---|
| HTTP POST body size | 2 MB per request |
| Push rate | Limited by app quota |
| ApsaraDB RDS for MySQL sync rate | See Limits |
| ApsaraDB RDS for MySQL sync size | See Limits |
Push data using the API or SDK
Batch your pushes
Batch documents into packages before pushing. This reduces the number of requests and makes better use of your quota. If the total size of documents uploaded in a single request exceeds 2 MB, the server rejects the request.
Check return values after every push
After pushing, always check the return values. An OK response only confirms receipt — it does not mean processing succeeded. Check the OpenSearch console for processing errors. Pay special attention to error code 3007: troubleshoot based on the error code, then retry.
Handle errors and rate limits
The following errors require a retry:
| Error message | Typical cause | Action |
|---|---|---|
connection timed out | Network issue | Retry |
1000 :system error | System issue | Retry |
push rate exceeds app quota | Documents exceed 2 MB per request (most common), or high request frequency | Retry; reduce batch size if the error persists |
request too frequently | Push count exceeds the upper limit | Retry; batch documents to reduce request count |
Encode your HTTP POST requests
Apply URL encoding to both the URL and body of HTTP POST requests. Without encoding, the server may fail to parse the request or reject it with a signature error.
Synchronize data from ApsaraDB RDS for MySQL
The rate and size of data synchronization from ApsaraDB RDS for MySQL are limited. For details, see Limits.
Avoid binary log overflow
A binary log is generated whenever any table in an ApsaraDB RDS for MySQL database is updated. If binary log generation exceeds the upper limit, data stacks up and synchronization is delayed.
To reduce binary log volume:
Move frequently updated tables into separate databases to distribute binary log generation.
Enable automatic data synchronization for the primary table, then use API operations for secondary tables.