You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Sa...@ril.com on 2022/02/11 07:52:29 UTC
Ignite data not in sync
We are running Apache Ignite version 2.7, It is three node cluster.
After restart of one of the Ignite node, we are getting inconsistent select result on one of our cache.
Is there any way we can remove this inconsistency ? Below is the couple sql which clerk_id is intermittently visible.
0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
+--------------------------------+--------------------------------+
| CLERK_ID | TSTAMP_TRANS |
+--------------------------------+--------------------------------+
| 1212652456 | 2022011018152249 |
+--------------------------------+--------------------------------+
1 row selected (0.017 seconds)
0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
+--------------------------------+--------------------------------+
| CLERK_ID | TSTAMP_TRANS |
+--------------------------------+--------------------------------+
| 1212652456 | 2022011018152249 |
+--------------------------------+--------------------------------+
1 row selected (0.002 seconds)
0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
+--------------------------------+--------------------------------+
| CLERK_ID | TSTAMP_TRANS |
+--------------------------------+--------------------------------+
| | 2022011018152249 |
+--------------------------------+--------------------------------+
1 row selected (0.003 seconds)
0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
+--------------------------------+--------------------------------+
| CLERK_ID | TSTAMP_TRANS |
+--------------------------------+--------------------------------+
| | 2022011018152249 |
+--------------------------------+--------------------------------+
1 row selected (0.002 seconds)
0: jdbc:ignite:thin://10.142.49.43:10800>
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s).
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email.
and delete this message and any attachments from your system.
Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email.
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
Re: Ignite data not in sync
Posted by Maksim Timonin <ti...@apache.org>.
Hi!
Am I correctly understanding your case:
1. There is a 3-node cluster
2. You restart one node
3. After restart you query a cache with the same query, and sometimes it
returns a value for the field "CLERK_ID" and sometimes not.
Maksim
On Fri, Feb 11, 2022 at 11:27 AM <Sa...@ril.com> wrote:
> We are running Apache Ignite version 2.7, It is three node cluster.
>
> After restart of one of the Ignite node, we are getting inconsistent
> select result on one of our cache.
>
>
>
> Is there any way we can remove this inconsistency ? Below is the couple
> sql which clerk_id is intermittently visible.
>
>
>
>
>
>
>
>
>
>
>
> 0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans
> from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
>
> +--------------------------------+--------------------------------+
>
> | CLERK_ID | TSTAMP_TRANS |
>
> +--------------------------------+--------------------------------+
>
> | 1212652456 | 2022011018152249 |
>
> +--------------------------------+--------------------------------+
>
> 1 row selected (0.017 seconds)
>
> 0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans
> from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
>
> +--------------------------------+--------------------------------+
>
> | CLERK_ID | TSTAMP_TRANS |
>
> +--------------------------------+--------------------------------+
>
> | 1212652456 | 2022011018152249 |
>
> +--------------------------------+--------------------------------+
>
> 1 row selected (0.002 seconds)
>
> 0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans
> from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
>
> +--------------------------------+--------------------------------+
>
> | CLERK_ID | TSTAMP_TRANS |
>
> +--------------------------------+--------------------------------+
>
> | | 2022011018152249 |
>
> +--------------------------------+--------------------------------+
>
> 1 row selected (0.003 seconds)
>
> 0: jdbc:ignite:thin://10.142.49.43:10800> select clerk_id,tstamp_trans
> from crawler_fin_l_r where UNIQUENESS_KEY='893689191';
>
> +--------------------------------+--------------------------------+
>
> | CLERK_ID | TSTAMP_TRANS |
>
> +--------------------------------+--------------------------------+
>
> | | 2022011018152249 |
>
> +--------------------------------+--------------------------------+
>
> 1 row selected (0.002 seconds)
>
> 0: jdbc:ignite:thin://10.142.49.43:10800>
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>