FAQ – Xeround Cloud DBaaS

Xeround comes in three editions: Xeround FREE, Xeround BASIC and Xeround PRO. Every Xeround user is entitled to one Xeround FREE database instance — which is a no charge plan most suitable for development stages and for small web applications. In addition, you can also try Xeround’s paid editions for free for the first 30 days.

To learn more about Xeround’s plans, their features and respective prices, visit our Plans and Pricing page.

The current Xeround version supports MySQL. More database engines will be supported in the near future.

Xeround operates in the following data centers:

• Amazon EC2 US East Coast (US-East)
• Amazon EC2 West Europe (EU-West)
• RackSpace US East Coast (ORD1)

We are constantly working on expanding our reach by adding additional data centers to our service, as well as by offering it on other public cloud providers.

We plan to expand to offering availability across multiple clouds, regions and availability zones within existing data centers.

Our technology allows us to arbitrarily set the number of data replicas that we manage as well as the role and location of each one of these. By design, our system is tolerant to faults in any of its replicas and continues to perform during and after a replica’s failure. In its current form, our service is offered with two active-active replicas, both residing in the same data center (and availability zone) as a means of protecting against a single server’s failure.

In the future we will offer other configurations like 4-replicas (1-per-zone) – where in such a configuration the system will be able to withstand the loss of one, two or even three of the availability zones that it is using and still provide the database service. Similarly, another deployment form could be split between the east and west data centers to ensure the DB’s availability even in the event of a data center meltdown.

• Trial is limited to 30 days
• DB Instances created on Amazon EC2 datacenters are limited up to 10GB
• DB Instances created on Rackspace datacenter are limited up to 5GB

If you require a larger database, you can at any point submit your payment details to remove the size limitation.

You do not need to modify your product at all. Xeround supports standard SQL commands; if your product now uses a MySQL server, it will work seamlessly with Xeround once you connect it to it.

Your product can be located anywhere: at your premises if it is a test environment, on a hosted system or running from the cloud (e.g. Amazon EC2 or Rackspace).

Ideally, it is recommended to run the application at same data center that the database resides in. Currently, Xeround is deployed at:

• Amazon EC2 US East Coast
• Amazon EC2 West Europe
• RackSpace US East Coast (ORD1)

When creating your database instance, choose the data center closest to where your application is hosted.

Xeround provides a fully compliant MySQL database. Therefore, importing data into Xeround Cloud Database can be done using any standard MySQL functionality.

If your existing database is relatively small, you can use phpMyAdmin to load your database export file:

1. Log in to the Xeround DB Instance Manager and select the database instance you want to upload your database to
2. Click one of the ‘DNS Names’ entries in your instance’s ‘Details’ tab to open phpMyAdmin
3. Log in to your instance using your instance’s username and password
4. Click the ‘Import’ tab to browse and load your exported database.

For larger databases and in order to make the database migration faster, we recommend following the below procedure that parallelizes data import from a MySQL database.

1. First, use mysqldump to export your schema and data separately by executing the following commands:
   Exporting the schema: 

   mysqldump --net_buffer_length=4096 –no-data --triggers  –u <user> -p<pass> -h <server> -P <port> <database> > <schema out file>

   Exporting the data:

   mysqldump --net_buffer_length=4096 --compact --no-create-info –u<user> -p<pass> -h<server> -P<port> <database> > <data out file>

   * Setting net_buffer_length to 4096 is recommended to avoid large transactions

2. Split the data export file to several smaller files in preparation for parallel loading. For example, on any Linux distribution you can use the split command:

   split –l <num of lines per file> <source file> <dest file prefix>

3. Upload yout data to Xeround database instance:
   1. Optionally, move the database export files to and do the import from a server that is as close as possible to your Xeround database instance – this will help in lowering the overall load time by minimizing network latency. For example, if your Xeround database instance resides in Amazon’s US-East datacenter in Virginia, it would be best to load your data to it from a machine in the same datacenter.
   2. Load the exported schema file – this can be achieved using the mysql command line utility in the following fashion:

      mysql  –u <user> -p<pass> -h <server> -P <port> <database>  < <schema out file>

   3. Once the schema loading completes, you can load the exported data by spawning a process for each data file. For example:

      mysql  –u <user> -p<pass> -h <server> -P <port> -D <database>  < <data out file X>

Xeround has been built based on MySQL Storage Engine Architecture, acting as a pluggable storage engine. This implementation enables Xeround to provide many of MySQL features, such as SQL interface, interpreter, optimizer, etc., but at the same time to provide a much better backend supporting scalability, elasticity, availability and performance.

Yes – you should be able to import existing database with no need for code changes. Xeround performs a silent switch to Xeround’s distributed MySQL storage engine, which is our “secret sauce”.

