Has anyone had any experience using ScaleArc?
My CTO has asked my thoughts on it, and I have seen no information out there regarding real-world experiences.
Has anyone had any experience using ScaleArc?
My CTO has asked my thoughts on it, and I have seen no information out there regarding real-world experiences.
HA HA HA HA What a coincidence. I was asked to evaluate it myself.
Here is what has been done so far...
Here is what the rudimentary test I performed: I decided to connect to MySQL, not using the Master EC2, and not using the Slave EC2, but using only the ScaleArc EC2. Here is a script to wrote up to test connectivity:
[redwards@lw-lts-155 ec2]$ cat master_select
EC2_DNS=<ScaleArc-EC2-DNS Hidden>
MYSQL_USER=<<Username Hidden>
MYSQL_PASS=<Password Hidden>
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
mysql -h${EC2_DNS} ${MYSQL_CONN} -ANe"show variables like 'hostname'"
Here is the result:
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-205-21-233 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-205-21-233 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-205-21-233 |
+----------+------------------+
[redwards@lw-lts-155 ec2]$ ./master_select
+----------+------------------+
| hostname | ip-10-242-47-176 |
+----------+------------------+
Hey, not bad. Slave was reached 7 out of 10 times.
At the very least, that is what one would want: Using just one address, connect to MySQL and have some roving intelligence decide which DB Server to connect to. This has been the pipe dream of all avid prognosticators of MySQL Proxy:
Dec 17, 2012 : MySQL proxy to replication configurationApr 19, 2012 : What's the latest on MySQL Proxy?Jan 24, 2012 : Using Replication for Scale-OutWhether they implemented MySQL Proxy using LUA or scripted it in some proprietary way, the bottom line is this : ScaleArc has achieved this and has done the heavy lifting for us all (at least in the AWS Universe).
I would say : Go ahead and play with it as follows:
Sorry, I am no expert with ScaleArc and this not a full answer for you. Test drive it and kick the tires some.
I downloaded the sakila database and loaded it into the Cluster.
wget http://downloads.mysql.com/docs/sakila-db.tar.gz
Then, I ran this query
SELECT actor_id FROM sakila.actor
ORDER BY MD5(CONCAT(last_name,first_name))
and stored the results in actor_id.txt
Next, I constructed the following script to launch mysql many, many times, in testbeds..
EC2_DNS=<ScaleArc-EC2-DNS Hidden>
MYSQL_USER=<Username Hidden>
MYSQL_PASS=<Password Hidden>
MYSQL_CONN="-h${EC2_DNS} -u${MYSQL_USER} -p${MYSQL_PASS} -Dsakila"
NUMBER_OF_TESTBEDS=${1}
PARALLEL_TESTS=${2}
if [ "${1}" == "" ] ; then NUMBER_OF_TESTBEDS=1 ; fi
if [ "${2}" == "" ] ; then PARALLEL_TESTS=1 ; fi
ACTOR_LIST=""
for ACTOR_ID in `cat actor_id.txt`
do
ACTOR_LIST="${ACTOR_LIST} ${ACTOR_ID}"
done
SQLPREFIX="SELECT F.film_id,F.title FROM actor A"
SQLPREFIX="${SQLPREFIX} INNER JOIN film_actor FA USING (actor_id)"
SQLPREFIX="${SQLPREFIX} INNER JOIN film F USING (film_id) WHERE A.actor_id="
for (( X = 1 ; X <= NUMBER_OF_TESTBEDS ; X++ ))
do
echo -n "Launching TestBed #${X} ("
for (( Y = 1 ; Y <= PARALLEL_TESTS ; Y++ ))
do
echo -n " ${Y}"
for ACTOR_ID in `echo "${ACTOR_LIST}"`
do
SQLSTMT="${SQLPREFIX}${ACTOR_ID}"
mysql ${MYSQL_CONN} -ANe"${SQLSTMT}" /dev/null 2>/dev/null &
done
done
echo -n ")"
wait
echo
done
Hope This Helps !!!
In my personal experience, Scale Arc support has been notoriously bad and their software seems to be pretty unreliable.
Our Database connection to our Load balancer fails for no legitimate reason. For instance, we've had our database connection fail, which affects all of the services we have running on our webservers. When we reach out to Scale Arc support, they usually blame it on an expired SSL certificate (their fault), or syncing issues with their software (again, their fault). Resolving syncing problems (between a master node and several slave nodes) has taken two weeks for a support tech to go through the software logs and identify a problem.
If you're going to advertise 0% downtime, you should ensure your support team has the same SLA that you're marketing to your clients.
Try explaining to your boss that all web servers and database servers are performing well, except for the service we're paying a 3rdparty company to monitor and support. I don't need retrospective support, I need them to tell me when something is going to fail, before it takes down every service our company relies on for revenue.
If I had it my way, I'd deal with the pain involved with setting up a high availability network using HAproxy...
Don't neglect your clients