Dell DX6000 Kurulum ve Yapılandırma Kılavuzu - Sayfa 19

Depolama Dell DX6000 için çevrimiçi göz atın veya pdf Kurulum ve Yapılandırma Kılavuzu indirin. Dell DX6000 43 sayfaları. Rack installation instructions — static rails
Ayrıca Dell DX6000 için: Tamamlayıcı Kılavuz (4 sayfalar), Donanım Kurulum Talimatları (2 sayfalar), Kullanıcı Kılavuzu (46 sayfalar), Kurulum ve Yapılandırma Kılavuzu (35 sayfalar), Başlangıç Kılavuzu (28 sayfalar), Uyarı (28 sayfalar), Uyarı (20 sayfalar), Genel Bakış (19 sayfalar), Yapılandırma Kılavuzu (9 sayfalar), Yapılandırma Kılavuzu (9 sayfalar), Yayın Notu (8 sayfalar), Referans Kılavuzu (12 sayfalar), Yapılandırma Kılavuzu (7 sayfalar), Yayın Notu (6 sayfalar), Yayın Notu (5 sayfalar), Sürüm Notları (5 sayfalar), Kurulum Talimatları (2 sayfalar), Kurulum Talimatları (2 sayfalar)

Chapter 5. Running and Managing DX Content Router

DX Content Router Publisher and Replicator will attempt to start every time the server on which they

are installed boots. Admins should be sure to update the config files for Publisher and/or Replicator

after installation to ensure DX Content Router has the necessary information to start correctly. If

a service was stopped for any reason it can be manually started with a standard init.d script. For

mirrored configurations with both services on the same server, Publisher and Replicator must be

started separately as follows:

$ sudo /etc/init.d/cr-publisher start

$ sudo /etc/init.d/cr-replicator start

To stop a DX Content Router service, use one of the following commands:

$ sudo /etc/init.d/cr-publisher stop

$ sudo /etc/init.d/cr-replicator stop

The standard rule set can easily be customized to control what content is published on a given

channel. Each Publish statement, or channel', will be evaluated against the full list of known UUIDs.

Multiple replicators may subscribe to the same channel when replicating the same content to more

than one remote cluster. Channel names are case sensitive. Modifications to rules files, both real-

time and while Publisher is stopped, will delete all subscriber sessions as the list of previously

filtered events is no longer guaranteed to be accurate for the new rules. Subscriber clients that

receive a 404 on a request must restart their subscriber session(s).

The default channel in the sample rules file is a 'PublishAll' rule with no filter criteria that cannot be

modified. This channel name is reserved and the filter criteria associated with it cannot be modified

as the PublishAll case is optimized to speed performance by skipping the rule filtering process.

'PublishAll' is equivalent to the previous default of 'ReplicateAll'; customers using a 'ReplicateAll'

rule need not update their rule name to gain the same functionality. Legacy 'ReplicateAll' rules will

display on the Publisher console as 'PublishAll' (irrespective of the name displayed in the rules.xml

file) and will behave in all other ways as the 'PublishAll' rule. If there are any filter criteria associated

with either the 'PublishAll' or 'ReplicateAll' rule, Publisher will log an error and fail to start.

The examples below illustrate multiple alternate rule implementations.

Note

Delete events are considered to match all channels. They are sent to all subscribers. For

a Replicator subscriber, there is a configuration parameter, "ignoreDeleteEvents", which

tells Replicator to not propagate any deletes to the target cluster. Unless this parameter

is set, all object deletes are propagated independent of which channels streams matched

when they were written. This ensures content replicated to a remote cluster via a previous

rule version is still deleted. If a stream was never replicated to the target cluster, there will

be nothing to delete.

This is the same as the default "PublishAll" case.

Version 2.2

December 2010