See our feature comparison table »

Contrary to common perception, Amazon RDS is not a truly elastic cloud database service, but an implementation of MySQL on EC2. Unlike other database implementations, Xeround is a native cloud database, delivering seamless configuration and optimization for your MySQL’s performance, elasticity and availability in the cloud, alongside the simplicity, automation and ease-of-use of a Database-as-a-Service.

Key Differentiators Between Xeround and Amazon RDS:

1. Automatic, rule-based scale up & down while the database is always available vs. manual scaling with downtime
2. Highly available, self-healing database vs. database downtime, both planned (4 hour / week maintenance) and unplanned
3. Unlimited database size vs. limited to Amazon’s instance sizes
4. Pay per actual usage vs. pay per instance size
5. Database configuration does not require code changes to your application (replication etc.)
6. In-memory distributed architecture providing high performance for Read and Write operations
7. Xeround is agnostic to cloud service providers – your database will run with low latency on any cloud service provider of your choice

Xeround has been built based on MySQL Storage Engine Architecture, acting as a pluggable storage engine. This implementation enables Xeround to provide many of MySQL features, such as SQL interface, interpreter, optimizer, etc., but at the same time to provide a much better backend supporting scalability, elasticity, availability and performance.

Xeround cloud database is highly available via the use of node redundancy. As a rule, we take the biggest and meanest machines that Amazon has to offer (currently the m2.4xlarge type). This not only gives us the financial upside of buying resources comparatively cheaply, but also significantly lowers the probability that two of our instances reside on the same physical server. Our resource management algorithms slice, dice and provision chunks of these big servers to our users, while ensuring no two inter-redundant nodes are hosted on the same server. This way, despite getting no assurances from Amazon, we can still make our own guarantee of high availability.

In case of failure, be it network, hardware or software, Xeround database continues to work with its existing resources. In parallel, new resources are automatically allocated to return the system to its predefined fault tolerance level. There is no need for you to configure anything and no need for the application to be aware of the changes.

During continuous operation, Xeround stores data in-memory, providing low and predictable latency for both Read and Write operations. In addition, Xeround continuously stores data on-disk for Disaster Recovery functionality.

Xeround currently uses Optimistic Concurrency Control to manage locks. Since the locks are acquired at the commit phase of a transaction, error-handling code should be written with the assumption that the transaction’s commit may fail if the data was changed by another transaction while the transaction is executed.

The ability to choose among Optimistic and Pessimistic locking is planned to be offered shortly.

We do not currently support SSL connection or host-based permissions. These two features are in our roadmap and should be made available later this year.

Using application-side encryption/decryption addresses some of the security limitations of not having SSL enabled as well as ensuring that the actual data stored on our service is encrypted.

You connect to your database by providing the following details to your application or MySQL client: DNS hostname, port, username & password.

Your instance’s DNS hostnames and ports are available under the Details tab of your instance in the Xeround Database Instance Manager Console. We provide you with two DNS addresses:

• Internal DNS – points to the internal IP addresses and is used for accessing your DB from within the same datacenter
• External DNS is used for connecting from outside the datacenter.

The database instance’s username and password are those you provided when creating the instance.

Please refer to the Connecting your MySQL application to Xeround Cloud Database page for more information and examples.

Follow the next steps to identify source of the problem:

1. Verify that your database is available: access Xeround’s Database Instance Manager page and verify that the instance’s status is Healthy.
2. Connect to your database instance: establish a connection using phpMyAdmin by clicking the ‘DNS Name’ of your instance under the ‘Details’ tab.
   • Note: you’ll need to enter your database instance’s username and password to complete the connection
   • If you are unable to login successfully, please review the database credentials (i.e., username and password) that you are using. The credentials should either be those that you had supplied during the instance’s creation or ones that you had created independently after the instance was created.
3. Review your application’s connection settings: make sure that you are using the correct hostname, port, user and password in your application to connect to your instance.
   • Refer to the Connecting your MySQL application to Xeround Cloud Database page for more information and examples.
4. Rule out application-specific issues: establish a direct connection to your database instance from the application’s server. This can be achieved using any of the below methods:
   • Use MySQL’s command line utility from the server’s console. For example, use the following syntax to connect to the mydb database with the database credentials of the user john and password malon via port 4567 of the instance123.db.xeround.com hostname:

     mysql -hinstance123.db.xeround.com -P4567 -ujohn -pmalon mydb

   • Use telnet to verify connectivity from the server’s console, for example:

     telnet instance123.db.xeround.com 4567

     Note: being a generic client, telnet will only attempt to establish a network connection to the database instance (and not a database connection). This means that after connecting you will NOT be prompted for username and password and will get, most likely, what appears to be garbled characters. This is actually a good sign as it indicates that the connection went through. A connection failure, on the other hand, will be reported by an error message (e.g., “Unable to connect to remote host: Connection refused” or similar).

   • Use any standalone MySQL client software (e.g., HeidiSQL, SQLyog or MySQL Workbench) from your application server to connect to your database.
