Migration from MySQL to Cassandra for millions of active users

How did we migrate data for millions
of live users from MySQL to
Cassandra
Andrey Panasyuk, @defascat

Use case
Challenges
a. Individual
b. Corporate

Servers
● Thousands of servers in prod
● Java 8
● Tomcat 7
● Spring 3
● Hibernate 3

Sharded MySQL. Environment
1. MySQL (Percona Server)
2. Hardware configuration:
a. two Intel E2620v2 CPU
b. 128GB RAM
c. 12x800GB Intel SSD, RAID 10
d. two 2Gb network interfaces (bonded)

MemcacheD
1. Hibernate
a. Query Cache
b. Entity Cache
2. 100th of nodes
3. ~100MBps per Memcache node

Sharded MySQL. Failover
1. master
2. co-master
3. flogger
4. archive
X4

Sharded MySQL. Approach
1. Hibernate changes:
a. Patching 2nd level caching:
i. +environment
ii. -class version
b. More info to debug problems
c. Fixing bugs
2. Own implementation:
a. FitbitTransactional
b. ManagedHibernateSession
3. Dynamic sharding concept (somewhat similar to C*)

Sharded MySQL. Data migration
Solution: vBucket

Migration (96 -> 152 shards):
● vBuckets to move: 96579
● 1 bucket migration time: 8 min
● 10 bucketmover * 3 processes - 12 days

Job
● Setup
a. Ensures vbuckets in read-only mode
b. Waits for servers to reach consensus
● Execute
a. Triggers actions (dump, insert, etc.) on Bucketmover
b. Waits for actions to complete
● Wrap-up
a. Updates shards for vbuckets, re-opens them for writes
b. Advances jobs to next action

Sharded MySQL. Schema migration
1. Locks during schema update
Solution: pt-online-schema-change + protobuf
Drawbacks:
1. Split between DML/DDL scripts
2. Binary format (additional data)
3. Additional platform specific tool
message Meta {
optional string name = 1;
optional string intro = 2;
...
repeated string requiredFeatures = 32;
}
message Challenge {
optional Meta meta = 1;
...
optional CWRace cw_race = 6;
}

Sharded MySQL. Development
1. Job system across shards
2. Use unsharded databases for lookup tables
3. Do not forget about custom annotation
@PrimaryEntity(entityType = EntityType.SHARDED_ENTITY)

Query patterns
1. Create challenge
2. List challenges by user
3. Get challenge team leaderboard by user
4. Post a message
5. List challenge messages
6. Cheer a message

MySQL. Not a problem
1. Knowledge Base
2. Response Time

Our problems
1. MySQL
a. Scalability
b. Fault tolerance
c. Schema migration
d. Locks
2. Infrastructure cost
a. MemcacheD
b. Redis

C* expectations
1. Scalability
2. Quicker fault recovery
3. Easier schema migration
4. Lack of locks

Migration specifics
1. Millions of real users in prod
2. No downtime

Apache Cassandra
Apache Cassandra is a free and open-source distributed database
management system designed to handle large amounts of data across
many commodity servers, providing high availability with no single
point of failure. Cassandra offers robust support for clusters spanning
multiple datacenters, with asynchronous masterless replication allowing
low latency operations for all clients.

Setting cluster up
1. Performance testing
2. Monitoring
3. Alerting
4. Incremental repairs (CASSANDRA-9935)

C* tweaks
1. ParNew+CMS -> G1
2. MaxPauseGCMillis = 200ms
3. ParallelGCThreads and ConcGCThreads = 4
4. Compaction
5. gc_grace_seconds = 0 (already big TTL for our data)

Create keyspaces/tables
1. Almost the same schema with Cassandra adjustments
2. Data denormalization was required in several places

ID migration
1. Create pseudo-random migration UUID based on BIGINT
2. Thank API designers for using string as object ids.
3. Make sure clients are ready for the new length of the id.
4. Migrate API to UUID all over the place

DAO (Data Access Object)
1. Create CassandraDAO with the same interface as HibernateDAO
2. Create ProxyAdapterDAO to control which implementation to select
3. Create adapter implementation for each DAO with the same
interface as HibernateDAO

Enable shadow writes (percentage)
1. Introduce environment specific settings for shadow writes
2. Adjust ProxyAdapterDAO code to enable shadow writes by
percentage. Various implementations.
3. Analyze performance (StatsD metrics for our code + Cassandra
metrics)

Migrate legacy data
1. Create a new job to read/migrate data
2. Process data in batches

Start shadow C* reads with validation
1. Environment specific settings for data validation
2. Adjust ProxyAdapterDAO code to enable simultaneous read from
MySQL and Cassandra
3. Adjust ProxyAdapterDAO to be able to compare objects
4. Logging & investigating data discrepancy.

Check validation issues
1. Path
a. Fix code problems
b. Migrate affected challenges again
c. Go to step 1
2. Duration: 1.5 month

Turn on read from C*
1. Introduce C* return read percentage in the config settings
2. Still do shadow MySQL reads and validations
3. Increase percentage over time

Clean-up
1. Adjust places which are not suitable for C* patterns like look
through all of the shards.
2. Adjust adapters to get rid of Hibernate DAOs. Adapter hierarchy is
still presented
3. Remove obsolete code
4. Clean up MySQL database

Challenge Events Migration Example
1. Previous attempts:
a. SWF + SQS
b. MySQL + Job across all shards
2. Now
a. Complication due to C* as a queue performance
b. 16 threads across 1024 buckets

Code Redesign. Message cheer example
1. Originally
a. Read
b. Update BLOB
c. Persist
2. Approach
a. Update C* set as a single operation

Code Redesign. Life without transactions
1. BATCH
2. Some object as a single source of truth

Challenges C*. Current State
1. Two datacenters
2. 18 nodes
3. Hardware
a. 24-core CPU
b. 64 GB RAM
4. RF: 3

Results of migration
1. Significant improvement in persistence storage scalability &
management (comparing to MySQL RDBMS)
2. Minimizing number of external points of failures
3. Squashing Technical Debt
4. Created a reusable migration module

Cassandra Inconveniences
1. Lack of ACID transactions
2. MultiDC scenarios require concious decisions for
QUORUM/LOCAL_QUORUM.
3. Data denormalization
4. CQL vs SQL limitations
5. Less readable IDs

Surprisingly not a big deal
1. Lack of JOINs due to the model
2. Lack of aggregation functions due to the model (we’re on 2.1 now)
3. Eventual consistency
4. IDs format change

Migration from MySQL to Cassandra for millions of active users

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Migration from MySQL to Cassandra for millions of active users (20)

Recently uploaded (20)

Migration from MySQL to Cassandra for millions of active users