首先需要在主实例上设置：设置`loose_innodb_primary_sync_slave`为3，目的是告诉主实例，它连接的只读实例会有强同步的需求。接着在需要强同步的只读实例上把参数`loose_slave_trans_sync_level `设置为2，注意这个参数需要重启实例。另外，先设置主实例，再设置只读实例的顺序不能乱。设置成功后，在主实例上执行`show polar replicas;`(这个命令可以查看所有的只读实例)，在`sync_level`这一列，可以发现由默认的0变成了2，这就表示强同步开启成功了。如果需要关闭强同步，在主实例上设置`loose_innodb_primary_sync_slave`为0，只读节点上设置`loose_slave_trans_sync_level `设置为0即可，注意设置的顺序依然不能乱。此外，如果强同步的只读实例在`loose_innodb_primary_sync_slave_timeout`后还没返回，强同步复制退化为异步复制，还可以通过`loose_innodb_primary_sync_slave`参数控制当只读节点掉线时是否立刻退化为异步复制。
另外一种解决办法是通过PROXY来解决。主实例每次做完更新就会把当前的日志位点发给PROXY，同时PROXY也会定期去轮询最大的日志位点，当PROXY需要把后续的查询发到只读实例上时，首先会判断只读实例是否应用到了最新的位点，如果不是，就把请求转发到主实例。这个策略操作的单位是连接，即通过这种方法能保证同一个连接中读到的一定是最新的数据。这种方法虽然会导致主库的压力变大，但是其对性能影响较小，是一种推荐的方法。如果用户需要使用，联系售后做一次小版本升级，即可开放这个功能。
## BINLOG问题
POLARDB使用基于redolog的物理复制来构建复制关系，不依赖BINLOG，因此BINLOG默认是关闭的，但是许多用户需要使用BINLOG将数据同步到第三方数据仓库以方便做复杂的数据分析，所以有很多开启BINLOG的需求。用户可以开启BINLOG，但是与RDS不同，后台不但不会有任务定时上传备份BINLOG，而且也不会有定期删除BINGLOG的任务，完全需要用户自己控制何时删除，否则会导致BINLOG堆积，从而造成更多的存储成本。因为POLARDB不依赖BINLOG复制，我们不清楚用户已经消费了多少日志(有可能用户的SLAVE端使用了类似复制延迟的技术)，因此，需要用户自己决定何时清除日志。
用户可以通过主实例(考虑到HA切换，最好把所有只读实例也打开)参数`loose_polar_log_bin`打开BINLOG(需要重启)，BINLOG就会自动存储在日志目录下，空间统计在日志空间使用量里面。可以通过常规的`show master logs`查看BINLOG。每个BINLOG的大小，BINLOG cache的大小，BINLOG格式等参数都可以通过控制台调整。这里注意下，由于POLARDB使用的是自研的存储系统，`sync_binlog`参数无效，因此没有开放。
如果用户需要删除无用的BINLOG，目前有一种方法：通过调节参数`loose_expire_logs_hours`来控制BINLOG自动删除的时间，这个参数表示自BINLOG创建后多久系统自动将它删除，单位是小时。注意，删除前请务必确保BINLOG已经无效，误删除后将无法恢复(BINLOG是否需要后台上传OSS来作为备份，这个需求我们会参考用户的反馈来决定是否支持)。
**目前，开启BINLOG有一个限制：当底层存储系统升级的时，开启BINLOG的实例不可服务时间目前是分钟级别的，不开启BINLOG的实例是秒级别的。所以，如果用户对实例可用性要求比较高，可以等我们优化后再开启BINLOG**。
## 限制问题
POLARDB由于使用了自研的文件系统和自研的块设备存储系统，因此在一些限制上与RDS MySQL有所不同。
由于文件系统是集成在数据库里面的，即数据库与文件系统共用一个进程，所以文件系统会占用一部分的规格内存。另外不同规格的文件个数也有上限。目前存储最大支持到10000GB。
此外，文件名，即数据库中的表名和库名都不能超过63个字符，实际使用的时候最好控制在55个字符以下，因为还有.frm,.ibd后缀，中间过程临时表等。详细的说明见[这里](https://help.aliyun.com/document_detail/72671.html?spm=5176.10695662.1996646101.searchclickresult.38b34a84FpSWtb)
## 并发连接问题
数据库最佳性能的线程数一般是CPU核数的2-3倍，线程数太少，不容易发挥出多线程的优势，线程数太多，又容易导致上下文切换过多以及锁争抢严重的问题。不幸的是，很多用户往往会创建很多并发连接，导致数据库CPU打满，性能低下。