• home
• support
  • xkoto Support
• contact

• Products
  • GRIDSCALE Overview
  • Features
  • Screenshots
  • System Requirements
  • GRIDSCALE for DB2
  • GRIDSCALE for SQL Server
  • FAQ
  • Demo and Evaluation
• Business Impact
  • Overview
  • Customer Successes
  • Benefits by Role
  • Continuous Availability
  • Scale-Out Performance
  • Dramatic Cost Savings
  • Business Agility
• Resources
  • Resource Center
• Partners
  • Overview
  • Channel Partners
  • Technology Partners
  • Become a Partner
• News+Events
  • Overview
  • Media Coverage
  • Press Releases
  • Calendar of Events
• Company
  • Overview
  • Management Team
  • Board of Directors
  • Investors
  • Careers
  • Contact Us

Business Impact

• Business Impact Overview
• Customer Successes
• Benefits by Role
• Continuous Availability
• Scale-Out Performance
• Dramatic Cost Savings
• Business Agility

Continuous Availability

No enterprise can afford to be down. Whether private or public, Fortune 100 or startup, the objective is the same: keep the business running. Your customers and partners depend on it. Unfortunately, the traditional "High Availability" (HA) approach to databases cannot provide 100% uptime. Legacy approaches like Server Clustering and Log Replication are widely deployed but do have their limitations as described below:

Database Server Clustering

Two servers are clustered together in the same physical location so that an application can failover from a primary server to a secondary server. The servers share common disk storage and have cluster software running to determine when to trigger a failover.

Limitations:

Long recovery time: the secondary server needs to attach to the shared storage and then replay the logs before the secondary database can start up.

GRIDSCALE is an active/active solution so all servers are useful all the time. As a result, there is no failover delay because there is no failover!

Single point of failure: With a reliance on shared storage, not only can performance suffer, any failure of the storage means total failure of the cluster and downtime for the business.

GRIDSCALE employs a "shared nothing" architecture so that failure of one server does not bring the application down.

High cost: In a server cluster, the servers are typically sized identically, even though the secondary is normally idle. This means high cost and low utilization.

GRIDSCALE can use different servers, including commodity servers, even running different versions of databases.

Log Shipping Replication

Each of two or more servers run both a database and replication software. One database is designated as the master, whose transaction log is monitored. Changes detected in the master log are shipped to and applied to the other replicated databases (the slaves).

Limitations:

Data loss: If master log changes are sent to the slave asynchronously, the slave can be missing data when called upon in the event of master failure.

GRIDSCALE provides consistent data at any time and all the time across the grid.

Slow performance: If master log changes are sent to the slave synchronously, the application may suffer poor performance since data has to be committed to all slaves before an application can proceed.

GRIDSCALE sends DML statements to all servers in the grid but responds back to an application on the first successful commit, thereby improving application performance.

High network usage: log shipping requires binary data to be sent to all slaves, potentially consuming significant network bandwidth.

GRIDSCALE uses SQL statement replication which can be very compact and efficient.