5. Access your database from a different server & network: repeat step 4 using a server other than that of your application to rule out server-specific issues. Similarly, repeat step 4 with a server that is connected to a different network to rule out network-specific issues.
   • Note: some providers intentionally block access to arbitrary network ports. Contact the support department of your provider to verify that your database instance’s port is not blocked, and if it is make a request to open it.

Xeround supports all MySQL commands, so you can continue managing with tools you are used to, such as SQLyog, phpMyAdmin, MySQL Workbench, or others.

You can retrieve data by backing up your Xeround database instance to a file and restoring it to your MySQL server.

At this time our service does not offer the means to have a Xeround database instance operate as a replication master. This is because each of Xeround’s database instances is implemented by multiple database engines that work in parallel, effectively making it multi-master setup in MySQL’s replication terms (i.e., multiple mysqld processes and multiple binary logs). Multi-Master Single-Slave replication, while arguably theoretically possible, is not supported by MySQL.

Xeround provides two methods for backing up your database and restoring your DB Instance:

1. “Hot” Backups – These are done online, with no service downtime or interruptions. Hot Backups are available only for Xeround PRO plan.
   There are two types of Hot Backups:
   • Automated scheduled backups – Xeround PRO plan includes one daily system backup, performed automatically during your chosen backup window. Automated backups are also available during the free trial period.
   • User initiated backups – You can initiate additional on-demand backups as frequently as you wish. You can initiate on-demand backups from within Xeround’s Management Console. User-generated backups are kept until you explicitly delete them.
2. Export – These are available for Xeround BASIC edition and allow you to easily export your database from within the management console. The saved exports can be used as backup or for Restore purposes.

In addition to system backups and exports, you can also export your data at any time using SQL-Dump or any external backup tools.

Xeround supports standard SQL and MySQL’s SQL extensions. We developed it specifically targeting this compatibility and tested it using the standard MySQL Test Framework. For more details on actual commands, please refer to the Xeround Release Notes.

Being a fully elastic solution, Xeround modifies the actual memory used according to the required actual size. Since the resize process itself does require computer resources it is good practice to start the database with a size allocation that will suit the initial work needs.

Xeround automatically scale up or down to the exact needs of the application so that the database gets additional resources when it needs more size/throughput, and scales back down when it is underutilized. This effectively eliminates both over-provisioning and over-paying.

Please Note that if you’ve chosen a larger initial size than the actual data you import to your instance, your database instance will automatically shrink to accommodate its actual size within 7 days.

If your data is already stored in a relational database, use the 1.5 the size of the database as the initial size. If your data resides in flat files, a good estimate will be to multiply the files’ sizes by 3.

A database instance and a database schema are not the same thing. Database instances’ names, supplied when creating the instance in Xeround’s Database Instance Manager, are used solely to identify the instance. Creating an instance does not create a database schema with the same name in the database instance and if needed, the schema should be explicitly created using the CREATE SCHEMA syntax.

Xeround uses round-robin DNS to guarantee high availability of the connection to your database in a way that does not require you to tweak your application.
Each Xeround instance is assigned with two connection DNS hostnames:

• Internal DNS points to the internal IP addresses and is used for accessing your DB from within the same datacenter
• External DNS is used for connecting from outside the datacenter.

Each DNS routes to one of the available IP addresses we supply for connecting to your database.
That way, if one IP address is temporarily unavailable, you can still connect to your database instance.

One of Xeround’s database-as-a-service key benefits is its simplicity and ease-of-use. This principle is also evident in how our database is scaled up or down.

Scaling is triggered automatically, based on threshold-based rules that you can configure in the Database Instance Manager. Your database instance will automatically increase its resources when it detects more capacity or throughput are needed, and will shrink back down when it notices that it is under-utilized. Auto-scaling up and down is done with no database downtime and is transparent to the application, meaning no code changes or configuration changes are required.

This automatic elasticity also enables us to bill our users based on their actual usage and not by a pre-set instance size (often resulting in over-provisioning).

Yes. The Xeround API allows developers to connect third-party applications to Xeround service and automate processes available in the UI. The API is accessible using either REST or SOAP, per your preference. To use the API you need to be a registered user of Xeround’s cloud database service.
For more details, see Xeround’s Cloud Database API documentation.