Escala de centros de datos de Percona: configuración y replicación

Question

Dado que nuestra startup ha despegado bien, ahora nos reunimos con algunos de esos problemas que siempre asumió que nunca te afectaría.

Ya hemos escalado mucho de nuestra pila de aplicaciones: descargamos nuestras altas tablas de lectura/escritura para obtener información temporal a un servidor Percona separado donde las tablas se ejecutan con "motor = memoria", así como migramos otras secciones a un clúster de Cassandra.

Ahora nos queda una base de datos "delgada" donde tenemos una carga de lectura/escritura del 88%/12%. En este punto, tengo algunas preguntas sobre las que me gustaría recibir comentarios:

1. Leer esclavos

Con nuestra configuración de lectura/escritura, una serie de (por ejemplo 2-3) los esclavos de lectura deberían reducir la carga de lectura al mínimo en nuestro maestro de escritura. ¿Qué tan escalable es una solución de lectura-esclavo: si duplicamos/triple nuestra carga, agregamos esclavos de lectura adicionales para continuar ofreciendo suficiente capacidad para lecturas? Leí en esta publicación: ¿Cuáles son los límites de la cantidad de esclavos por maestro? Sin embargo, sin salir de un fondo de escala, esto puede parecer tonto, pero ¿es esta una solución congelable? Hay muchas personas empujando fragmentos en lugar de una solución de lectura, sin embargo, realmente no veo una necesidad en este momento con nuestra carga de lectura/escritura para reescribir grandes secciones de nuestra aplicación ... ¿alguna idea?

2. múltiples centros de datos y replicación

Además, estamos buscando servir diferentes ubicaciones geográficas con centros de datos cercanos para reducir el retraso de la red (tratamos con aplicaciones móviles a las que realmente no les gustan el retraso). El plan sería usar la semisync muy mencionada. Replicación (ver: ¿Es una buena idea dividir mysql db en dos servidores? y ¿Se ve afectada la replicación MySQL por una interconexión de alta latencia? ) para una replicación maestra-maestro, donde cada centro de datos tiene un solo maestro y múltiples esclavos de lectura. Nuevamente, en mi ingenuidad, estoy muy interesado en saber si esto estaría dentro de los límites de las "mejores prácticas" al escalar.

3. Hardware y configuración

He estado ocupado en las últimas semanas comparando nuestro sistema en vivo, y he llegado a la conclusión de que, independientemente de la solución que elegimos para el punto 1 y 2, el servidor que estamos usando actualmente no lo hará por mucho más tiempo, podría hacerlo. Tengo algunas ideas sobre nuestra configuración:

CPU: Intel(R) Xeon(R) CPU E31275 @ 3.40GHz mit 8 cores (hyperthreading)
RAM: 16GB
Raid 10 with a strip size of 64 KB and controller cache enabled
Software: Percona 5.5
Database size: 83.7GB
Top 5 Tables:
 21302MB  table1
 7656MB  table2
 5477MB  table3
 4352MB  table4
 3663MB  table5

My.cnf Configuración:

 max_heap_table_size=64M
 tmp_table_size=64M
 default_storage_engine = InnoDB
 innodb_buffer_pool_size = 10G
 innodb_file_per_table   = 1
 innodb_old_blocks_time=1000
 innodb_buffer_pool_instances=10
 innodb_log_file_size=256M
 innodb_flush_method=O_DIRECT
 innodb_read_io_threads=10
 innodb_write_io_threads=10
 join_buffer_size = 67108864 #64M
 expand_fast_index_creation=ON

¿Moverse a una solución de clúster Percona XTRADB resolverá algunos de nuestros problemas, por ejemplo, la estabilidad de la replicación?

Sé que estas son muchas preguntas que son muy teóricas, y aprecio a cualquiera que se tome el tiempo para leer y comentar mis pensamientos. Como pequeña startup en Europa, realmente no tenemos el capital de riesgo para "ir a la nube", y preferimos tener más controles nosotros mismos. Mientras buscamos consultores, etc. Pensé que Stackexchange era el lugar correcto para eliminar algunas ideas.