SearchStax Site Search solution is engineered to give marketers the agility they need to optimize site search outcomes. Get full visibility into search analytics and make real-time changes with one click.
SearchStax Managed Search service automates, manages and scales hosted Solr infrastructure in public or private clouds. Free up developers for value-added tasks and reduce costs with fewer incidents.
Ensure that your Solr search infrastructure is resilient and available when you need it by implementing Solr disaster recovery to minimize data loss and disruptions to your business
Machines and technology fail. Natural or man-made disasters occur. Networks go down. And website or application outages caused by any of these situations are going to happen.
Instead of hoping that disaster won’t happen to them, most companies meet their business requirement to maintain high availability, minimize customer disruptions and reduce overall risk by implementing a disaster recovery plan for their Solr infrastructure.
SearchStax Managed Search offers three different disaster recovery (DR) options to protect your Solr infrastructure. With Hot DR, we deploy an active full-size Solr deployment in another cloud region. With Warm DR, we create an active scaled-down Solr deployment in another region. For Cold DR, we create a new Solr environment on-demand.
Hot DR is bundled automatically with the SearchStax Managed Search Platinum Premium support plan.
Cold, Warm or Hot DR is available as an add-on for any Gold or Platinum support plan.
Hot Disaster Recovery
Warm Disaster Recovery
Cold Disaster Recovery
HOT DISASTER RECOVERY | WARM DISASTER RECOVERY | COLD DISASTER RECOVERY | |
---|---|---|---|
Secondary Environment | Active full-size Solr deployment in another cloud region | Scaled-down Solr deployment in another cloud region | Created on-demand in another cloud region or same region upon request |
Disaster Recovery Trigger | Upon customer request or when Solr service is unavailable for 5 minutes | Upon customer request or when Solr service is unavailable for 5 minutes | Created on-demand upon customer request or when Solr service is unavailable for 5 min. |
Disaster Recovery Process | DR Triggers a DNS failover | DR Triggers a DNS failover | DR Triggers new cluster deployment, backup restoration and DNS failover |
RPO* Service Level (SLA) | 24 hours to as low as 10 minutes | 24 hours to as low as 10 minutes | 24 hours to as low as 1 hour |
RTO** Service Level (SLA) | Less than 10 minutes | Less than 10 minutes | 8 hours (typically 2 to 4 hours) |
*Recovery Point Objective (RPO) defines the amount of data that your business can tolerate losing in case of an emergency
**Recovery Time Objective (RTO) is the amount of time that your Solr service can be unavailable in case of an emergency
A more sophisticated version of Hot Solr disaster recovery is Cross Data Center Replication (CDCR). CDCR provides near instantaneous synchronization across different cloud regions by implementing Solr clusters in two or more separate cloud regions. With CDCR, there would be minimal loss of data during fail-over and replication.
Learn more about CDCR and see how one of our customers used CDCR to achieve near 100% uptime with SearchStax.
Disaster recovery for Apache Solr involves the process of restoring the Solr instance and its data in the event of a disaster such as hardware failure, software failure, natural disasters or human errors.
For businesses with aggressive RTO and RPO requirements, a duplicate infrastructure that mirrors your primary production environment in real-time may be needed. SearchStax offers a Hot Disaster Recovery option that augments your production deployment and provides the highest level of redundancy and resource capacity during a disaster.
To achieve this level of redundancy, we create a “hot” standby or secondary deployment in a different region than your production deployment. This secondary deployment is a full replica of your primary production environment and is kept in sync with your production system at all times. That means that an interruption in service at the primary site for the production system can be met by a near instantaneous switchover to the standby site.
For businesses with aggressive RTO and RPO requirements, a duplicate infrastructure that mirrors your primary production environment in real-time may be needed. SearchStax offers a Hot Disaster Recovery option that augments your production deployment and provides the highest level of redundancy and resource capacity during a disaster.
To achieve this level of redundancy, we create a “hot” standby or secondary deployment in a different region than your production deployment. This secondary deployment is a full replica of your primary production environment and is kept in sync with your production system at all times. That means that an interruption in service at the primary site for the production system can be met by a near instantaneous switchover to the standby site.
For some businesses, downtime is not a critical requirement. Under the Cold Disaster Recovery option, the restoration process starts after the disaster occurs. A new Solr cluster is created and the data and configurations are then restored from a backup file.
The SearchStax Cold Disaster Recovery handles this process for you and uses backup files that are stored in different cloud regions and provides a higher level of recovery than backups stored in the same region. While everyone should maintain regular backups of their deployments, the Cold Disaster Recovery option takes this to the next level by storing the backups in a different cloud region from the primary system. If the production site goes down, we will start a deployment in the same region as the backup and restore it.
Recovery Time Objective, or RTO, is the amount of time that your Solr service can be unavailable in case of an emergency. This could be caused by a corrupt Solr Index or Solr replicas going into recovery mode. A cloud provider region could go down because of a natural disaster or a cyber attack.
In any of these situations, your business might have to face some downtime. RTO defines the maximum acceptable time for your application to recover when such an event occurs.
Recovery Point Objective, or RPO, defines the amount of data that your business can tolerate losing in case of an emergency. For example, if your business can tolerate losing four hours of history in order to get back on line quickly, then your RPO would be four hours.
Copyrights © SearchStax Inc.2014-2024. All Rights Reserved.