forked from ravendb/docs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request ravendb#1584 from Danielle9897/RDoc-2346-hidePython
RDoc-2346 Hide python docs
- Loading branch information
Showing
23 changed files
with
815 additions
and
793 deletions.
There are no files selected for viewing
214 changes: 107 additions & 107 deletions
214
...s-with-replication-bundle.python.markdown → ...h-replication-bundle.python.markdown.temp
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,107 +1,107 @@ | ||
# Replication: How client integrates with replication bundle? | ||
|
||
RavenDB's Client API is aware of the replication mechanism offered by the server instances and is ready to support failover scenarios. | ||
|
||
{PANEL:**Failover behavior**} | ||
|
||
By default the client will detect and respond appropriately whenever a server has the replication bundle enabled. This includes: | ||
|
||
* Detecting that an instance is replicating to another set of instances. | ||
* When that instance is down, the client will be automatically shifted to other instances. | ||
|
||
This is caused by a failover mechanism which is turned in a document stored by default. The client can load a replication document from `/replication/topology` to learn what replication instances to use if the failover occurred. | ||
|
||
{NOTE The client by default creates requests for the replication document even if the server does not have the replication bundle enabled. In this case, the request for `/replication/topology` results in `404` in server logs./} | ||
|
||
You can turn off the failover behavior by using the document store conventions. In order to do so, use `fail_immediately` option | ||
|
||
{CODE:python client_integration_1@clientapi\bundles\HowClientIntegratesWithReplicationBundle.py /} | ||
|
||
When `fail_immediately` option is used then client will raise exception when primary server is down. | ||
|
||
The remaining values of `Failover` enumeration are: | ||
|
||
* *allow_reads_from_secondaries* (default) - allow to read from secondary server(s), but immediately fail writes to the secondary server(s) | ||
* *allow_reads_from_secondaries_and_writes_to_secondaries* - allow reads from and writes to secondary server(s) | ||
* *read_from_all_servers* - spread read requests across all servers, instead of doing all the work against master. Write requests will always go to master | ||
|
||
They determine the strategy of the failovers if the primary server is down and the environment is configured to replicate between sibling instances. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Discovering destinations**} | ||
|
||
Once the document store is configured to support failovers, the replication configuration of the database is checked. A list of replicated nodes is then retrieved and saved in the local application storage. Even if it is impossible to reach the primary server in the future, the list will still exist locally, and the document store can try to work with secondary instances, according to the conventions. | ||
|
||
Changes in the server's replication configuration are monitored by the Client API as well. It is done regularly, every 5 minutes, to check if the documents are directed to current instances that are slaves to the primary server, in case a failover occurs. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Failover servers**} | ||
|
||
|
||
If the client cannot reach the primary server and does not have a list of servers, nor is such list available in the local cache, the client will attempt to load and use manually configured failover servers. List of those servers can be configured by a list of `ReplicationDestination` in `ReplicationDocument` and then store them in the server. | ||
|
||
|
||
### Setup | ||
|
||
{CODE:python client_integration_2@ClientApi\Bundles\HowClientIntegratesWithReplicationBundle.py /} | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Setting up default client configuration on server**} | ||
|
||
Default client configuration can be 'injected' into a client, by filling out the `ClientConfiguration` property in `Raven/Replication/Destinations`. | ||
|
||
The available options are: | ||
|
||
- `Failover` - default failover behavior for all clients that are connecting to a database. | ||
|
||
Default configuration can be altered by The Studio as well. Appropriate settings are available in `Settings -> Replication`. | ||
|
||
![Setting up default client configuration on server](images/replication-client-configuration.png) | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Request redirection**} | ||
|
||
The Raven Client API is quite intelligent in this regard, as upon failure it will: | ||
|
||
* Assume that the failure is transient, and retry the request, | ||
* If the second attempt fails as well, will record the failure and shift to a replicated node, if available, | ||
* After ten consecutive failures, Raven will start replicating to this node less often | ||
* Once every 10 requests, until failure count reaches 100 | ||
* Once every 100 requests, until failure count reaches 1,000 | ||
* Once every 1,000 requests, when failure count is above 1,000 | ||
* On the first successful request, the failure count is reset. | ||
|
||
If the second replicated node fails, the same logic applies to it as well, and we move to the third replicated node, and so on. If all nodes fail, an appropriate exception is thrown. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Back to primary**} | ||
|
||
The client shifted to a replicated node will go back to its primary server | ||
as soon as it becomes reachable (irrespective of the failure count). In replication environment the nodes send heartbeat messages in order to notify destination instances that they are up again. Then the destination (which is the secondary server for our shifted client) will send a feedback message to the client and then try sending a request to the primary server again. If the operation is successful, the failure count will be reset and the communication will work normally. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Replicated operations**} | ||
|
||
At a lower level, the following operations support replication: | ||
|
||
* get - single document and multi documents | ||
* put | ||
* delete | ||
* query | ||
|
||
The following operations do not support replication in the Client API: | ||
|
||
* put_index | ||
* delete_index | ||
|
||
{PANEL/} | ||
|
||
## Related articles | ||
|
||
- [Server : Replication](../../server/scaling-out/replication/how-replication-works) | ||
# Replication: How client integrates with replication bundle? | ||
|
||
RavenDB's Client API is aware of the replication mechanism offered by the server instances and is ready to support failover scenarios. | ||
|
||
{PANEL:**Failover behavior**} | ||
|
||
By default the client will detect and respond appropriately whenever a server has the replication bundle enabled. This includes: | ||
|
||
* Detecting that an instance is replicating to another set of instances. | ||
* When that instance is down, the client will be automatically shifted to other instances. | ||
|
||
This is caused by a failover mechanism which is turned in a document stored by default. The client can load a replication document from `/replication/topology` to learn what replication instances to use if the failover occurred. | ||
|
||
{NOTE The client by default creates requests for the replication document even if the server does not have the replication bundle enabled. In this case, the request for `/replication/topology` results in `404` in server logs./} | ||
|
||
You can turn off the failover behavior by using the document store conventions. In order to do so, use `fail_immediately` option | ||
|
||
{CODE:python client_integration_1@clientapi\bundles\HowClientIntegratesWithReplicationBundle.py /} | ||
|
||
When `fail_immediately` option is used then client will raise exception when primary server is down. | ||
|
||
The remaining values of `Failover` enumeration are: | ||
|
||
* *allow_reads_from_secondaries* (default) - allow to read from secondary server(s), but immediately fail writes to the secondary server(s) | ||
* *allow_reads_from_secondaries_and_writes_to_secondaries* - allow reads from and writes to secondary server(s) | ||
* *read_from_all_servers* - spread read requests across all servers, instead of doing all the work against master. Write requests will always go to master | ||
|
||
They determine the strategy of the failovers if the primary server is down and the environment is configured to replicate between sibling instances. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Discovering destinations**} | ||
|
||
Once the document store is configured to support failovers, the replication configuration of the database is checked. A list of replicated nodes is then retrieved and saved in the local application storage. Even if it is impossible to reach the primary server in the future, the list will still exist locally, and the document store can try to work with secondary instances, according to the conventions. | ||
|
||
Changes in the server's replication configuration are monitored by the Client API as well. It is done regularly, every 5 minutes, to check if the documents are directed to current instances that are slaves to the primary server, in case a failover occurs. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Failover servers**} | ||
|
||
|
||
If the client cannot reach the primary server and does not have a list of servers, nor is such list available in the local cache, the client will attempt to load and use manually configured failover servers. List of those servers can be configured by a list of `ReplicationDestination` in `ReplicationDocument` and then store them in the server. | ||
|
||
|
||
### Setup | ||
|
||
{CODE:python client_integration_2@ClientApi\Bundles\HowClientIntegratesWithReplicationBundle.py /} | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Setting up default client configuration on server**} | ||
|
||
Default client configuration can be 'injected' into a client, by filling out the `ClientConfiguration` property in `Raven/Replication/Destinations`. | ||
|
||
The available options are: | ||
|
||
- `Failover` - default failover behavior for all clients that are connecting to a database. | ||
|
||
Default configuration can be altered by The Studio as well. Appropriate settings are available in `Settings -> Replication`. | ||
|
||
![Setting up default client configuration on server](images/replication-client-configuration.png) | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Request redirection**} | ||
|
||
The Raven Client API is quite intelligent in this regard, as upon failure it will: | ||
|
||
* Assume that the failure is transient, and retry the request, | ||
* If the second attempt fails as well, will record the failure and shift to a replicated node, if available, | ||
* After ten consecutive failures, Raven will start replicating to this node less often | ||
* Once every 10 requests, until failure count reaches 100 | ||
* Once every 100 requests, until failure count reaches 1,000 | ||
* Once every 1,000 requests, when failure count is above 1,000 | ||
* On the first successful request, the failure count is reset. | ||
|
||
If the second replicated node fails, the same logic applies to it as well, and we move to the third replicated node, and so on. If all nodes fail, an appropriate exception is thrown. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Back to primary**} | ||
|
||
The client shifted to a replicated node will go back to its primary server | ||
as soon as it becomes reachable (irrespective of the failure count). In replication environment the nodes send heartbeat messages in order to notify destination instances that they are up again. Then the destination (which is the secondary server for our shifted client) will send a feedback message to the client and then try sending a request to the primary server again. If the operation is successful, the failure count will be reset and the communication will work normally. | ||
|
||
{PANEL/} | ||
|
||
{PANEL:**Replicated operations**} | ||
|
||
At a lower level, the following operations support replication: | ||
|
||
* get - single document and multi documents | ||
* put | ||
* delete | ||
* query | ||
|
||
The following operations do not support replication in the Client API: | ||
|
||
* put_index | ||
* delete_index | ||
|
||
{PANEL/} | ||
|
||
## Related articles | ||
|
||
- [Server : Replication](../../server/scaling-out/replication/how-replication-works) |
60 changes: 30 additions & 30 deletions
60
...session/deleting-entities.python.markdown → ...on/deleting-entities.python.markdown.temp
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,30 +1,30 @@ | ||
# Session: Deleting entities | ||
|
||
Entities can be marked for deletion by using `delete` method, but will not be removed from server until `save_changes` is called. | ||
|
||
## Syntax | ||
|
||
{CODE:python deleting_1@ClientApi\Session\DeletingEntities.py /} | ||
|
||
| Parameters | | | | ||
| ------------- | ------------- | ----- | | ||
| **entity** or **key_or_entity** | entity, str or entity | instance of entity to delete or entity Id | | ||
|
||
The `delete` method can be used with entity or str. by calling delete with entity `delete_by_entity` will be executed | ||
|
||
## Example 1 | ||
|
||
{CODE:python deleting_2@ClientApi\Session\DeletingEntities.py /} | ||
|
||
## Example 2 | ||
|
||
{CODE:python deleting_3@ClientApi\Session\DeletingEntities.py /} | ||
|
||
## Example 3 | ||
|
||
{CODE:python deleting_4@ClientApi\Session\DeletingEntities.py /} | ||
|
||
## Related articles | ||
|
||
- [Opening a session](./opening-a-session) | ||
- [Loading entities](./loading-entities) | ||
# Session: Deleting entities | ||
|
||
Entities can be marked for deletion by using `delete` method, but will not be removed from server until `save_changes` is called. | ||
|
||
## Syntax | ||
|
||
{CODE:python deleting_1@ClientApi\Session\DeletingEntities.py /} | ||
|
||
| Parameters | | | | ||
| ------------- | ------------- | ----- | | ||
| **entity** or **key_or_entity** | entity, str or entity | instance of entity to delete or entity Id | | ||
|
||
The `delete` method can be used with entity or str. by calling delete with entity `delete_by_entity` will be executed | ||
|
||
## Example 1 | ||
|
||
{CODE:python deleting_2@ClientApi\Session\DeletingEntities.py /} | ||
|
||
## Example 2 | ||
|
||
{CODE:python deleting_3@ClientApi\Session\DeletingEntities.py /} | ||
|
||
## Example 3 | ||
|
||
{CODE:python deleting_4@ClientApi\Session\DeletingEntities.py /} | ||
|
||
## Related articles | ||
|
||
- [Opening a session](./opening-a-session) | ||
- [Loading entities](./loading-entities) |
Oops, something went wrong.