Кластер MySQL: 20 ТБ x 3K таблицы
Вам не нужна справочная служба для знания пароля конечного пользователя. То, что можно сделать:
- создайте учетную запись с помощью генератора пароля - не говорят никому пароль
- в новый пользовательский день начала одна из обязанностей по справочной службе состоит в том, чтобы сбросить пароль пользователя, когда вызовы пользователя в и справочная служба дают пользователю тот новый пароль. В то время справочная служба также устанавливает "пользователя, должен изменить пароль при следующем входе в систему" опция. Обратите внимание, что это auditable и должно регулярно контролироваться.
- пользователь входит в систему на их рабочей станции и вынужден генерировать новый пароль.
Существует несколько вопросов, которые поднимает Ваш вопрос:
- если пароль автоматически генерируется, каков механизм для конечного пользователя для получения начального пароля?
- Как Вы в настоящее время обрабатываете забытые пароли? Что делает "новый" забытый пароль (новая учетная запись) отличающийся, чем существующая?
- Почему пользователь должен приехать в справочную службу для изменения их пароля?
NDB has some limitations for large tables due to it's in-memory model. For you situation, is does not make sense.
Recently, we tested Percona Cluster with some very promising results. It supports master-master replication, and has full InnoDB ACID compliance. One thing to note is the speed of queries is limited to the slowest node in the cluster - which many MySQL installations that are Master/Slave usually have a much faster Master.
If you need really fast access, you could also convert the really large data sets to MongoDB or Cassandra. Both of these are considerably faster than RDBMS like MySQL. Clustering in these NoSQL databases is native.