| Russian | English |
| в режиме "ведущий-ведущий" | multi-master (в этом режиме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случае реализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевым взаимодействием. При асинхронном обновлении возникает другая проблема – могут появиться конфликтующие версии данных, которые требуют наличия механизма определения и разрешения конфликтов (автоматически или на уровне приложения Alex_Odeychuk) |
| в режиме "ведущий-ведущий" | master-master (в этом режиме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случаереализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевым взаимодействием. При асинхронном обновлении возникает другая проблема – могут появиться конфликтующие версии данных, которые требуют наличия механизма определения и разрешения конфликтов (автоматически или на уровне приложения Alex_Odeychuk) |
| ведущая машина | master computer |
| ведущая машина | controller machine (Alex_Odeychuk) |
| ведущая машина | host |
| ведущий-ведущий | master-master (при этой схеме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случаереализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевым взаимодействием. При асинхронном обновлении возникает другая проблема – могут появиться конфликтующие версии данных, которые требуют наличия механизма определения и разрешения конфликтов (автоматически или на уровне приложения) Alex_Odeychuk) |
| ведущий-ведущий | multi-master (при этой схеме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случае реализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевым взаимодействием. При асинхронном обновлении возникает другая проблема – могут появиться конфликтующие версии данных, которые требуют наличия механизма определения и разрешения конфликтов (автоматически или на уровне приложения) Alex_Odeychuk) |
| ведущий-подчинённый | master-slave |
| ведущий узел | master (Alex_Odeychuk) |
| вести запись | log |
| вести разработку одностраничного приложения | be following a single-page application approach (англ. термин взят из кн.: De Sanctis V. ASP.NET Core and Angular 2 Alex_Odeychuk) |
| вторичное ведущее устройство | secondary master (протокол HART Сабу) |
| первичное ведущее устройство | primary master (протокол HART Сабу) |
| система с конфигурацией "ведущий-подчинённый" | master-slave system |
| со схемой "ведущий-ведомый" | master-slave (Alex_Odeychuk) |
| со схемой "ведущий-ведущий" | multi-master (при этой схеме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случае реализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевым взаимодействием. При асинхронном обновлении возникает другая проблема – могут появиться конфликтующие версии данных, которые требуют наличия механизма определения и разрешения конфликтов (автоматически или на уровне приложения) Alex_Odeychuk) |
| со схемой "ведущий-ведущий" | master-master (при этой схеме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случаереализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевым взаимодействием. При асинхронном обновлении возникает другая проблема – могут появиться конфликтующие версии данных, которые требуют наличия механизма определения и разрешения конфликтов (автоматически или на уровне приложения) Alex_Odeychuk) |
