Does your mirror storage service have any special features compared to traditional CDN? External domain – Qiniu domain – origin domain. I want to know if there will be any conflicts if I automatically sync my website server data to Qiniu along with the mirror storage feature. How much can access speed and response speed be improved?
Qiniu’s mirror storage appears similar to traditional CDN, as both will fetch from the origin server when data is not present at the acceleration node. The difference is that mirror storage is storage (no different from regular storage; the mirroring function is just a feature of the storage), not a cache. Therefore, mirror storage only fetches from the origin once per resource; subsequent accesses will not trigger another origin pull. So, it’s not suitable when the URL content on the origin server changes frequently (minor changes are acceptable; you can proactively delete files in the mirror storage to force a refresh).
You can proactively sync data to the mirror storage, for example, using qrsync, or by writing your own sync upload code. This is possible and indeed beneficial: because mirror storage fetches from the origin upon the first access of a resource, that first access will be relatively slow. Proactively syncing data can improve the speed of that first access.
Additionally, using mirror storage together with qrsync data synchronization allows you to smoothly migrate your website data to Qiniu without service interruption. Assuming all images on your origin server are hosted under a subdomain called img.example.com, the smooth migration method is:
- Create a mirror bucket on Qiniu and set the origin server to img.example.com. Assume the mirror bucket is named example-img, and the corresponding domain for the mirror bucket is example-img.qiniudn.com.
- Change all externally-facing image domains to example-img.qiniudn.com.
- If the website data is UGC (User Generated Content), adjust the upload process to upload directly to the Qiniu mirror bucket. This makes the origin server read-only.
- Use the qrsync sync tool to synchronize all historical data to the Qiniu mirror bucket.
This completes the entire migration process. At this point, the origin server img.example.com can be decommissioned.
You might ask: if I want to keep the externally-facing domain img.example.com, instead of using example-img.qiniudn.com, is that possible? The answer is yes, but it will be slightly more troublesome. The additional steps required are:
- You need to specify a different origin server for the Qiniu mirror bucket (it can no longer be img.example.com), such as img-src.example.com, or use an IP address directly.
- Bind img.example.com to the Qiniu mirror bucket. To achieve this, you need to submit img.example.com to Qiniu for registration. This involves a manual review period and may not be instant.
- After testing that the mirror storage works as expected, CNAME img.example.com to the domain of the Qiniu mirror bucket (e.g., example-img.qiniudn.com). Be extremely careful not to make a mistake in this step, as after this point your website will be served through Qiniu’s mirror storage. Out of caution, it is recommended to test locally first by modifying your hosts file to point img.example.com to the IP address of example-img.qiniudn.com.