缩放Percona数据中心:设置和复制
由于我们的初创公司发展得很好，我们现在遇到了一些你一直认为永远不会影响到你的问题。
我们已经扩展了大量的应用程序堆栈:我们将用于临时信息的高读写表卸载到单独的Percona服务器，其中的表以"Engine=MEMORY“形式运行，并将其他部分迁移到cassandra集群。
现在，我们有一个“精益”数据库，其中有88%/12%的读/写负载。在这一点上，我有几个问题想得到一些反馈：
1.读奴隶
使用我们的读/写设置，一些(例如2-3)读-从应该减少读负载到最小的在我们的写主。读-从解决方案的可扩展性有多大:如果我们增加两倍/三倍的负载，那么额外的读从将继续提供足够的读取容量？我在这篇文章中读到：每个主人的奴隶数量有多大的限制？，但是，没有从一个可扩展的背景中出来--这看起来可能很愚蠢，但是这是一个可冻结的解决方案吗？有很多人推动切分而不是从读-从解决方案，然而，我真的不认为目前需要用我们的读/写负载重写我们的应用程序的大部分.有什么想法吗？
2.多个数据中心和复制
此外，我们正在考虑服务不同的地理位置与数据中心附近，以减少网络滞后(我们处理的移动应用程序，真正不喜欢滞后)。我们的计划是使用很多提到的半音。用于主主复制的复制(请参阅：将MySQL DB拆分成两个服务器是个好主意吗？和MySQL复制是否受高延迟互连的影响？ )，其中每个数据中心都有一个主服务器和多个读从服务器。同样，在我的天真中，我非常感兴趣地想知道，在扩展时，这是否符合“最佳实践”的范围。
3.硬件和Config
过去几个星期，我一直在忙着对我们的实时系统进行基准测试，我得出的结论是，无论我们为第1点和第2点选择了什么解决方案，我们目前使用的服务器都不会在很长一段时间内使用，我能对我们的设置有一些想法吗：
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 table5my.cnf设置：
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迁移到Percona XtraDB集群解决方案会解决我们的一些问题，例如复制稳定性吗？
我知道，这些都是非常理论性的问题，我感谢任何人花时间阅读和评论我的想法。作为欧洲的一家小型创业公司，我们真的没有足够的风险资本来“进入云端”，我们更愿意自己拥有更多的控制权。当我们研究顾问等的时候，我认为stackexchange是提出一些想法的合适地方。
回答 2
Database Administration用户
发布于 2012-07-25 16:30:25
在这种情况下，您实际上有两个选择
选择#1 : Percona XtraDB
我目前正在评估它，我认为它设计得非常出色，适合MultiMaster编写。它可以使用mysqldump (默认)、rsync和xtrabackup (首选)初始化新的群集节点。你有完全的自由和权力。除了拥有强大的力量，他们也必须永远是伟大的责任(19:16-19:25的视频)，这可能是有史以来最古老的陈词滥调。
你最终会对
- 调整InnoDB的内存需求和磁盘配置
- 记住，MyISAM上的DDL/DML不是在Galera写集复制器库中复制的。由于GRANT命令与存储引擎无关，所以处理mysql模式中的MyISAM表没有问题。不复制针对
mysql.user的任何DML。 - 添加用于读写的新群集节点
选择2: Amazon
Amazon使MySQL数据库云服务变得非常简单。您必须花费一些时间使用7种服务器模型中的一种部署服务器。默认情况下，所有InnoDB日志文件都是128 m。以下是每个服务器模型所特有的唯一选项：
MODEL max_connections innodb_buffer_pool_size
--------- --------------- -----------------------
t1.micro 34 326107136 ( 311M)
m1-small 125 1179648000 ( 1125M, 1.097G)
m1-large 623 5882511360 ( 5610M, 5.479G)
m1-xlarge 1263 11922309120 (11370M, 11.103G)
m2-xlarge 1441 13605273600 (12975M, 12.671G)
m2-2xlarge 2900 27367833600 (26100M, 25.488G)
m2-4xlarge 5816 54892953600 (52350M, 51.123G)您没有获得超级特权，也没有直接访问my.cnf的权限。有鉴于此，为了更改启动时的my.cnf选项，必须首先创建一个基于MySQL的DB参数选项列表，并使用(命令行接口)来更改所需的选项。然后，您必须这样做才能导入新选项：
- 创建自定义DB参数组(称为
MySettings) - 下载RDS CLI并使用AWS凭据设置一个配置文件
- 执行以下操作：
./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate" - 使用DB参数选项列表
MySettings进行修改 - 重新启动MySQL RDS实例
至于扩展到数据中心，您可以选择创建read副本。由于默认的存储引擎是InnoDB，使得读取副本变得无缝，因为数据可以同步到从站，而不会中断主。
更高的服务器模型意味着您可以拥有更多的内存，更多的IOP。不要忘记我提到的陈词滥调，因为当涉及到Amazon时，强大的力量带来了巨大的金钱。
Database Administration用户
发布于 2012-10-22 20:23:52
@tnosaj，关于你关于读奴隶的第一个问题--通常一个主人可以无缝地复制到5-6个奴隶。然而，评估读取从程序是否正常工作--知道您拥有的应用程序类型是非常重要的。例如，与电子商务网站相反，社交应用程序中“喜欢”的数量不需要实时更新，在电子商务网站上，如果某个商品已经售罄，那么它就必须立即更新。因此，这种类型的读取从将适用于前一种情况，但不适用于后一种情况。
关于第二个问题，关于多个数据中心和复制-最佳实践是在同一个数据中心内实现主-主复制，理想情况下，它应该在专用集群主机上完成。在多个数据中心上运行主-主复制并不是常见的做法。其原因是主从复制(类似于所有集群)所面临的最大挑战是一种被称为“分裂的大脑”的情况。在这种情况下，每个主机被断开，然后在重新启动后开始独立工作。修复这种“分裂的大脑”问题通常需要停机和人工处理。(看看这个关于大脑分裂的Wiki页面)。
至于与之配套的DB供应商，除了@Rolando提到的Percona XtraDB集群和RDS之外，我建议您也查看克伦德氏产品(我认为这是RDS的一个公平的替代方案)。
https://dba.stackexchange.com/questions/21491
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号