anchor.diff:  [[server-groups]]
   == Server groups
   
  -The domain controller defines one or more server groups and associates
  -each of these with a profile and a socket binding group, and also :
  +The Domain Controller defines one or more server groups and associates
  +each of these with a profile and a socket binding group, and also:
   
   [source,xml,options="nowrap"]
   ----
  
positive.code: with `/host=*`, i.e. those that are persisted in `domain.xml`. Having
  that local copy allows a user to do the following things:
  
  * Ask the slave to launch its already configured servers, even if the
  Domain Controller is not running.
  * Configured new servers, using different server groups from those
  current running, and ask the slave to launch them, even if the Domain
  Controller is not running.
  * Reconfigure the slave to act as the Domain Controller, allowing it to
  take over as the master if the previous master has failed or been shut
  down.
  
  However, of these three things only the latter two require that the
  slave maintain a _complete_ copy of the domain wide configuration. The
  first only requires the slave to have the _portion_ of the domain wide
  configuration that is relevant to its current servers. And the first use
  case is the most common one. A slave that is only meant to support the
  first use case can safely "ignore" portions of the domain wide
  configuration. And there are benefits to ignoring some resources:
  
  * If a server group is ignored, and the deployments mapped to that
  server group aren't mapped to other non-ignored groups, then the slave
  does not need to pull down a copy of the deployment content from the
  master. That can save disk space on the slave, improve the speed of
  starting new hosts and reduce network traffic.
  * WildFly supports "mixed domains" where a later version Domain
  Controller can manage slaves running previous versions. But those
  "legacy" slaves cannot understand configuration resources, attributes
  and operations introduced in newer versions. So any attempt to use newer
  things in the domain wide configuration will fail unless the legacy
  slaves are ignoring the relevant resources. But ignoring resources will
  allow the legacy slaves to work fine managing servers using profiles
  without new concepts, while other hosts can run servers with profiles
  that take advantage of the latest features.
  
  Prior to WildFly 10, a slave could be configured to ignore some
  resources, but the mechanism was not particularly user friendly:
  
  * The resources to be ignored had to be listed in a fair amount of
  
negative.code: 
  ~(See domain/configuration/domain.xml)~
  
  The Domain Controller also defines the socket binding groups and the
  profiles. The socket binding groups define the default socket bindings
  that are used:
  
  